NSLU2-Linux
view · edit · print · history

HowTo.UseOpenSSHForRemoteAccess History

Hide minor edits - Show changes to markup

February 01, 2009, at 08:37 AM by DYamaki --
Changed lines 262-263 from:

ipkg update ipkg install openssh-sftp-server

to:
 ipkg update
 ipkg install openssh-sftp-server
Changed line 270 from:

chmod 777 /dev/null

to:
 chmod 777 /dev/null
February 01, 2009, at 08:36 AM by DYamaki -- Updated formatting
Added lines 260-261:

(:table border=0 width=80% bgcolor=#eeffee:) (:cell:)

Changed lines 264-265 from:
to:

(:tableend:)

Added lines 268-269:

(:table border=0 width=80% bgcolor=#eeffee:) (:cell:)

Changed lines 271-272 from:
to:

(:tableend:)

February 01, 2009, at 08:35 AM by DYamaki -- Updated SFTP Section
Changed lines 254-255 from:

If you wanto to use sftp, then you need to install also the package openssh-sftp-server (At least I need it -thx1011). On OpenSlug 2.7Beta even after installing package openssh, you need this one. Then you can use, for example on windows side, the WinSCP freeware program, ou also, the integrated SFTP client into OpenSSH windows client. This will allow file transfer using SSH for remote access without exposing your Samba shares.

to:

If you want to use SFTP, then you need to install also the package openssh-sftp-server (At least I need it -thx1011). On OpenSlug 2.7Beta even after installing package openssh, you need this one. Then you can use, for example on windows side, the WinSCP freeware program, ou also, the integrated SFTP client into OpenSSH windows client. This will allow file transfer using SSH for remote access without exposing your Samba shares.

Added lines 258-266:

To do this login as root and execute:

ipkg update ipkg install openssh-sftp-server

You will also need to change the /dev/null permissions, otherwise you will get an SFTP connection error:

chmod 777 /dev/null

October 23, 2008, at 09:27 AM by Pistol -- Added reference to installing openssh-sftp-server if you wish to use WinSCP/Filezilla.
Changed lines 48-49 from:

(You might like to use WinSCP or FileZilla instead/as well. These allow FTP-like access to your files over the secure SSH connection.)

to:

(You might like to use WinSCP or FileZilla instead/as well. These allow FTP-like access to your files over the secure SSH connection. You may have to install openssh-sftp-server for this to work.)

October 20, 2008, at 09:01 AM by Kmoerman -- openssh-sftp should be openssh-sftp-server
Changed lines 254-255 from:

If you wanto to use sftp, then you need to install also the package openssh-sftp (At least I need it -thx1011). On OpenSlug 2.7Beta even after installing package openssh, you need this one. Then you can use, for example on windows side, the WinSCP freeware program, ou also, the integrated SFTP client into OpenSSH windows client. This will allow file transfer using SSH for remote access without exposing your Samba shares.

to:

If you wanto to use sftp, then you need to install also the package openssh-sftp-server (At least I need it -thx1011). On OpenSlug 2.7Beta even after installing package openssh, you need this one. Then you can use, for example on windows side, the WinSCP freeware program, ou also, the integrated SFTP client into OpenSSH windows client. This will allow file transfer using SSH for remote access without exposing your Samba shares.

July 11, 2008, at 07:01 AM by CR --
Changed lines 403-405 from:

Installing DenyHosts (http://denyhosts.sourceforge.net/) or another program with similar functionality will help stop this.

to:

Installing DenyHosts (http://denyhosts.sourceforge.net/) or another program with similar functionality will help stop this.

edit by CR: it also helps to change the port on which your SSH is listenig - scripts often just look for the default port 22. my slug is listening on 443 (forwarded by router) and I haven't got any login attempts since I changed the port :)

June 27, 2008, at 04:13 PM by Carl --
Added lines 267-268:
  • ipkg install openssh-sftp-server is required for sshfs* 27/6/8
April 25, 2008, at 05:29 AM by Fred --
Changed lines 267-268 from:

Note: I like to sshfs to the NSLU2 from a user account other than root for security reasons - that way if you use a key without a passphrase, if someone has access to the account with the key they still haven't got root access to your slug.

to:

Note: I like to sshfs to the NSLU2 from a user account other than root for security reasons. I'd like to be able to use only a key without a passphrase for easy auto-mounting, but if my account is compromised I'd rather not give root access to the slug.

April 25, 2008, at 05:20 AM by Fred --
Changed lines 267-269 from:

Note: If you are going to sshfs to the NSLU2 with a user other than root (probably not a bad idea for security reasons), you will need to permit other users to access /dev/null on the slug itself. If you don't do this, you will keep receiving a "remote host disconnected" message.

to:

Note: I like to sshfs to the NSLU2 from a user account other than root for security reasons - that way if you use a key without a passphrase, if someone has access to the account with the key they still haven't got root access to your slug.

If you are going to sshfs to the NSLU2 via a user account other than root you will need to permit other users to access /dev/null on the slug itself. If you don't do this, you will keep receiving a "remote host disconnected" message.

April 25, 2008, at 05:13 AM by Fred -- Made a note about how to sshfs for non-root accounts
Changed lines 265-266 from:

If working with *nix systems, you can mount your your data on the NSLU2 via either LUFS or SHFS. I have found SHFS a bit easier to work with than LUFS, but if you're working with encrypted file systems LUFS is the way to go. SHFS requires Perl to be installed on the NSLU2, which is conveniently available as a package (ipkg install perl). For the mounting in SHFS, make sure all binaries and mount points have the appropriate ownership and accessibility.

to:

If working with *nix systems, you can mount your your data on the NSLU2 via either LUFS or SHFS. I have found SHFS a bit easier to work with than LUFS, but if you're working with encrypted file systems LUFS is the way to go. SHFS requires Perl to be installed on the NSLU2, which is conveniently available as a package (ipkg install perl). For the mounting in SHFS, make sure all binaries and mount points have the appropriate ownership and accessibility.

Note: If you are going to sshfs to the NSLU2 with a user other than root (probably not a bad idea for security reasons), you will need to permit other users to access /dev/null on the slug itself. If you don't do this, you will keep receiving a "remote host disconnected" message. (:table border=0 width=80% bgcolor=#eeffee:) (:cell:)

  chmod 777 /dev/null

(:tableend:)

January 16, 2008, at 01:06 PM by glynd -- added warning to check for correct /root directory
Changed lines 90-92 from:

Now change to the home directory and create the hidden directory for the SSH settings:

to:

Notice: Although you have set up a new home directory it will not be active until your next telnet session. Until you do this the home may still be '/' not '/root'. It is important that the SSH settings are off your new /root directory, not the system root.

Now change to your home directory and create the hidden directory for the SSH settings:

Changed line 95 from:
 cd ~
to:
 cd /root
December 07, 2007, at 07:06 PM by Andy -- RE: Other Users. Files created while logged in as root will be owned by user and group root. For OpenSSH to work for other users the .ssh directory and authorized_keys file need to be owned by the user for you to be able to log in using you public/private key pair. These lines have been added to the relevent point
Added line 225:
 chown john:john .ssh
Added line 234:
 chown john:john authorized_keys
December 03, 2007, at 06:32 PM by -DC- --
Changed line 322 from:
 C:\cygwin\bin\ssh.exe -ax -c blowfish -L 10.0.0.222:445:127.0.0.1:445 root@nslu2
to:
 C:\cygwin\bin\ssh.exe -ax -c blowfish-cbc -L 10.0.0.222:445:127.0.0.1:445 root@nslu2
December 03, 2007, at 06:16 PM by -DC- -- More clarification on tunneling SMB
Changed lines 287-288 from:
 ".\plink.exe" username@myserver.ipaddress.com -ssh -N -v -batch -L 10.0.0.1:139:127.0.0.1:139 -L 10.0.0.1:445:127.0.0.1:445 -L 10.0.0.1:80:127.0.0.1:80 -L 10.0.0.1:443:127.0.0.1:443 -L 10.0.0.1:901:127.0.0.1:901 -L 10.0.0.1:8080:127.0.0.1:8080 -L 10.0.0.1:6667:127.0.0.1:6667 -L 10.0.0.1:9180:mynetworkgatewayipaddress:80 -L 10.0.0.1:21:ftp.myispwebpageuploadserver.com:21
to:
 ".\plink.exe" username@myserver.ipaddress.com -ssh -N -v -batch -L 10.0.0.1:139:127.0.0.1:139 -L 10.0.0.1:445:127.0.0.1:445
Changed lines 296-297 from:

Note: the only ports you need to expose for SAMBA are 139 and 445. This assumes you have set up the loopback adapter on 10.0.0.1 and removed all the bound services except TCP/IP as described in the page linked to above.

to:

Note: the only ports you need to expose for SAMBA are 139 (pre-Windows 2000) and/or 445 (Windows 2000 and newer). This assumes you have set up the loopback adapter on 10.0.0.1 and removed all the bound services except TCP/IP and Client for Microsoft Networks.

Changed lines 318-319 from:

Once OpenSSH? is installed, create a loopback adapter in Windows (search Google.) To make an SSH connection and tunnel the SMB protocol (port 445), use the following command:

to:

Once OpenSSH? is installed, create a loopback adapter in Windows (search Google.) Make sure to disable File and Printer Sharing for this adapter but leave Client for Microsoft Networks enabled. To make an SSH connection and tunnel the SMB protocol (port 445), use the following command:

Changed lines 325-326 from:

Where 10.0.0.222 is the IP address of your loopback adapter and nslu2 is the IP address of your slug (the other switches should speed up the connection a bit; you can also specify -C to use SSH compression.) You should now be able to click Start/Run and type in \\10.0.0.222 to see your NSLU2 folders.

to:

Where 10.0.0.222 is the IP address of your loopback adapter and nslu2 is the IP address of your slug (the other switches should speed up the connection a bit; you can also specify -C to use SSH compression.) You should now be able to click Start/Run and type in \\10.0.0.222 to see your NSLU2 folders.

November 29, 2007, at 03:15 PM by -DC- --
Changed lines 285-295 from:

@echo off

".\plink.exe" username@myserver.ipaddress.com -ssh -N -v -batch -L 10.0.0.1:139:127.0.0.1:139 -L 10.0.0.1:445:127.0.0.1:445 -L 10.0.0.1:80:127.0.0.1:80 -L 10.0.0.1:443:127.0.0.1:443 -L 10.0.0.1:901:127.0.0.1:901 -L 10.0.0.1:8080:127.0.0.1:8080 -L 10.0.0.1:6667:127.0.0.1:6667 -L 10.0.0.1:9180:mynetworkgatewayipaddress:80 -L 10.0.0.1:21:ftp.myispwebpageuploadserver.com:21

REM If you are running Windows 95 or 98, you can uncomment the following "choice" line to REM insert a delay of 5 seconds before the connection tries to re-establish.

REM choice /cX /t:X,5 > nul REM call tunnel.bat

to:
 @echo off

 ".\plink.exe" username@myserver.ipaddress.com -ssh -N -v -batch -L 10.0.0.1:139:127.0.0.1:139 -L 10.0.0.1:445:127.0.0.1:445 -L 10.0.0.1:80:127.0.0.1:80 -L 10.0.0.1:443:127.0.0.1:443 -L 10.0.0.1:901:127.0.0.1:901 -L 10.0.0.1:8080:127.0.0.1:8080 -L 10.0.0.1:6667:127.0.0.1:6667 -L 10.0.0.1:9180:mynetworkgatewayipaddress:80 -L 10.0.0.1:21:ftp.myispwebpageuploadserver.com:21

 REM If you are running Windows 95 or 98, you can uncomment the following "choice" line to 
 REM insert a delay of 5 seconds before the connection tries to re-establish.

 REM choice /cX /t:X,5 > nul
 REM call tunnel.bat
Changed line 322 from:

C:\cygwin\bin\ssh.exe -ax -c blowfish -L 10.0.0.222:445:127.0.0.1:445 root@nslu2

to:
 C:\cygwin\bin\ssh.exe -ax -c blowfish -L 10.0.0.222:445:127.0.0.1:445 root@nslu2
November 29, 2007, at 03:13 PM by -DC- --
Added lines 322-323:

(:table border=0 width=80% bgcolor=#eeffee:) (:cell:)

Changed lines 325-326 from:
to:

(:tableend:)

November 29, 2007, at 12:43 AM by -DC- --
Changed lines 322-325 from:

C:\cygwin\bin\ssh.exe -ax -c blowfish -L 10.0.0.222:445:127.0.0.1:445 root@10.0.0.98

Where 10.0.0.222 is the IP address of your loopback adapter (the other switches should speed up the connection a bit; you can also specify -C to use SSH compression.) You should now be able to click Start/Run and type in \\10.0.0.222 to see your NSLU2 folders.

to:

C:\cygwin\bin\ssh.exe -ax -c blowfish -L 10.0.0.222:445:127.0.0.1:445 root@nslu2

Where 10.0.0.222 is the IP address of your loopback adapter and nslu2 is the IP address of your slug (the other switches should speed up the connection a bit; you can also specify -C to use SSH compression.) You should now be able to click Start/Run and type in \\10.0.0.222 to see your NSLU2 folders.

November 29, 2007, at 12:35 AM by -DC- --
Changed lines 320-321 from:

Once OpenSSH? is installed, create a virtual network adapter in Windows as explained above. To make an SSH connection and tunnel the SMB protocol (port 445), use the following command:

to:

Once OpenSSH? is installed, create a loopback adapter in Windows (search Google.) To make an SSH connection and tunnel the SMB protocol (port 445), use the following command:

Changed lines 324-325 from:

Where 10.0.0.222 is the IP address of your virtual network adapter (the other switches should speed up the connection a bit; you can also specify -C to use SSH compression.) You should now be able to click Start/Run and type in \\10.0.0.222 to see your NSLU2 folders.

to:

Where 10.0.0.222 is the IP address of your loopback adapter (the other switches should speed up the connection a bit; you can also specify -C to use SSH compression.) You should now be able to click Start/Run and type in \\10.0.0.222 to see your NSLU2 folders.

November 29, 2007, at 12:28 AM by -DC- --
Changed lines 318-321 from:

Cygwin is a Linux-like environment for Windows. With it you can install the latest OpenSSH? package and use it from the command line the same way you would in Linux. A good step-by-step installation tutorial can be found at http://pigtail.net/LRP/printsrv/cygwin-sshd.html. Another option is CopSSH which installs a minimalistic version of Cygwin specifically meant for running OpenSSH?.

Once OpenSSH? is installed, create a virtual network adapter in Windows as explained above. To make an SSH connection and tunnel the SMB protocol (port 445), use the following command:

to:

Cygwin is a Linux-like environment for Windows. With it you can install the latest OpenSSH? package and use it from the command line the same way you would in Linux. A good step-by-step installation tutorial can be found at http://pigtail.net/LRP/printsrv/cygwin-sshd.html. Another option is CopSSH which installs a minimalistic version of Cygwin specifically meant for running OpenSSH?.

Once OpenSSH? is installed, create a virtual network adapter in Windows as explained above. To make an SSH connection and tunnel the SMB protocol (port 445), use the following command:

Changed lines 324-325 from:

Where 10.0.0.222 is the IP address of your virtual network adapter (the other switches should speed up the connection a bit; you can also specify -C for SSH compression.) You should now be able to click Start/Run and type in \\10.0.0.222 to see your NSLU2 folders.

to:

Where 10.0.0.222 is the IP address of your virtual network adapter (the other switches should speed up the connection a bit; you can also specify -C to use SSH compression.) You should now be able to click Start/Run and type in \\10.0.0.222 to see your NSLU2 folders.

November 29, 2007, at 12:24 AM by -DC- -- Added Cygwin option
Changed line 304 from:

PuTTY Tray

to:

PuTTY Tray

Changed lines 316-325 from:
to:

Using Cygwin

Cygwin is a Linux-like environment for Windows. With it you can install the latest OpenSSH? package and use it from the command line the same way you would in Linux. A good step-by-step installation tutorial can be found at http://pigtail.net/LRP/printsrv/cygwin-sshd.html. Another option is CopSSH which installs a minimalistic version of Cygwin specifically meant for running OpenSSH?.

Once OpenSSH? is installed, create a virtual network adapter in Windows as explained above. To make an SSH connection and tunnel the SMB protocol (port 445), use the following command:

C:\cygwin\bin\ssh.exe -ax -c blowfish -L 10.0.0.222:445:127.0.0.1:445 root@10.0.0.98

Where 10.0.0.222 is the IP address of your virtual network adapter (the other switches should speed up the connection a bit; you can also specify -C for SSH compression.) You should now be able to click Start/Run and type in \\10.0.0.222 to see your NSLU2 folders.

October 29, 2007, at 12:02 AM by -DC- -- Added FileZilla link
Changed lines 48-49 from:

(You might like to use WinSCP instead/as well. This allows FTP-like access to your files over the secure SSH connection.)

to:

(You might like to use WinSCP or FileZilla instead/as well. These allow FTP-like access to your files over the secure SSH connection.)

September 24, 2007, at 08:32 PM by fcarolo -- removed false wikilinks
Changed line 157 from:
 BusyBox? v0.60.4 (2005.03.22-06:52+0000) Built-in shell (ash)
to:
 BusyBox v0.60.4 (2005.03.22-06:52+0000) Built-in shell (ash)
Changed lines 250-251 from:

If you wanto to use sftp, then you need to install also the package openssh-sftp (At least I need it -thx1011). On OpenSlug 2.7Beta even after installing package openssh, you need this one. Then you can use, for example on windows side, the WinSCP freeware program, ou also, the integrated SFTP client into OpenSSH? windows client. This will allow file transfer using SSH for remote access without exposing your Samba shares.

to:

If you wanto to use sftp, then you need to install also the package openssh-sftp (At least I need it -thx1011). On OpenSlug 2.7Beta even after installing package openssh, you need this one. Then you can use, for example on windows side, the WinSCP freeware program, ou also, the integrated SFTP client into OpenSSH windows client. This will allow file transfer using SSH for remote access without exposing your Samba shares.

Changed lines 300-301 from:

Note-to-the-note: On my XPSP2? box I've had success adding the loopback adapter using a fixed IP and only disabling "File And Printer Sharing for Microsoft Networks" and "NetBIOS? over TCP/IP" (leaving all other settings at default). This gets port 139 working (though not 445) and my shares seem quite happy to run through SSH. (Use "Add New Hardware", assign a fixed IP address, click on "Advanced", go to the "WINS" tab and select "Disable NetBIOS? over TCP/IP".)

to:

Note-to-the-note: On my XP SP2 box I've had success adding the loopback adapter using a fixed IP and only disabling "File And Printer Sharing for Microsoft Networks" and "NetBIOS over TCP/IP" (leaving all other settings at default). This gets port 139 working (though not 445) and my shares seem quite happy to run through SSH. (Use "Add New Hardware", assign a fixed IP address, click on "Advanced", go to the "WINS" tab and select "Disable NetBIOS over TCP/IP".)

Changed lines 304-305 from:

PuTTY? Tray

PuTTY? Tray (http://www.xs4all.nl/~whaa/putty/) can be used instead of plink. The main advantage is that you don't need plink running in a window continuously. Instead, you can make it start minimized in the systray.\\

to:

PuTTY Tray

PuTTY Tray (http://www.xs4all.nl/~whaa/putty/) can be used instead of plink. The main advantage is that you don't need plink running in a window continuously. Instead, you can make it start minimized in the systray.\\

Changed line 308 from:

-make a profile in PuTTY? Tray (e.g. call it 'sshtunnel')\\

to:

-make a profile in PuTTY Tray (e.g. call it 'sshtunnel')\\

September 24, 2007, at 12:42 AM by HN --
Added line 311:

-in Connection>SSH>Auth, point to your .ppk key file

September 24, 2007, at 12:40 AM by HN --
Changed line 305 from:

<a href='http://www.xs4all.nl/~whaa/putty/'>PuTTY? Tray</a> can be used instead of plink. The main advantage is that you don't need plink running in a window continuously. Instead, you can make it start minimized in the systray.\\

to:

PuTTY? Tray (http://www.xs4all.nl/~whaa/putty/) can be used instead of plink. The main advantage is that you don't need plink running in a window continuously. Instead, you can make it start minimized in the systray.\\

September 24, 2007, at 12:39 AM by HN -- Added PuTTY Tray
Added lines 304-315:

PuTTY? Tray

<a href='http://www.xs4all.nl/~whaa/putty/'>PuTTY? Tray</a> can be used instead of plink. The main advantage is that you don't need plink running in a window continuously. Instead, you can make it start minimized in the systray.

Settings:
-make a profile in PuTTY? Tray (e.g. call it 'sshtunnel')
-in Window>behaviour, set minimize to tray on start
-in Connection>data, set (e.g.) root as auto-login username
-in Connection>SSH>Tunnels, type '10.0.0.1:139' in the 'Source port' field, and '127.0.0.1:139' in the 'Destination' field. Replace 10.0.0.1 by whatever the ip of your MS loopback interface is.
-save the profile
-make a shortcut on your desktop; make it call putty.exe -load "sshtunnel"

August 27, 2007, at 03:34 PM by fcarolo -- fixed false wikilink
Changed line 365 from:

Installing DenyHosts? (http://denyhosts.sourceforge.net/) or another program with similar functionality will help stop this.

to:

Installing DenyHosts (http://denyhosts.sourceforge.net/) or another program with similar functionality will help stop this.

August 25, 2007, at 06:06 PM by morrijr -- DenyHosts
Added line 365:

Installing DenyHosts? (http://denyhosts.sourceforge.net/) or another program with similar functionality will help stop this.

July 16, 2007, at 09:43 AM by Dave Lane -- Removed Default comment about puTTYgen
Changed lines 58-59 from:

Notice: Make sure you are generating an SSH-2 RSA key in puttygen, neither SSH-1 nor SSH-2 DSA (which is the default), as these keys won't work (at least that was my problem keeping me busy for hours...) (Peter, 1/27/2007)

to:

Notice: Make sure you are generating an SSH-2 RSA key in puttygen, neither SSH-1 nor SSH-2 DSA, as these keys won't work (at least that was my problem keeping me busy for hours...) (Peter, 1/27/2007)

May 07, 2007, at 06:52 PM by Andreas --
Changed line 99 from:

Now let's copy the public key to the authorized_keys file in the NSLU2. This can be done easily if you have the key copied to the Windows clipboard, using an echo command to write to the file. Use a command line like this, typing echo, pasting the public key inside the telnet session and ending with the redirection (>authorized_keys) (the key here has been shortened for display purposes, your generated key will be a much longer string):

to:

Now let's copy the public key to the /root/.ssh/authorized_keys file in the NSLU2. This can be done easily if you have the key copied to the Windows clipboard, using an echo command to write to the file. Use a command line like this, typing echo, pasting the public key inside the telnet session and ending with the redirection (>authorized_keys) (the key here has been shortened for display purposes, your generated key will be a much longer string):

Deleted line 101:
 cd /root/.ssh
May 07, 2007, at 06:51 PM by Andreas -- Added cd to directory of authorized_keys
Added line 102:
 cd /root/.ssh
March 26, 2007, at 12:46 PM by david -- fixed link mistake
Changed lines 261-262 from:

If working with *nix systems, you can mount your your data on the NSLU2 via either LUFS or SHFS. I have found SHFS a bit easier to work with than LUFS, but if you're working with encrypted file systems LUFS is the way to go. SHFS requires Perl to be installed on the NSLU2, which is conveniently available as a package(http://www.nslu2-linux.org/wiki/HowTo/BuildPerlOnYourNSLU2Box). For the mounting in SHFS, make sure all binaries and mount points have the appropriate ownership and accessibility.

to:

If working with *nix systems, you can mount your your data on the NSLU2 via either LUFS or SHFS. I have found SHFS a bit easier to work with than LUFS, but if you're working with encrypted file systems LUFS is the way to go. SHFS requires Perl to be installed on the NSLU2, which is conveniently available as a package (ipkg install perl). For the mounting in SHFS, make sure all binaries and mount points have the appropriate ownership and accessibility.

March 26, 2007, at 12:43 PM by david -- Added SHFS instructions for mounting
Added lines 260-262:

Mounting files via SHFS

If working with *nix systems, you can mount your your data on the NSLU2 via either LUFS or SHFS. I have found SHFS a bit easier to work with than LUFS, but if you're working with encrypted file systems LUFS is the way to go. SHFS requires Perl to be installed on the NSLU2, which is conveniently available as a package(http://www.nslu2-linux.org/wiki/HowTo/BuildPerlOnYourNSLU2Box). For the mounting in SHFS, make sure all binaries and mount points have the appropriate ownership and accessibility.

March 15, 2007, at 09:27 PM by vatachino --
Changed lines 39-40 from:

Note:: At this point, you can access your slug using an SSH client by typing in the root password, as you did for telnet access. This is still more secure than telnet because the password is encrypted. If you aren't going to be SSH-ing into your slug regularly, you probably don't need to set up public keys as described below.

to:

Note:: At this point, you can access your slug using an SSH client by typing in the root password, as you did for telnet access. While the security-paranoid won't be happy with this and will want to disable password access as described below, it is still more secure than telnet because the password is encrypted. If your slug is on a private network behind a firewall, then there is probably no need to go any further.

March 15, 2007, at 09:21 PM by vatachino -- Add info about using SSH without key setup
Added lines 39-40:

Note:: At this point, you can access your slug using an SSH client by typing in the root password, as you did for telnet access. This is still more secure than telnet because the password is encrypted. If you aren't going to be SSH-ing into your slug regularly, you probably don't need to set up public keys as described below.

January 28, 2007, at 12:16 AM by Peter --
Changed lines 56-57 from:

Make sure you are generating an SSH-2 RSA key in puttygen, neither SSH-1 nor SSH-2 DSA (which is the default), as these keys won't work (at least that was my problem keeping me busy for hours...)

to:

Notice: Make sure you are generating an SSH-2 RSA key in puttygen, neither SSH-1 nor SSH-2 DSA (which is the default), as these keys won't work (at least that was my problem keeping me busy for hours...) (Peter, 1/27/2007)

January 28, 2007, at 12:14 AM by Peter --
Added lines 56-57:

Make sure you are generating an SSH-2 RSA key in puttygen, neither SSH-1 nor SSH-2 DSA (which is the default), as these keys won't work (at least that was my problem keeping me busy for hours...)

December 31, 2006, at 09:47 AM by MattMcNeill -- Tidying up SAMBA tunnelling info
Changed lines 262-263 from:

Bitvise Tunnelier (http://www.bitvise.com)is free for personal use and makes it very easy to set up regular port tunnelling sessions, using shared keys or passwords. There is also an excellent HowTo for setting up and configuring the port-formwarding interfaces for Windows http://www.bitvise.com/file-sharing which may also be useful for people with general questions on how to tunnel samba shares.

to:

Bitvise Tunnelier (http://www.bitvise.com)is free for personal use and makes it very easy to set up regular port tunnelling sessions, using shared keys or passwords. There is also an excellent HowTo for setting up and configuring the port-forwarding interfaces for Windows

http://www.bitvise.com/file-sharing

which may also be useful for people with general questions on how to tunnel samba shares, with instructions for setting up loopback interfaces in XP etc.

December 31, 2006, at 09:44 AM by MattMcNeill -- Added Link to external SAMBA tunelling howto
Changed lines 238-239 from:

Better Interactivity

to:

Better Interactivity

Changed lines 244-245 from:

Secure Copy

to:

Secure Copy

Changed lines 252-253 from:

Remote access to files over SSH

to:

Remote access to files over SSH

Changed lines 258-259 from:

Remote access to Samba shares over SSH

to:

Remote access to Samba (Windows) shares over SSH

Using Bitvise Tunnelier

Bitvise Tunnelier (http://www.bitvise.com)is free for personal use and makes it very easy to set up regular port tunnelling sessions, using shared keys or passwords. There is also an excellent HowTo for setting up and configuring the port-formwarding interfaces for Windows http://www.bitvise.com/file-sharing which may also be useful for people with general questions on how to tunnel samba shares.

Using Putty

Changed lines 295-296 from:

A security story

to:

Change root jail

The following page describes how to setup a change root jail at our Slug : ChrootJailForSFTP


A security story

Deleted lines 353-357:

Change root jail

The following page describes how to setup a change root jail at our Slug : ChrootJailForSFTP

December 26, 2006, at 04:54 AM by drdave -- Spelling correction
Changed line 224 from:

Save the public key to the authrized_keys file, just like you did for root, and adjust the permissions for that file:

to:

Save the public key to the authorized_keys file, just like you did for root, and adjust the permissions for that file:

December 12, 2006, at 12:21 PM by fcarolo -- fixed wiki link
Changed lines 213-214 from:

In your Windows machine, run PuTTYgen? again and generate a new key pair. Protect the new private key with a passphrase and save it to file, this key will be used by the new user when he wants to login to the slug. Also remember to set the key comment for the new public key to username@hostaname, copy the entire key text to the clipboard and save the public key to a text file (for safety).

to:

In your Windows machine, run PuTTYgen again and generate a new key pair. Protect the new private key with a passphrase and save it to file, this key will be used by the new user when he wants to login to the slug. Also remember to set the key comment for the new public key to username@hostaname, copy the entire key text to the clipboard and save the public key to a text file (for safety).

December 12, 2006, at 12:13 PM by fcarolo -- added info about creating other users
Changed lines 1-2 from:

typoThis howto covers the setup and usage of the OpenSSH secure shell for remote command line access on Unslung. If you are switching from Dropbear, see also SwapFromDropbearToOpenSSH.

to:

This howto covers the setup and usage of the OpenSSH secure shell for remote command line access on Unslung. If you are switching from Dropbear, see also SwapFromDropbearToOpenSSH.

Added lines 7-13:
Changed line 48 from:

Now we need to generate a pair of private/public key pair. Run Start->Programs->PuTTY->PuTTYGen, the key generation program and click the "Generate" button to generate a new key pair. In the top part of the window you will see a text box showing the generated public key string, something like the following (the key here has been shortened for display purposes, your generated key will be a much longer string):

to:

Now we need to generate a private/public key pair. Run Start->Programs->PuTTY->PuTTYgen, the key generation program, and click the "Generate" button to generate a new key pair. In the top part of the window you will see a text box showing the generated public key string, something like the following (the key here has been shortened for display purposes, your generated key will be a much longer string):

Changed lines 56-57 from:

Set your passphrase by typing it in the "Key passphrase" box and repeat it in the "Confirm passphrase". Make this passphrase reasonably long (>8 characters), easy to remember, and significant to you but not to anyone else. This is especially true if you plan to make the NSLU2 visible on the Internet. Click on "Save private key" and save your private key to a file with the .ppk extension after setting a passphrase to encrypt it.

to:

Set your passphrase by typing it in the "Key passphrase" box and repeat it in the "Confirm passphrase". Make this passphrase reasonably long (>8 characters), easy to remember and significant to you but not to anyone else. This is especially true if you plan to make the NSLU2 visible on the Internet. Click on "Save private key" and save your private key to a file with the .ppk extension after setting a passphrase to encrypt it.

Changed lines 63-64 from:

Configure SSH Server For Public Key Access

to:

Configure SSH Server for Public Key Access

Changed line 109 from:

Finally, check that the authorized_keys file is not accessible by anyone but the current user (i.e. have a mask like -rwx------ when you do an ls -l):

to:

Finally, check that the authorized_keys file is not accessible by anyone but the current user (i.e. have a mask like -rw------- when you do an ls -l):

Changed line 115 from:

Ok, so that should get us ready for authentication using a public key. Furthermore we can prevent anyone logging in via SSH without a key. To do this we need to do edit the sshd_config file. Use nano or any editor of your choice to edit the file:

to:

Ok, so that should get us ready for authentication using a public key. Furthermore, we can prevent anyone logging in via SSH without a key. To do this we need to edit the sshd_config file. Use nano or an editor of your choice to edit the file:

Changed lines 146-149 from:
 Enter the passphrase for root@slug: 
 Authenticating with public key "root@slug" from agent
 BusyBox v0.60.4 (2004.07.01-03:05+0000) Built-in shell (ash)
 Enter 'help' for a list of built-in commands.
to:
 Authenticating with public key "root@SLUG"
 Passphrase for key "root@SLUG":
Added lines 149-155:
 Welcome to Unslung V2.3R63-uNSLUng-6.8-beta

 ---------- NOTE: THIS SYSTEM IS CURRENTLY UNSLUNG ----------

 BusyBox? v0.60.4 (2005.03.22-06:52+0000) Built-in shell (ash)
 Enter 'help' for a list of built-in commands.
Changed lines 159-160 from:

Voila!!

to:

Voilą!!

Changed lines 164-167 from:

Configuring SSH Authentication for Other Users

WARNING: this section is being updated, please wait one day or two before using these instructions. fcarolo December 11, 2006, at 10:15 PM

to:

Configure SSH Authentication for Other Users

Changed line 172 from:
 username:scK54m082CMzI:2001:501:::/dev/null
to:
 username:scwAynQfOwmF.:2000:501:Some user::/dev/null
Changed lines 178-222 from:
So you will need to change the last two items, in the previous example that would be:
USERNAME:scK54m082CMzI:2001:501::/USERNAME:/bin/sh
Notes:
a. Allocating the user with a working path in /etc/passwd renders the ftp capabilities useless
b. Allocating the user with a shell enables each user to log in to the shell also in telnet (assuming it is enabled)

The important thing will be to ensure that the directory is set up with appropriate permissions and also that the parent directories (remember the /root setup?) have appropriate permissions both for the public and for the groups. Once this folder has been created, then follow steps (5) to (7) to create keys for the user. Follow up by chowning the newly created folder to the new user, e.g.

# chown -R mynewuser:everyone /home/mynewuserhome

You may wish to add additional users via the adduser tool (a tool which is installable via ipkg). You will discover that after a user is created with adduser and a password was assigned, the password will be lost on next server restart. See ChangePasswordsFromTheCommandLine for info on how to correctly set up a persistent password via the command line.

Other Notes

Better Interactivity

You might want to consider overclocking the NSLU2 so that it'll run at full speed instead of half speed as supplied by Linksys.


Secure Copy

If you wanto to use sftp, then you need to install also the package openssh-sftp (At least I need it -thx1011). On OpenSlug 2.7Beta even after installing package openssh, you need this one. Then you can use, for example on windows side, the WinSCP freeware program, ou also, the integrated SFTP client into OpenSSH? windows client. This will allow file transfer using SSH for remote access without exposing your Samba shares.

If you want to use KDE for accessing the file on your slung ala fish://root@192.168.1.2:22/ you have to install perl (ipkg install perl) in addition to openssh and openssl.


Remote access to files over SSH

If you want to be able to access your files, upload and download over SSH then you need an SCP client. For myself, wanting to access my files over the internet securely from my Windows box at work, I downloaded WinSCP (http://winscp.net/) and simply configured it up, by entering the IP address, pointing to the key file and entering the username. It worked out of the box, I could browse all the files on the SLUG as if logged in to console.


Remote access to Samba shares over SSH

If you want to view Samba shares over SSH then you need to follow the following instructions - worked perfectly for me.

http://lists.samba.org/archive/samba/2004-May/085358.html

I have created a batch file which I use to run PLINK (part of Putty) with the tunnel settings (so no console window is necessary) as follows:

(:table border=0 width=100% bgcolor=#eeffee:)

to:

You have to define a home directory and change the login shell. The home directory can be a new directory created under /home, as usual for Linux boxes. The login shell must be changed from /dev/null to /bin/sh.

Open /etc/passwd in your favorite text editor, such as nano: (:table border=0 width=80% bgcolor=#eeffee:)

Changed lines 183-193 from:

@echo off

".\plink.exe" username@myserver.ipaddress.com -ssh -N -v -batch -L 10.0.0.1:139:127.0.0.1:139 -L 10.0.0.1:445:127.0.0.1:445 -L 10.0.0.1:80:127.0.0.1:80 -L 10.0.0.1:443:127.0.0.1:443 -L 10.0.0.1:901:127.0.0.1:901 -L 10.0.0.1:8080:127.0.0.1:8080 -L 10.0.0.1:6667:127.0.0.1:6667 -L 10.0.0.1:9180:mynetworkgatewayipaddress:80 -L 10.0.0.1:21:ftp.myispwebpageuploadserver.com:21

REM If you are running Windows 95 or 98, you can uncomment the following "choice" line to REM insert a delay of 5 seconds before the connection tries to re-establish.

REM choice /cX /t:X,5 > nul REM call tunnel.bat

to:
 nano /etc/passwd
Changed lines 186-191 from:

Note: the only ports you need to expose for SAMBA are 139 and 445. This assumes you have set up the loopback adapter on 10.0.0.1 and removed all the bound services except TCP/IP as described in the page linked to above.

Note-to-the-note: On my XPSP2? box I've had success adding the loopback adapter using a fixed IP and only disabling "File And Printer Sharing for Microsoft Networks" and "NetBIOS? over TCP/IP" (leaving all other settings at default). This gets port 139 working (though not 445) and my shares seem quite happy to run through SSH. (Use "Add New Hardware", assign a fixed IP address, click on "Advanced", go to the "WINS" tab and select "Disable NetBIOS? over TCP/IP".)

Note: to use create a file called tunnel.bat in the same folder as plink.exe. Load your keys into Pageant as normal and then simply run the batch file. remember that you need to have opened the SSH port (22) in your firewall etc as you would for SSH console sessions.

to:

Now locate the line for the user you have just created and change the home directory (the sixth field of the line) to /home/username. For example, if the new username is john, set the directory to /home/john:

(:table border=0 width=80% bgcolor=#eeffee:) (:cell:)

 john:scwAynQfOwmF.:2000:501:John Smith:/home/john:/dev/null

(:tableend:)

Finally, change the login shell (the last field) to /bin/sh: (:table border=0 width=80% bgcolor=#eeffee:) (:cell:)

 john:scwAynQfOwmF.:2000:501:John Smith:/home/john:/bin/sh

(:tableend:)

After that, can just save the file.

Notice: if you change the login shell for an user account, you should be aware that this user will also be able to login using telnet, if the telnet server is enabled through the web interface.

Now we need to create the home directory for the user and set the appropriate permissions. Following our example, where the directory is /home/john: (:table border=0 width=80% bgcolor=#eeffee:) (:cell:)

 mkdir /home/john
 chown john:everyone /home/john
 chmod og-w /home/john

(:tableend:)

If you are using passwords to login via ssh, this is all you need to do. However, if you are using public key authentication, you will have to follow the steps mentioned above again to create a new key pair and save the public key in the authorized_keys file for the new user.

In your Windows machine, run PuTTYgen? again and generate a new key pair. Protect the new private key with a passphrase and save it to file, this key will be used by the new user when he wants to login to the slug. Also remember to set the key comment for the new public key to username@hostaname, copy the entire key text to the clipboard and save the public key to a text file (for safety).

Use telnet to login to the slug as the new user, in order to create the .ssh directory: (:table border=0 width=80% bgcolor=#eeffee:) (:cell:)

 cd ~
 mkdir .ssh
 chmod og= .ssh
 cd .ssh

(:tableend:)

Save the public key to the authrized_keys file, just like you did for root, and adjust the permissions for that file: (:table border=0 width=80% bgcolor=#eeffee:) (:cell:)

 echo ssh-rsa AAAAB3NzaC1yc2EAAAABIwAA...aJ3Wy+Ws4IZEgdJgPlTYUBWWtCWOGc= john@hostname > authorized_keys
 chmod og= authorized_keys

(:tableend:)

Now, use PuTTY to connect as the new user. Remember to use SSH as the protocol and set the private key file (under the "Category" menu, "Connection", "SSH", "Auth") to the new one that you have just created.

Notice: you may wish to add additional users via the adduser tool (a tool which is installable via ipkg). You will discover that after a user is created with adduser and a password was assigned, the password will be lost on next server restart. See ChangePasswordsFromTheCommandLine for info on how to correctly set up a persistent password via the command line.

Other Notes

Better Interactivity

You might want to consider overclocking the NSLU2 so that it'll run at full speed instead of half speed as supplied by Linksys.

Added lines 244-288:

Secure Copy

If you wanto to use sftp, then you need to install also the package openssh-sftp (At least I need it -thx1011). On OpenSlug 2.7Beta even after installing package openssh, you need this one. Then you can use, for example on windows side, the WinSCP freeware program, ou also, the integrated SFTP client into OpenSSH? windows client. This will allow file transfer using SSH for remote access without exposing your Samba shares.

If you want to use KDE for accessing the file on your slug ala fish://root@192.168.1.2:22/ you have to install perl (ipkg install perl) in addition to openssh and openssl.


Remote access to files over SSH

If you want to be able to access your files, upload and download over SSH then you need an SCP client. For myself, wanting to access my files over the internet securely from my Windows box at work, I downloaded WinSCP (http://winscp.net/) and simply configured it up, by entering the IP address, pointing to the key file and entering the username. It worked out of the box, I could browse all the files on the SLUG as if logged in to console.


Remote access to Samba shares over SSH

If you want to view Samba shares over SSH then you need to follow the following instructions - worked perfectly for me.

http://lists.samba.org/archive/samba/2004-May/085358.html

I have created a batch file which I use to run PLINK (part of Putty) with the tunnel settings (so no console window is necessary) as follows:

(:table border=0 width=100% bgcolor=#eeffee:) (:cell:)

@echo off

".\plink.exe" username@myserver.ipaddress.com -ssh -N -v -batch -L 10.0.0.1:139:127.0.0.1:139 -L 10.0.0.1:445:127.0.0.1:445 -L 10.0.0.1:80:127.0.0.1:80 -L 10.0.0.1:443:127.0.0.1:443 -L 10.0.0.1:901:127.0.0.1:901 -L 10.0.0.1:8080:127.0.0.1:8080 -L 10.0.0.1:6667:127.0.0.1:6667 -L 10.0.0.1:9180:mynetworkgatewayipaddress:80 -L 10.0.0.1:21:ftp.myispwebpageuploadserver.com:21

REM If you are running Windows 95 or 98, you can uncomment the following "choice" line to REM insert a delay of 5 seconds before the connection tries to re-establish.

REM choice /cX /t:X,5 > nul REM call tunnel.bat

(:tableend:)

Note: the only ports you need to expose for SAMBA are 139 and 445. This assumes you have set up the loopback adapter on 10.0.0.1 and removed all the bound services except TCP/IP as described in the page linked to above.

Note-to-the-note: On my XPSP2? box I've had success adding the loopback adapter using a fixed IP and only disabling "File And Printer Sharing for Microsoft Networks" and "NetBIOS? over TCP/IP" (leaving all other settings at default). This gets port 139 working (though not 445) and my shares seem quite happy to run through SSH. (Use "Add New Hardware", assign a fixed IP address, click on "Advanced", go to the "WINS" tab and select "Disable NetBIOS? over TCP/IP".)

Note: to use create a file called tunnel.bat in the same folder as plink.exe. Load your keys into Pageant as normal and then simply run the batch file. remember that you need to have opened the SSH port (22) in your firewall etc as you would for SSH console sessions.


December 11, 2006, at 10:49 PM by fcarolo -- typo
Changed lines 1-2 from:

This howto covers the setup and usage of the OpenSSH secure shell for remote command line access on Unslung. If you are switching from Dropbear, see also SwapFromDropbearToOpenSSH.

to:

typoThis howto covers the setup and usage of the OpenSSH secure shell for remote command line access on Unslung. If you are switching from Dropbear, see also SwapFromDropbearToOpenSSH.

Changed lines 94-95 from:

Noticee: you can use a regular text editor, like vi or nano, to create the authorized_keys file. Just make sure that the whole key is on a single line. If you are using nano, start it with nano -w so you won't problems with long lines.

to:

Notice: you can use a regular text editor, like vi or nano, to create the authorized_keys file. Just make sure that the whole key is on a single line. If you are using nano, start it with nano -w so you won't problems with long lines.

December 11, 2006, at 10:24 PM by fcarolo -- update and cleanup
Changed lines 10-11 from:

First of all, let's assume you have already installed Unslung? and have activated the built-in telnet server. After you have installed OpenSSH you will no longer need telnet.

to:

First of all, let's assume you have already installed Unslung and have activated the built-in telnet server. After you have installed OpenSSH you will no longer need telnet.

Changed lines 32-34 from:

Notice: if you are switching from Dropbear you can stop it from running and free some memory. Either remove it after installing OpenSSH (run ipkg remove dropbear) or remove the init script that starts Dropbear by running rm /opt/etc/init.d/S51dropbear.

#client#

to:

Notice: if you are switching from Dropbear you can stop it from running and free some memory. Either remove it after installing OpenSSH (run ipkg remove dropbear) or remove the init script that starts Dropbear by running rm /opt/etc/init.d/S51dropbear.

Changed lines 39-41 from:

(You might like to use WinSCP instead/as well. This allows FTP-like access to your files over the secure SSH connection.)

Now we need to generate a pair of private/public key pair. Run Start->Programs->PuTTY->PuTTYGen, the key generation program and click the "Generate" button to generate a new key pair. In the top part of the window you will see a text box showing the generated public key string, something like the following (the key here has been shortened for display purposes, your generated key will be a much longer string):\\

to:

(You might like to use WinSCP instead/as well. This allows FTP-like access to your files over the secure SSH connection.)

Now we need to generate a pair of private/public key pair. Run Start->Programs->PuTTY->PuTTYGen, the key generation program and click the "Generate" button to generate a new key pair. In the top part of the window you will see a text box showing the generated public key string, something like the following (the key here has been shortened for display purposes, your generated key will be a much longer string):

Deleted line 79:
  1. Change to the home directory:\\
Changed line 88 from:

Now let's copy the public key to the authorized_keys file in the NSLU2. This can be done easily if you have the key copied to the Windows clipboard, using an echo command to write to the file. Use a command line like this, typing echo, pasting the public key inside the telnet session and ending with the redirection (>authorized_keys): (the key here has been shortened for display purposes, your generated key will be a much longer string):

to:

Now let's copy the public key to the authorized_keys file in the NSLU2. This can be done easily if you have the key copied to the Windows clipboard, using an echo command to write to the file. Use a command line like this, typing echo, pasting the public key inside the telnet session and ending with the redirection (>authorized_keys) (the key here has been shortened for display purposes, your generated key will be a much longer string):

Changed lines 94-96 from:

Note: you can use a regular text editor, like vi or nano, to create the authorized_keys file. Just make sure that the whole key is on a single line. If you are using nano, start it with nano -w so you won't problems with long lines.

''Note: echo is a command which prints what ever follows it to the standard output (usually the screen). So if you type "echo hello" at the prompt of a telnet session to the slug, the terminal will print "hello" to the screen.\\

to:

Noticee: you can use a regular text editor, like vi or nano, to create the authorized_keys file. Just make sure that the whole key is on a single line. If you are using nano, start it with nano -w so you won't problems with long lines.

Notice: echo is a command which prints what ever follows it to the standard output (usually the screen). So if you type "echo hello" at the prompt of a telnet session to the slug, the terminal will print "hello" to the screen.\\

Changed lines 100-102 from:

There are others, such as copying the file across to one of the Samba (Windows) shares and then moving it, but this way seemed to be the simplest (albeit arcane).''

Finally, check that the authorized_keys file is not accessible by anyone but the current user (i.e. have a mask like -rwx------ when you do an ls -l):

to:

There are others, such as copying the file across to one of the Samba (Windows) shares and then moving it, but this way seemed to be the simplest (albeit arcane).

Finally, check that the authorized_keys file is not accessible by anyone but the current user (i.e. have a mask like -rwx------ when you do an ls -l):

Changed line 108 from:

Ok, so that should get us ready for authentication using a public key. Furthermore we can prevent anyone logging in via SSH without a key. To do this we need to do edit the sshd_config file. Use nano or any editor of your choice to edit the file:

to:

Ok, so that should get us ready for authentication using a public key. Furthermore we can prevent anyone logging in via SSH without a key. To do this we need to do edit the sshd_config file. Use nano or any editor of your choice to edit the file:

Changed lines 120-121 from:

Note: for the full set of configuration details for this file see the sshd_config man page.

to:

Notice: for the full set of configuration details for this file see the sshd_config man page.

Changed lines 149-150 from:

If you're still asked for a password, carefully check the file permissions through the whole path of ~/.ssh/. Hints are written to /var/log/messages, like Authentication refused: bad ownership or modes for directory /home/user/.ssh. .ssh should have mode 700 (rwx------), authorized_keys should have mode 600 (rw-------).

to:

If you're still asked for a password, carefully check the file permissions through the whole path of ~/.ssh/. Hints are written to /var/log/messages, like Authentication refused: bad ownership or modes for directory /home/user/.ssh. Check the permissions: .ssh should have mode 700 (rwx------), authorized_keys should have mode 600 (rw-------).

Changed lines 154-155 from:

WARNING: this section is being updated, please wait one day or two before using these instructions. fcarolo December 11, 2006, at 10:15 PM

to:

WARNING: this section is being updated, please wait one day or two before using these instructions. fcarolo December 11, 2006, at 10:15 PM

December 11, 2006, at 10:15 PM by fcarolo -- update and cleanup
Changed lines 1-81 from:

This howto covers the setup and usage of the OpenSSH secure shell for remote command line access. see also SwapFromDropbearToOpenSSH

OpenSSH is a fully featured daemon which also requires the OpenSSL libraries. It is more sophisticated than DropBear and has more advanced features such as agent forwarding. It may also get around some of the multiple user problems that people experienced with DropBear.

I have a Windows 2000 machine which I want to be able to use from work (behind a number of firewalls) to access the slug on my home broadband network. So what do I need to do?

Install SSH daemon On Unslung

  1. Unsling your slug - see Unslung
  2. Install the OpenSSH package which gives you your SSH daemon. You can do this by executing the following via telnet.

    # ipkg update
    # ipkg install openssh (note: this may take a while to generate keys)
  3. Reboot and check OpenSSH is running.

    # ps -ef

    And look for a line something like the following:

    1735 root 3208 R /opt/sbin/sshd

OK so it's running. What the heck do you do now? If you already know ssh then you can stop at this point because SSH is installed and working. If you want to perform additional configuration then read on.
(Note: You can stop dropbear now and free some memory, just do the following steps: Goto /etc/rc3.d and delete de S10dropbear link. Note, this will not remove Dropbear from your Slug, but only won't start it for run level 3.)

Install and Configure SSH Client

  1. You need to get an SSH client for your Windows box.

    Putty is good free client so that's what I'm going to talk about here. Download it and install.

    (You might like to use WinSCP instead/as well. This allows FTP-like access to your files over the secure SSH connection.)
  2. Now we need to generate some keys.

    * So run Start->Programs->Putty->Puttygen key generation program.
    * Click the "generate" button to generate some new keys.

    In the top part of the window you will see a public key string something like the following (The key here has been shortened for display purposes. Your generated key will be a much longer string):

    ssh-rsa AAAAB3NzaC1yc2EAAAABIwAA......aJ3Wy+Ws4IZEgdJgPlTYUBWWtCWOGc= someone@hostname

    This is what is called a public key. We'll get back to this in a moment.
  3. Save your private key pair (*.ppk) file with a passphrase to encrypt it.

    Make this passphrase reasonably long (>8 characters), easy to remember, and significant to you but not to anyone else. This is especially true if you plan to make the NSLU2 visible on the Internet.
  4. Copy the public key (similar to the "ssh-rsa" string above) to the clipboard.

    Now what we need to do is load that public key as an authorized key for 'root'. We'll look at other users later on.

Configure SSH Server With Public Key

For this example, we will be working to authorize the 'root' user to use SSH.

  1. First of all telnet into the SLUG as the user we want to authorise (e.g. root)

    Since this setting does not persist after slug reboots, don't forget to authorize this by going to

    http://(slug IP address)/Management/telnet.cgi.
  2. Look in your telnet session and see if it came up with a message stating that the home directory could not be found.

    If you see this message, you need to create one and ensure that the permissions are correct. Permissions are very important, since OpenSSH checks them very carefully before allowing logins authenticated by keys.

    # mkdir /root
    # chmod a+rx /root
    # chmod og-w /root

    This should result in a folder which everyone can read but no-one but the owner (i.e. root) can write. Check this by:

    # ls -l /

    And look for a line which looks like the following (noting the dwrx-rx-rx particularly)

    drwxr-xr-x 1 root root 0 Jan 30 16:21 root
to:

This howto covers the setup and usage of the OpenSSH secure shell for remote command line access on Unslung. If you are switching from Dropbear, see also SwapFromDropbearToOpenSSH.

OpenSSH is a fully featured daemon which also requires the OpenSSL libraries. It is more sophisticated than Dropbear and has more advanced features such as agent forwarding. It may also get around some of the multiple user problems that people experienced with Dropbear.

This howto focus on the steps needed to setup OpenSSH under Unslung and use PuTTY, an SSH client for Windows, to access to your slug.

Install OpenSSH Server on Unslung

First of all, let's assume you have already installed Unslung? and have activated the built-in telnet server. After you have installed OpenSSH you will no longer need telnet.

Install the OpenSSH package for Unslung, which includes the SSH daemon. You can do this by executing the following commands from a telnet session: (:table border=0 width=80% bgcolor=#eeffee:) (:cell:)

 ipkg update
 ipkg install openssh   (note: this may take a while to generate keys)

(:tableend:)

After installing the package, the OpenSSH server should be running. You can confirm this by running: (:table border=0 width=80% bgcolor=#eeffee:) (:cell:)

 ps -ef

(:tableend:) and look for a line something like the following: (:table border=0 width=80% bgcolor=#eeffee:) (:cell:)

 1735         root       3208   R   /opt/sbin/sshd

(:tableend:)

Ok, so it's running. What the heck do you do now? If you are already familiar with OpenSSH then you can stop at this point because SSH is installed and working. If you want to perform additional configuration to use public key authentication, then read on. Do not close your telnet session, we will have to configure the server later on.

Notice: if you are switching from Dropbear you can stop it from running and free some memory. Either remove it after installing OpenSSH (run ipkg remove dropbear) or remove the init script that starts Dropbear by running rm /opt/etc/init.d/S51dropbear.

#client#

Install and Configure PuTTY in Windows

You need to get an SSH client for your Windows box. PuTTY is good free client so that's what I'm going to talk about here. Download the Windows installer from http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html and install it.

(You might like to use WinSCP instead/as well. This allows FTP-like access to your files over the secure SSH connection.)

Now we need to generate a pair of private/public key pair. Run Start->Programs->PuTTY->PuTTYGen, the key generation program and click the "Generate" button to generate a new key pair. In the top part of the window you will see a text box showing the generated public key string, something like the following (the key here has been shortened for display purposes, your generated key will be a much longer string):
(:table border=0 width=80% bgcolor=#eeffee:) (:cell:)

 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAA...aJ3Wy+Ws4IZEgdJgPlTYUBWWtCWOGc= rsa-key-20061210

(:tableend:)

This is what we call the public key. It will be copied to the slug in the next section. Before that, we have to protect your private key (not shown) with a passphrase and save it to a file.

Set your passphrase by typing it in the "Key passphrase" box and repeat it in the "Confirm passphrase". Make this passphrase reasonably long (>8 characters), easy to remember, and significant to you but not to anyone else. This is especially true if you plan to make the NSLU2 visible on the Internet. Click on "Save private key" and save your private key to a file with the .ppk extension after setting a passphrase to encrypt it.

Since we are initially generating a key pair for root, set the "Key comment" box to root@hostname, where hostname is the name of your slug. After that, select all the text in the public key box and copy it to the clipboard. You should also save your public key to a text file, in case you need to restore it to the slug later, or setup another slug.

Now what we need to do is load that public key as an authorized key for root. We'll look at other users later on.

Configure SSH Server For Public Key Access

For this example, we will be working to authorize the root user to use SSH with public key authentication.

Go back to the telnet session you have as the desired user, in this case root. Look in your telnet session and see if right after login it came up with a message stating that the home directory could not be found. If you see this message, you need to create one and ensure that the permissions are correct. Permissions are very important, since OpenSSH checks them very carefully before allowing logins authenticated by keys. In the command prompt, run: (:table border=0 width=80% bgcolor=#eeffee:) (:cell:)

 mkdir /root
 chmod a+rx /root
 chmod og-w /root

(:tableend:)

This should result in a folder which everyone can read but no one but the owner (i.e. root) can write. Check this by: (:table border=0 width=80% bgcolor=#eeffee:) (:cell:)

 ls -ld /root

(:tableend:) and look for a line which looks like the following (noting the drwxr-xr-x particularly): (:table border=0 width=80% bgcolor=#eeffee:) (:cell:)

 drwxr-xr-x    1 root     root            0 Jan 30 16:21 /root

(:tableend:)

Now change to the home directory and create the hidden directory for the SSH settings:

Changed lines 81-109 from:


# cd ~/

  1. Now create the hidden directory for the SSH settings

    # mkdir /root/.ssh
    # cd /root/.ssh
  2. Copy the public key to the NSLU2

    Once we have this we want to save our public key into the authorized keys file which can be done easily as follows (The key here has been shortened for display purposes. Your generated key will be a much longer string):

    # echo ssh-rsa AAAAB3NzaC1yc2EAAAABIwAA......aJ3Wy+Ws4IZEgdJgPlTYUBWWtCWOGc= someone@hostname > authorized_keys

    For example, if my NSLU2 was called LKG0FD5B0 and this key was for the root ID, I would type:
    # echo ssh-rsa AAAAB3Nza......TYUBWWtCWOGc= root@LKG0FD5B0 > authorized_keys

    Since we have the public key in the Windows Clipboard from the Install and Configure SSH Client step, avoid all the typing and paste it in as appropriate.

    NOTE:
    I found problems using nano (small compact file editor) to create the file, because it kept changing the spacing and carriage returns which causes the key not to validate. The whole key should be on a single line. (slight edit: use nano -w and you won't have this problem)

    NOTE:
    "echo" is a command which prints what ever follows it to the standard output (usually the screen). So if you type "echo hello" at the prompt of a telnet session to the slug, the terminal will print "hello" to the screen.

    So assuming that you have copied your public key to the clipboard in windows, if you type "echo " and then paste your key following that from the clipboard, it will print your key to the standard output (i.e. the screen).

    Now the clever bit comes next. Using the ">" operator we can redirect the standard output from the screen to a file. So a statement such as "echo hello > hello.txt" will create a file called "hello.txt" containing the word "hello".
    \\
to:

(:table border=0 width=80% bgcolor=#eeffee:) (:cell:)

 cd ~
 mkdir .ssh
 chmod og= .ssh
 cd .ssh

(:tableend:)

Now let's copy the public key to the authorized_keys file in the NSLU2. This can be done easily if you have the key copied to the Windows clipboard, using an echo command to write to the file. Use a command line like this, typing echo, pasting the public key inside the telnet session and ending with the redirection (>authorized_keys): (the key here has been shortened for display purposes, your generated key will be a much longer string): (:table border=0 width=80% bgcolor=#eeffee:) (:cell:)

 echo ssh-rsa AAAAB3NzaC1yc2EAAAABIwAA...aJ3Wy+Ws4IZEgdJgPlTYUBWWtCWOGc= root@hostname > authorized_keys

(:tableend:)

Note: you can use a regular text editor, like vi or nano, to create the authorized_keys file. Just make sure that the whole key is on a single line. If you are using nano, start it with nano -w so you won't problems with long lines.

''Note: echo is a command which prints what ever follows it to the standard output (usually the screen). So if you type "echo hello" at the prompt of a telnet session to the slug, the terminal will print "hello" to the screen.
So assuming that you have copied your public key to the clipboard in windows, if you type echo and then paste your key following that from the clipboard, it will print your key to the standard output (i.e. the screen).
Now the clever bit comes next. Using the > operator we can redirect the standard output from the screen to a file. So a statement such as echo hello > hello.txt will create a file called hello.txt containing the word hello.\\

Changed lines 101-170 from:


There are others, such as copying the file across to one of the Samba (windows) shares and then moving it, but this way seemed to be the simplest (albeit arcane).

  1. Update file permissions

    Check that this file is not editable by anyone but the current user ensure that the write permissions are write only for the user (i.e. have a mask like -rwxr--r-- when you do an ls -l)

    # chmod a+r authorized_keys
    # chmod og-wx authorized_keys

OK so that should get us ready for authentication by key file. Furthermore we can prevent anyone logging in via SSH without a key.

Prevent Unauthorized User Access

To do this we need to do two things:

  1. Edit the ssh configuration file

    I use nano as my editor on the slug, but you can use any editor of your choice)

    # nano /opt/etc/openssh/sshd_config

    To this file change the PasswordAuthentication option to no and uncomment it.

    PasswordAuthentication no

    Note:
    For the full set of configuration details for this file see the sshd_config man page
  2. To correct the startup script so that the updated configuration file is called up we have to edit the init.d script:

    # nano /opt/etc/init.d/S40sshd

    and change the line which startsup the daemon from:

    /opt/sbin/sshd

    to:

    /opt/sbin/sshd -f /opt/etc/openssh/sshd_config

Restart the SSH Server

We're just about done!

  1. Restart SSH

    What we need to do is restart the SSH Daemon process and restart them. This can be done simply by calling the script that we just edited:

    # /opt/etc/init.d/S40sshd
  2. Start SSH Client

    Having set up the server as we want it all we have to do now is to connect with Putty. Start->Programs->Putty->Putty. It will come up with the options for the server (IP address etc) which you need to set. Also set up the SSH authentication by key (category screen on left -> connection -> SSH -> Auth: browse to the file with the key in it) - pointing the key to the *.ppk file that you created and saved in Install and Configure SSH Client.
  3. Log into your slug!

    Click open and when requested log in as 'root'. It should authenticate using the keys and a shell prompt will appear.
login as: root
Authenticating with public key "root@slug" from agent

BusyBox v0.60.4 (2004.07.01-03:05+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.

#
to:

There are others, such as copying the file across to one of the Samba (Windows) shares and then moving it, but this way seemed to be the simplest (albeit arcane).''

Finally, check that the authorized_keys file is not accessible by anyone but the current user (i.e. have a mask like -rwx------ when you do an ls -l): (:table border=0 width=80% bgcolor=#eeffee:) (:cell:)

 chmod og= authorized_keys

(:tableend:)

Ok, so that should get us ready for authentication using a public key. Furthermore we can prevent anyone logging in via SSH without a key. To do this we need to do edit the sshd_config file. Use nano or any editor of your choice to edit the file: (:table border=0 width=80% bgcolor=#eeffee:) (:cell:)

 nano /opt/etc/openssh/sshd_config

(:tableend:)

Inside this file, change the PasswordAuthentication option to no and uncomment it: (:table border=0 width=80% bgcolor=#eeffee:) (:cell:)

 PasswordAuthentication no

(:tableend:)

Note: for the full set of configuration details for this file see the sshd_config man page.

Under the current version of the OpenSSH server for Unslung, you do not need to change anything in the startup script in order to read the updated version of the config file.

After storing the public key and setting up the server to accept only key authentication, you need to restart the sshd server. This can be done simply by calling the init script: (:table border=0 width=80% bgcolor=#eeffee:) (:cell:)

 /opt/etc/init.d/S40sshd

(:tableend:)

Connect to the Slug using PuTTY

Having set up the server as we want it all we have to do now is to connect with PuTTY. Run Start->Programs->PuTTY->PuTTY. The PuTTY configuration window will come up with the options for the server (IP address and port) which you need to set. Type in the slug IP adress in the "Host Name" field and select "SSH" as the protocol. Also set up the SSH authentication by key: on the "Category" menu on the left select "Connection", "SSH", "Auth", click on "Browse" and select the file with your saved private key.

Now click on "Open" and when requested, log in as root. Enter the passphrase you used to protect your private key, the server should authenticate you using the keys and a shell prompt will appear: (:table border=0 width=80% bgcolor=#eeffee:) (:cell:)

 login as: root
 Enter the passphrase for root@slug: 
 Authenticating with public key "root@slug" from agent
 BusyBox v0.60.4 (2004.07.01-03:05+0000) Built-in shell (ash)
 Enter 'help' for a list of built-in commands.

 #

(:tableend:)

Changed lines 150-151 from:

If you're still asked for a password, carefully check the file permissions through the whole path of ~/.ssh/. Hints are written to /var/log/messages, like Authentication refused: bad ownership or modes for directory /home/user/.ssh. .ssh should have 700 (rwx------), authorized_keys 644 (rw-r--r--).

to:

If you're still asked for a password, carefully check the file permissions through the whole path of ~/.ssh/. Hints are written to /var/log/messages, like Authentication refused: bad ownership or modes for directory /home/user/.ssh. .ssh should have mode 700 (rwx------), authorized_keys should have mode 600 (rw-------).

Configuring SSH Authentication for Other Users

WARNING: this section is being updated, please wait one day or two before using these instructions. fcarolo December 11, 2006, at 10:15 PM

If you want to allow other users to use ssh to access the slug, you will need to create the users in the normal way using the Linksys web interface, update the /etc/passwd file to allocate them a shell and give them a path to their home directory. After that, you can also create authentication keys for these users.

First, create the desired user through the Linksys web interface. After this, login to the slug as root and edit the /etc/passwd file. Look for a line that begins with the newly created username, like this: (:table border=0 width=80% bgcolor=#eeffee:) (:cell:)

 username:scK54m082CMzI:2001:501:::/dev/null

(:tableend:)

The meaning of these fields is:

 username:encrypted password:user id:group id:description:home directory:login shell
So you will need to change the last two items, in the previous example that would be:
USERNAME:scK54m082CMzI:2001:501::/USERNAME:/bin/sh
Notes:
a. Allocating the user with a working path in /etc/passwd renders the ftp capabilities useless
b. Allocating the user with a shell enables each user to log in to the shell also in telnet (assuming it is enabled)

The important thing will be to ensure that the directory is set up with appropriate permissions and also that the parent directories (remember the /root setup?) have appropriate permissions both for the public and for the groups. Once this folder has been created, then follow steps (5) to (7) to create keys for the user. Follow up by chowning the newly created folder to the new user, e.g.

# chown -R mynewuser:everyone /home/mynewuserhome

You may wish to add additional users via the adduser tool (a tool which is installable via ipkg). You will discover that after a user is created with adduser and a password was assigned, the password will be lost on next server restart. See ChangePasswordsFromTheCommandLine for info on how to correctly set up a persistent password via the command line.

Other Notes

Better Interactivity

You might want to consider overclocking the NSLU2 so that it'll run at full speed instead of half speed as supplied by Linksys.

Changed lines 189-196 from:

Better Interactivity

You might want to consider overclocking the NSLU2 so that it'll run at full speed instead of half speed as supplied by Linksys.


Secure Copy

to:

Secure Copy

Added line 194:
Changed lines 197-220 from:

Adding Additional SSH Users

If you want to allow other users to use ssh to access the slug, you will need to create the users in the normal way using the Linksys web interface, update the /etc/passwd file to allocate them a shell and give them a path to their home directory.

A more detailed explanation (for newbies like me):
In the etc/passwd you will find a line similar to this one, for each of the users:
USERNAME:scK54m082CMzI:2001:501:::/dev/null
Meaning:
user name : password (encrypted): user id : group id : description : home directory : login shell
So you will need to change the last two items, in the previous example that would be:
USERNAME:scK54m082CMzI:2001:501::/USERNAME:/bin/sh
Notes:
a. Allocating the user with a working path in /etc/passwd renders the ftp capabilities useless
b. Allocating the user with a shell enables each user to log in to the shell also in telnet (assuming it is enabled)

The important thing will be to ensure that the directory is set up with appropriate permissions and also that the parent directories (remember the /root setup?) have appropriate permissions both for the public and for the groups. Once this folder has been created, then follow steps (5) to (7) to create keys for the user. Follow up by chowning the newly created folder to the new user, e.g.

# chown -R mynewuser:everyone /home/mynewuserhome

You may wish to add additional users via the adduser tool (a tool which is installable via ipkg). You will discover that after a user is created with adduser and a password was assigned, the password will be lost on next server restart. See ChangePasswordsFromTheCommandLine for info on how to correctly set up a persistent password via the command line.

to:

Remote access to files over SSH

If you want to be able to access your files, upload and download over SSH then you need an SCP client. For myself, wanting to access my files over the internet securely from my Windows box at work, I downloaded WinSCP (http://winscp.net/) and simply configured it up, by entering the IP address, pointing to the key file and entering the username. It worked out of the box, I could browse all the files on the SLUG as if logged in to console.

Changed lines 203-210 from:

Remote access to files over SSH

If you want to be able to access your files, upload and download over SSH then you need an SCP client. For myself, wanting to access my files over the internet securely from my Windows box at work, I downloaded WinSCP (http://winscp.net/) and simply configured it up, by entering the IP address, pointing to the key file and entering the username. It worked out of the box, I could browse all the files on the SLUG as if logged in to console.


Remote access to Samba shares over SSH

to:

Remote access to Samba shares over SSH

Changed lines 234-235 from:

A security story

to:

A security story

Changed lines 287-288 from:

Change root jail

to:

Change root jail

November 21, 2006, at 09:01 PM by rickb --
Changed lines 34-35 from:

You might like to use WinSCP instead/as well. This allows FTP-like access to your files over the secure SSH connection.

to:

(You might like to use WinSCP instead/as well. This allows FTP-like access to your files over the secure SSH connection.)

November 21, 2006, at 08:41 PM by rickb --
Changed line 32 from:

Putty is good free client so that's what I'm going to talk about here. Download it and install.

to:

Putty is good free client so that's what I'm going to talk about here. Download it and install.\\

November 21, 2006, at 08:40 PM by rickb --
Changed lines 32-34 from:

I use the free client called Putty so that's what I'm going to talk about here. Download it and install.

  1. Now we need to generate some keys.\\
to:

Putty is good free client so that's what I'm going to talk about here. Download it and install.

Added lines 34-37:

You might like to use WinSCP instead/as well. This allows FTP-like access to your files over the secure SSH connection.

  1. Now we need to generate some keys.
    \\
October 15, 2006, at 08:10 PM by marty_k71 -- Added link to page for chroot jail setup.
Added lines 316-318:

Change root jail

The following page describes how to setup a change root jail at our Slug : ChrootJailForSFTP

September 21, 2006, at 11:25 AM by Lunar_Lamp -- Added timing warning to installation
Changed lines 14-15 from:

# ipkg install openssh

to:

# ipkg install openssh (note: this may take a while to generate keys)

August 25, 2006, at 06:53 PM by ultranewbie ruby --
Added lines 204-218:
A more detailed explanation (for newbies like me):
In the etc/passwd you will find a line similar to this one, for each of the users:
USERNAME:scK54m082CMzI:2001:501:::/dev/null
Meaning:
user name : password (encrypted): user id : group id : description : home directory : login shell
So you will need to change the last two items, in the previous example that would be:
USERNAME:scK54m082CMzI:2001:501::/USERNAME:/bin/sh
Notes:
a. Allocating the user with a working path in /etc/passwd renders the ftp capabilities useless
b. Allocating the user with a shell enables each user to log in to the shell also in telnet (assuming it is enabled)
July 01, 2006, at 04:05 PM by metamind --
Changed lines 166-167 from:

Having set up the server as we want it all we have to do now is to connect with Putty. Start->Programs->Putty->Putty. It will come up with the options for the server (IP address etc) which you need to set. Also set up the SSH authentication by key - pointing the key to the *.ppk file that you created and saved in Install and Configure SSH Client.

to:

Having set up the server as we want it all we have to do now is to connect with Putty. Start->Programs->Putty->Putty. It will come up with the options for the server (IP address etc) which you need to set. Also set up the SSH authentication by key (category screen on left -> connection -> SSH -> Auth: browse to the file with the key in it) - pointing the key to the *.ppk file that you created and saved in Install and Configure SSH Client.

June 14, 2006, at 10:14 PM by lxs4ever -- Private key has passphrase (rather than password)
Changed line 45 from:
  1. Save your private key pair (*.ppk) file with a password to encrypt it.\\
to:
  1. Save your private key pair (*.ppk) file with a passphrase to encrypt it.\\
Changed lines 47-48 from:

Make this password reasonably long (>8 characters), easy to remember, and significant to you but not to anyone else. This is especially true if you plan to make the NSLU2 visible on the Internet.

to:

Make this passphrase reasonably long (>8 characters), easy to remember, and significant to you but not to anyone else. This is especially true if you plan to make the NSLU2 visible on the Internet.

June 09, 2006, at 05:32 AM by jcc --
Changed lines 1-2 from:

This howto covers the setup and usage of the OpenSSH secure shell for remote command line access. see also SwapFromDropbearToOpenSSH

to:

This howto covers the setup and usage of the OpenSSH secure shell for remote command line access. see also SwapFromDropbearToOpenSSH

June 09, 2006, at 05:32 AM by jcc --
Changed lines 1-2 from:

This howto covers the setup and usage of the OpenSSH secure shell for remote command line access.

to:

This howto covers the setup and usage of the OpenSSH secure shell for remote command line access. see also SwapFromDropbearToOpenSSH

May 16, 2006, at 03:19 PM by MattMcNeill -- Explaining the key pasting
Changed lines 101-103 from:

I found problems using nano (small compact file editor) to create the file, because it kept changing the spacing and carriage returns which causes the key not to validate. The whole key should be on a single line. (slight edit: use nano -w and you won't have this problem)

  1. Update file permissions\\
to:

I found problems using nano (small compact file editor) to create the file, because it kept changing the spacing and carriage returns which causes the key not to validate. The whole key should be on a single line. (slight edit: use nano -w and you won't have this problem)\\

Changed lines 103-104 from:

Check that this file is not editable by anyone but the current user ensure that the write permissions are write only for the user (i.e. have a mask like -rwxr--r-- when you do an ls -l)\\

to:

NOTE:
"echo" is a command which prints what ever follows it to the standard output (usually the screen). So if you type "echo hello" at the prompt of a telnet session to the slug, the terminal will print "hello" to the screen.\\

Added lines 106-117:

So assuming that you have copied your public key to the clipboard in windows, if you type "echo " and then paste your key following that from the clipboard, it will print your key to the standard output (i.e. the screen).

Now the clever bit comes next. Using the ">" operator we can redirect the standard output from the screen to a file. So a statement such as "echo hello > hello.txt" will create a file called "hello.txt" containing the word "hello".

Putting all this together the echo statement is an easy way of getting the public key from your clipboard in windows into a file on the slug.

There are others, such as copying the file across to one of the Samba (windows) shares and then moving it, but this way seemed to be the simplest (albeit arcane).

  1. Update file permissions

    Check that this file is not editable by anyone but the current user ensure that the write permissions are write only for the user (i.e. have a mask like -rwxr--r-- when you do an ls -l)
    \\
May 12, 2006, at 02:39 PM by JonMikelV -- Add something I forgot last time
Changed lines 231-232 from:

Note-to-the-note: On my XPSP2? box I've had success adding the loopback adapter and disabling NetBIOS? over TCP/IP leaving all the standard bound services enabled. This gets port 139 working (though not 445) and my shares seem quite happy to run through SSH. (Use "Add New Hardware", assign a fixed IP address, click on "Advanced", go to the "WINS" tab and select "Disable NetBIOS? over TCP/IP".)

to:

Note-to-the-note: On my XPSP2? box I've had success adding the loopback adapter using a fixed IP and only disabling "File And Printer Sharing for Microsoft Networks" and "NetBIOS? over TCP/IP" (leaving all other settings at default). This gets port 139 working (though not 445) and my shares seem quite happy to run through SSH. (Use "Add New Hardware", assign a fixed IP address, click on "Advanced", go to the "WINS" tab and select "Disable NetBIOS? over TCP/IP".)

May 12, 2006, at 02:21 PM by JonMikelV -- Added user experience with SSH forwarding
Added lines 231-232:

Note-to-the-note: On my XPSP2? box I've had success adding the loopback adapter and disabling NetBIOS? over TCP/IP leaving all the standard bound services enabled. This gets port 139 working (though not 445) and my shares seem quite happy to run through SSH. (Use "Add New Hardware", assign a fixed IP address, click on "Advanced", go to the "WINS" tab and select "Disable NetBIOS? over TCP/IP".)

May 11, 2006, at 03:48 PM by MattMcNeill -- typo on root folders permissions (w-x -> -rx)
Changed line 76 from:

And look for a line which looks like the following (noting the dwrxw-xw-x particularly)\\

to:

And look for a line which looks like the following (noting the dwrx-rx-rx particularly)\\

February 16, 2006, at 03:01 PM by mordak -- Using KDE-SCP (fish) with slung
Added line 186:

If you want to use KDE for accessing the file on your slung ala fish://root@192.168.1.2:22/ you have to install perl (ipkg install perl) in addition to openssh and openssl.

December 16, 2005, at 03:56 AM by thx1011 -- Add more info regarding DropBear and SFTP
Changed lines 26-27 from:

(Note: You can stop dropbear now and free some memory, just do the following steps: Goto /etc/rc3.d and delete de S10dropbear link.)

to:

(Note: You can stop dropbear now and free some memory, just do the following steps: Goto /etc/rc3.d and delete de S10dropbear link. Note, this will not remove Dropbear from your Slug, but only won't start it for run level 3.)

Added lines 182-187:

Secure Copy

If you wanto to use sftp, then you need to install also the package openssh-sftp (At least I need it -thx1011). On OpenSlug 2.7Beta even after installing package openssh, you need this one. Then you can use, for example on windows side, the WinSCP freeware program, ou also, the integrated SFTP client into OpenSSH? windows client. This will allow file transfer using SSH for remote access without exposing your Samba shares.


December 14, 2005, at 02:30 PM by thx1011 -- Removing dropbear after ssh instalation
Changed lines 25-26 from:

OK so it's running. What the heck do you do now? If you already know ssh then you can stop at this point because SSH is installed and working. If you want to perform additional configuration then read on.

to:

OK so it's running. What the heck do you do now? If you already know ssh then you can stop at this point because SSH is installed and working. If you want to perform additional configuration then read on.
(Note: You can stop dropbear now and free some memory, just do the following steps: Goto /etc/rc3.d and delete de S10dropbear link.)

December 09, 2005, at 08:35 AM by MattMcNeill --
Added line 210:
December 09, 2005, at 08:29 AM by MattMcNeill -- added PLINk tunnel batch file example
Added lines 204-223:

I have created a batch file which I use to run PLINK (part of Putty) with the tunnel settings (so no console window is necessary) as follows:

(:table border=0 width=100% bgcolor=#eeffee:) (:cell:)

@echo off ".\plink.exe" username@myserver.ipaddress.com -ssh -N -v -batch -L 10.0.0.1:139:127.0.0.1:139 -L 10.0.0.1:445:127.0.0.1:445 -L 10.0.0.1:80:127.0.0.1:80 -L 10.0.0.1:443:127.0.0.1:443 -L 10.0.0.1:901:127.0.0.1:901 -L 10.0.0.1:8080:127.0.0.1:8080 -L 10.0.0.1:6667:127.0.0.1:6667 -L 10.0.0.1:9180:mynetworkgatewayipaddress:80 -L 10.0.0.1:21:ftp.myispwebpageuploadserver.com:21

REM If you are running Windows 95 or 98, you can uncomment the following "choice" line to REM insert a delay of 5 seconds before the connection tries to re-establish.

REM choice /cX /t:X,5 > nul REM call tunnel.bat

(:tableend:)

Note: the only ports you need to expose for SAMBA are 139 and 445. This assumes you have set up the loopback adapter on 10.0.0.1 and removed all the bound services except TCP/IP as described in the page linked to above.

Note: to use create a file called tunnel.bat in the same folder as plink.exe. Load your keys into Pageant as normal and then simply run the batch file. remember that you need to have opened the SSH port (22) in your firewall etc as you would for SSH console sessions.

November 16, 2005, at 10:29 PM by Sharth -- badly formatted edit. use nano -w to not worry about line breaks.
Changed lines 100-101 from:

I found problems using nano (small compact file editor) to create the file, because it kept changing the spacing and carriage returns which causes the key not to validate. The whole key should be on a single line.

to:

I found problems using nano (small compact file editor) to create the file, because it kept changing the spacing and carriage returns which causes the key not to validate. The whole key should be on a single line. (slight edit: use nano -w and you won't have this problem)

October 31, 2005, at 04:22 AM by tman --
Changed lines 3-4 from:

OpenSSH is a fully featured daemon which also requires the OpenSSL libraries. It is more sophisticated than DropBear and has more advanced features such as agent forwarding. It may also get around some of the multiple user problems that people experienced with DropBear.

to:

OpenSSH is a fully featured daemon which also requires the OpenSSL libraries. It is more sophisticated than DropBear and has more advanced features such as agent forwarding. It may also get around some of the multiple user problems that people experienced with DropBear.

Changed lines 7-10 from:

Install SSH Daemon On Unslung

  1. Unsling your slug - see Unslung
to:

Install SSH daemon On Unslung

  1. Unsling your slug - see Unslung
Changed lines 31-32 from:

I use the free client called Putty (http://www.chiark.greenend.org.uk/~sgtatham/putty/) so that's what I'm going to talk about here. Download it and install.

to:

I use the free client called Putty so that's what I'm going to talk about here. Download it and install.

Changed lines 100-101 from:

I found problems using nano (small compact file editor) to create the file, because it kept changing the spacing and carriage returns which causes the key not to validate. The whole key should be on a single line.

to:

I found problems using nano (small compact file editor) to create the file, because it kept changing the spacing and carriage returns which causes the key not to validate. The whole key should be on a single line.

Changed line 118 from:

I use nano as my editor on the slug, but you can use any editor of your choice)\\

to:

I use nano as my editor on the slug, but you can use any editor of your choice)\\

Deleted line 128:
Changed line 164 from:

BusyBox? v0.60.4 (2004.07.01-03:05+0000) Built-in shell (ash) \\

to:

BusyBox v0.60.4 (2004.07.01-03:05+0000) Built-in shell (ash) \\

Changed lines 175-181 from:

More Speed

Please considere that OverClocking? the Slug might be a good idea... OverClockTheSlug . (It will run at full speed instead of half speed)

OpenSSH? is slow... and you can go two time faster using this 5 minutes "hack". This is really a MUST if you want a decent SSH.

to:

Better Interactivity

You might want to consider overclocking the NSLU2 so that it'll run at full speed instead of half speed as supplied by Linksys.

Changed line 189 from:

You may wish to add additional users via the adduser tool (a tool which is installable via ipkg). You will discover that after a user is created with adduser and a password was assigned, the password will be lost on next server restart. See ChangePasswordsFromTheCommandLine for info on how to correctly set up a persistent password via the command line.

to:

You may wish to add additional users via the adduser tool (a tool which is installable via ipkg). You will discover that after a user is created with adduser and a password was assigned, the password will be lost on next server restart. See ChangePasswordsFromTheCommandLine for info on how to correctly set up a persistent password via the command line.

Changed lines 198-199 from:

Remote access to SAMBA shares over SSH

to:

Remote access to Samba shares over SSH

Deleted lines 258-259:

Cheeky, cheeky, cheeky !!!

October 31, 2005, at 03:13 AM by junk at nwxg dot com --
Changed line 193 from:

You may wish to add additional users via the adduser tool (a tool which is installable via ipkg). You will discover that after a user is created with adduser and a password was assigned, the password will be lost on next server restart. This makes attempts to login using the new user name via SSH fail after a restart. This happens because the passwd file in /etc is overwritten on every restart with the copy located in /share/hdd/conf/passwd, but the passwd command (which is used by adduser, and which you may also use directly yourself) only modifies the copy of passwd in /etc. Anytime you set a passwd with adduser or the passwd command, you should copy your newly modified /etc/passwd version to /share/hdd/conf/passwd. (Be careful! make a back up copy of /share/hdd/conf/passwd if in doubt.)

to:

You may wish to add additional users via the adduser tool (a tool which is installable via ipkg). You will discover that after a user is created with adduser and a password was assigned, the password will be lost on next server restart. See ChangePasswordsFromTheCommandLine for info on how to correctly set up a persistent password via the command line.

October 31, 2005, at 03:05 AM by junk at nwxg dot com --
Changed line 193 from:

You may wish to add additional users via the adduser tool (a tool which is installable via ipkg). You will discover that after a user is created with adduser and a password was assigned, the password will be lost on next server restart. This makes attempts to login using the new user name via SSH to fail after a restart. This happens because the passwd file in /etc is overwritten on every restart with the copy located in /share/hdd/conf/passwd, but adduser, and the passwd command only modify the copy in /etc. So, anytime you set a passwd with adduser or the passwd command, you should copy your newly modified /etc/passwd version to /share/hdd/conf/passwd. (Be careful! make a back up copy of /share/hdd/conf/passwd if in doubt.)

to:

You may wish to add additional users via the adduser tool (a tool which is installable via ipkg). You will discover that after a user is created with adduser and a password was assigned, the password will be lost on next server restart. This makes attempts to login using the new user name via SSH fail after a restart. This happens because the passwd file in /etc is overwritten on every restart with the copy located in /share/hdd/conf/passwd, but the passwd command (which is used by adduser, and which you may also use directly yourself) only modifies the copy of passwd in /etc. Anytime you set a passwd with adduser or the passwd command, you should copy your newly modified /etc/passwd version to /share/hdd/conf/passwd. (Be careful! make a back up copy of /share/hdd/conf/passwd if in doubt.)

October 31, 2005, at 03:02 AM by junk at nwxg dot com -- add info on correctly setting passwd for users created at command line.
Added line 193:

You may wish to add additional users via the adduser tool (a tool which is installable via ipkg). You will discover that after a user is created with adduser and a password was assigned, the password will be lost on next server restart. This makes attempts to login using the new user name via SSH to fail after a restart. This happens because the passwd file in /etc is overwritten on every restart with the copy located in /share/hdd/conf/passwd, but adduser, and the passwd command only modify the copy in /etc. So, anytime you set a passwd with adduser or the passwd command, you should copy your newly modified /etc/passwd version to /share/hdd/conf/passwd. (Be careful! make a back up copy of /share/hdd/conf/passwd if in doubt.)

October 02, 2005, at 05:07 PM by don lubinski -- minor edit on spell
Changed line 149 from:

What we need to do is restart the SSH Daemon processe and restart them. This can be done simply by calling the script that we just edited:\\

to:

What we need to do is restart the SSH Daemon process and restart them. This can be done simply by calling the script that we just edited:\\

September 03, 2005, at 01:16 PM by prikryl -- correct winscp link
Changed line 263 from:

Cheeky, cheeky, cheeky !!!

to:

Cheeky, cheeky, cheeky !!!

September 03, 2005, at 01:15 PM by prikryl -- correct winscp link
Changed lines 197-198 from:

If you want to be able to access your files, upload and download over SSH then you need an SCP client. For myself, wanting to access my files over the internet securely from my Windows box at work, I downloaded WinSCP (http://winscp.sourceforge.net/) and simply configured it up, by entering the IP address, pointing to the key file and entering the username. It worked out of the box, I could browse all the files on the SLUG as if logged in to console.

to:

If you want to be able to access your files, upload and download over SSH then you need an SCP client. For myself, wanting to access my files over the internet securely from my Windows box at work, I downloaded WinSCP (http://winscp.net/) and simply configured it up, by entering the IP address, pointing to the key file and entering the username. It worked out of the box, I could browse all the files on the SLUG as if logged in to console.

September 01, 2005, at 10:46 AM by Jochen Schoenfeld -- Added a hint concerning file permissions.
Added lines 172-173:

If you're still asked for a password, carefully check the file permissions through the whole path of ~/.ssh/. Hints are written to /var/log/messages, like Authentication refused: bad ownership or modes for directory /home/user/.ssh. .ssh should have 700 (rwx------), authorized_keys 644 (rw-r--r--).

July 27, 2005, at 12:57 PM by MattMcNeill --
Added lines 193-194:

Remote access to files over SSH

Added lines 207-208:

A security story

July 27, 2005, at 12:56 PM by MattMcNeill -- Pointer to instrutcions on how to view SAMBA shares over SSH.
Added lines 197-204:

Remote access to SAMBA shares over SSH

If you want to view Samba shares over SSH then you need to follow the following instructions - worked perfectly for me.

http://lists.samba.org/archive/samba/2004-May/085358.html


July 05, 2005, at 08:22 PM by KGP --
Deleted lines 171-180:

Adding Additional SSH Users

OverClocking? the Slug might be a good idea... OverClockTheSlug

OpenSSH? is slow... and you can go two time faster using this 5 minutes "hack". This is really a MUST if you want a decent SSH.

KGP / Nuage

Added lines 174-184:

More Speed

Please considere that OverClocking? the Slug might be a good idea... OverClockTheSlug . (It will run at full speed instead of half speed)

OpenSSH? is slow... and you can go two time faster using this 5 minutes "hack". This is really a MUST if you want a decent SSH.


Adding Additional SSH Users

July 04, 2005, at 08:31 PM by KGP --
Changed lines 176-180 from:

OverClocking? the Slug might be a good idea... OverClockTheSlug OpenSSH? is slow... and you can go two time faster using this 5 minutes "hack". KGP

to:

OverClocking? the Slug might be a good idea... OverClockTheSlug

OpenSSH? is slow... and you can go two time faster using this 5 minutes "hack". This is really a MUST if you want a decent SSH.

KGP / Nuage

July 04, 2005, at 08:29 PM by KGP --
Added lines 176-182:

OverClocking? the Slug might be a good idea... OverClockTheSlug OpenSSH? is slow... and you can go two time faster using this 5 minutes "hack". KGP


May 17, 2005, at 03:55 PM by barrym --
Changed lines 1-2 from:

This howto covers the setup and usage of the OpenSSH secure shell for remote command line access. OpenSSH is a fully featured daemon which also requires the OpenSSL libraries. It is more sophisticated than DropBear and has more advanced features such as agent forwarding. It may also get around some of the multiple user problems that people experienced with DropBear.

to:

This howto covers the setup and usage of the OpenSSH secure shell for remote command line access.

OpenSSH is a fully featured daemon which also requires the OpenSSL libraries. It is more sophisticated than DropBear and has more advanced features such as agent forwarding. It may also get around some of the multiple user problems that people experienced with DropBear.

Changed lines 7-11 from:

1) Unsling your slug - see Unslung

2) Install the OpenSSH package which gives you your SSH daemon. You can do this by executing the following via telnet.

# ipkg update \\
to:

Install SSH Daemon On Unslung

  1. Unsling your slug - see Unslung
  2. Install the OpenSSH package which gives you your SSH daemon. You can do this by executing the following via telnet.

    # ipkg update \\
Changed lines 16-106 from:

3) Reboot and check OpenSSH is running.

# ps -ef

And look for a line something like the following:

1735 root 3208 R /opt/sbin/sshd

4) OK so it's running. What the heck do you do now? If you already know ssh then you can stop at this point because SSH is installed and working. If you want to perform additional configuration then read on.

5) You need to get an SSH client for your Windows box. I use the free client called Putty (http://www.chiark.greenend.org.uk/~sgtatham/putty/) so that's what I'm going to talk about here. Download it and install.

6) Now we need to generate some keys. So run Start->Programs->Putty->Puttygen key generation program. Click the "generate" button to generate some new keys. In the top part of the window you will see a public key string something like the following (The key here has been shortened for display purposes. Your generated key will be a much longer string):

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAA......aJ3Wy+Ws4IZEgdJgPlTYUBWWtCWOGc= someone@hostname

This is what is called a public key.

7) First of all save your private key pair (*.ppk) file with a password to encrypt it.

8) Copy the public key similar to the string in (5) above to the clipboard. Now what we need to do is load that public key as an authorized key for 'root'. We'll look at other users later on.

First of all telnet into the SLUG as the user we want to authorise (e.g. root) and change to the home directory:

# cd ~/

NOTE: if when you logged in it came up with a message stating that the home directory could not be found, you need to create one and ensure that the permissions are correct. Permissions are very important, since OpenSSH checks them very carefully before allowing logins authenticated by keys.

# mkdir /root
# chmod a+rx /root
# chmod og-w /root

This should result in a folder which everyone can read but no-one but the owner (i.e. root) can write. Check this by:

# ls -l /

And look for a line which looks like the following (noting the dwrxw-xw-x particularly)

drwxr-xr-x 1 root root 0 Jan 30 16:21 root

Now create the hidden directory for the SSH settings

# mkdir /root/.ssh
# cd /root/.ssh

Once we have this we want to save our public key into the authorized keys file which can be done easily as follows (The key here has been shortened for display purposes. Your generated key will be a much longer string):

# echo ssh-rsa AAAAB3NzaC1yc2EAAAABIwAA......aJ3Wy+Ws4IZEgdJgPlTYUBWWtCWOGc= someone@hostname > authorized_keys

NOTE: I found problems using nano (small compact file editor) to create the file, because it kept changing the spacing and carriage returns which causes the key not to validate. The whole key should be on a single line.

Check that this file is not editable by anyone but the current user ensure that the write permissions are write only for the user (i.e. have a mask like -rwxr--r-- when you do an ls -l)

# chmod a+r authorized_keys
# chmod og-wx authorized_keys

9) OK so that should get us ready for authentication by key file. Furthermore we can prevent anyone logging in via SSH without a key. To do this we need to do two things:

i) Add an option into the OpenSSH? configuration script
ii) Correct the OpenSSH? startup script so that it actually calls the configuration script (this imay be an error in the ipkg installation procedure ?)

9i) Edit the ssh configuration file (I use nano as my editor on the slug, but you can use any editor of your choice)

# nano /opt/etc/openssh/sshd_config

To this file change the PasswordAuthentication? option to 'no' and uncomment it. (for the full set of configuration details for this file see the sshd_config man page

9ii) To correct the startup script so that the updated configuration file is called up we have to edit the init.d script:

# nano /opt/etc/init.d/S40sshd

and change the line which startsup the daemon from:

/opt/sbin/sshd

to:

/opt/sbin/sshd -f /opt/etc/openssh/sshd_config

What we need to do is restart the SSH Daemon processe and restart them. This can be done simply by calling the script that we just edited:

# /opt/etc/init.d/S40sshd

10) Having set up the server as we want it all we have to do now is to connect with Putty. Start->Programs->Putty->Putty. It will come up with the options for the server (IP address etc) which you need to set. Also set up the SSH authentication by key - pointing the key to the *.ppk file that you created and saved in (6).

11) Click open and when requested log in as 'root'. It should authenticate using the keys and a shell prompt will appear.

'''login as: root
Authenticating with public key "root@slug" from agent \\
to:
  1. Reboot and check OpenSSH is running.\\
Changed lines 18-19 from:

BusyBox? v0.60.4 (2004.07.01-03:05+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands. \\

to:

# ps -ef \\

Added lines 20-167:

And look for a line something like the following:

1735 root 3208 R /opt/sbin/sshd

OK so it's running. What the heck do you do now? If you already know ssh then you can stop at this point because SSH is installed and working. If you want to perform additional configuration then read on.

Install and Configure SSH Client

  1. You need to get an SSH client for your Windows box.

    I use the free client called Putty (http://www.chiark.greenend.org.uk/~sgtatham/putty/) so that's what I'm going to talk about here. Download it and install.
  2. Now we need to generate some keys.

    * So run Start->Programs->Putty->Puttygen key generation program.
    * Click the "generate" button to generate some new keys.

    In the top part of the window you will see a public key string something like the following (The key here has been shortened for display purposes. Your generated key will be a much longer string):

    ssh-rsa AAAAB3NzaC1yc2EAAAABIwAA......aJ3Wy+Ws4IZEgdJgPlTYUBWWtCWOGc= someone@hostname

    This is what is called a public key. We'll get back to this in a moment.
  3. Save your private key pair (*.ppk) file with a password to encrypt it.

    Make this password reasonably long (>8 characters), easy to remember, and significant to you but not to anyone else. This is especially true if you plan to make the NSLU2 visible on the Internet.
  4. Copy the public key (similar to the "ssh-rsa" string above) to the clipboard.

    Now what we need to do is load that public key as an authorized key for 'root'. We'll look at other users later on.

Configure SSH Server With Public Key

For this example, we will be working to authorize the 'root' user to use SSH.

  1. First of all telnet into the SLUG as the user we want to authorise (e.g. root)

    Since this setting does not persist after slug reboots, don't forget to authorize this by going to

    http://(slug IP address)/Management/telnet.cgi.
  2. Look in your telnet session and see if it came up with a message stating that the home directory could not be found.

    If you see this message, you need to create one and ensure that the permissions are correct. Permissions are very important, since OpenSSH checks them very carefully before allowing logins authenticated by keys.

    # mkdir /root
    # chmod a+rx /root
    # chmod og-w /root

    This should result in a folder which everyone can read but no-one but the owner (i.e. root) can write. Check this by:

    # ls -l /

    And look for a line which looks like the following (noting the dwrxw-xw-x particularly)

    drwxr-xr-x 1 root root 0 Jan 30 16:21 root
  3. Change to the home directory:

    # cd ~/
  4. Now create the hidden directory for the SSH settings

    # mkdir /root/.ssh
    # cd /root/.ssh
  5. Copy the public key to the NSLU2

    Once we have this we want to save our public key into the authorized keys file which can be done easily as follows (The key here has been shortened for display purposes. Your generated key will be a much longer string):

    # echo ssh-rsa AAAAB3NzaC1yc2EAAAABIwAA......aJ3Wy+Ws4IZEgdJgPlTYUBWWtCWOGc= someone@hostname > authorized_keys

    For example, if my NSLU2 was called LKG0FD5B0 and this key was for the root ID, I would type:
    # echo ssh-rsa AAAAB3Nza......TYUBWWtCWOGc= root@LKG0FD5B0 > authorized_keys

    Since we have the public key in the Windows Clipboard from the Install and Configure SSH Client step, avoid all the typing and paste it in as appropriate.

    NOTE:
    I found problems using nano (small compact file editor) to create the file, because it kept changing the spacing and carriage returns which causes the key not to validate. The whole key should be on a single line.
  6. Update file permissions

    Check that this file is not editable by anyone but the current user ensure that the write permissions are write only for the user (i.e. have a mask like -rwxr--r-- when you do an ls -l)

    # chmod a+r authorized_keys
    # chmod og-wx authorized_keys

OK so that should get us ready for authentication by key file. Furthermore we can prevent anyone logging in via SSH without a key.

Prevent Unauthorized User Access

To do this we need to do two things:

  1. Edit the ssh configuration file

    I use nano as my editor on the slug, but you can use any editor of your choice)

    # nano /opt/etc/openssh/sshd_config

    To this file change the PasswordAuthentication option to no and uncomment it.

    PasswordAuthentication no

    Note:
    For the full set of configuration details for this file see the sshd_config man page
  2. To correct the startup script so that the updated configuration file is called up we have to edit the init.d script:

    # nano /opt/etc/init.d/S40sshd

    and change the line which startsup the daemon from:

    /opt/sbin/sshd

    to:

    /opt/sbin/sshd -f /opt/etc/openssh/sshd_config

Restart the SSH Server

We're just about done!

  1. Restart SSH

    What we need to do is restart the SSH Daemon processe and restart them. This can be done simply by calling the script that we just edited:

    # /opt/etc/init.d/S40sshd
  2. Start SSH Client

    Having set up the server as we want it all we have to do now is to connect with Putty. Start->Programs->Putty->Putty. It will come up with the options for the server (IP address etc) which you need to set. Also set up the SSH authentication by key - pointing the key to the *.ppk file that you created and saved in Install and Configure SSH Client.
  3. Log into your slug!

    Click open and when requested log in as 'root'. It should authenticate using the keys and a shell prompt will appear.
'''login as: root
Authenticating with public key "root@slug" from agent

BusyBox? v0.60.4 (2004.07.01-03:05+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
\\
Changed lines 172-173 from:

12) If you want to allow other users to use ssh to access the slug, you will need to create the users in the normal way using the Linksys web interface, update the /etc/passwd file to allocate them a shell and give them a path to their home directory. The important thing will be to ensure that the directory is set up with appropriate permissions and also that the parent directories have appropriate permissions both for the public and for the groups. Once this folder has been created, then follow steps (5) to (7) to create keys for the user. Follow up by chowning the newly created folder to the new user, e.g.

to:

Adding Additional SSH Users

If you want to allow other users to use ssh to access the slug, you will need to create the users in the normal way using the Linksys web interface, update the /etc/passwd file to allocate them a shell and give them a path to their home directory.

The important thing will be to ensure that the directory is set up with appropriate permissions and also that the parent directories (remember the /root setup?) have appropriate permissions both for the public and for the groups. Once this folder has been created, then follow steps (5) to (7) to create keys for the user. Follow up by chowning the newly created folder to the new user, e.g.

April 04, 2005, at 01:12 PM by barrym --
Changed lines 54-55 from:
# mkdir .ssh
# cd .ssh
to:
# mkdir /root/.ssh
# cd /root/.ssh
February 07, 2005, at 04:34 PM by paulhar --
Changed line 20 from:

4) OK so it's running. What the heck do you do now? Well, you need to get an SSH client for your Windows box. I use the free client called Putty (http://www.chiark.greenend.org.uk/~sgtatham/putty/) so that's what I'm going to talk about here. Download it and install.

to:

4) OK so it's running. What the heck do you do now? If you already know ssh then you can stop at this point because SSH is installed and working. If you want to perform additional configuration then read on.

Changed lines 22-24 from:

5) Now we need to generate some keys. So run Start->Programs->Putty->Puttygen key generation program. Click the "generate" button to generate some new keys. In the top part of the window you will see a public key string something like the following (The key here has been shortened for display purposes. Your generated key will be a much longer string):

to:

5) You need to get an SSH client for your Windows box. I use the free client called Putty (http://www.chiark.greenend.org.uk/~sgtatham/putty/) so that's what I'm going to talk about here. Download it and install.

6) Now we need to generate some keys. So run Start->Programs->Putty->Puttygen key generation program. Click the "generate" button to generate some new keys. In the top part of the window you will see a public key string something like the following (The key here has been shortened for display purposes. Your generated key will be a much longer string):

Changed line 30 from:

6) First of all save your private key pair (*.ppk) file with a password to encrypt it.

to:

7) First of all save your private key pair (*.ppk) file with a password to encrypt it.

Changed line 32 from:

7) Copy the public key similar to the string in (5) above to the clipboard. Now what we need to do is load that public key as an authorized key for 'root'. We'll look at other users later on.

to:

8) Copy the public key similar to the string in (5) above to the clipboard. Now what we need to do is load that public key as an authorized key for 'root'. We'll look at other users later on.

Changed line 68 from:

8) OK so that should get us ready for authentication by key file. Furthermore we can prevent anyone logging in via SSH without a key. To do this we need to do two things:

to:

9) OK so that should get us ready for authentication by key file. Furthermore we can prevent anyone logging in via SSH without a key. To do this we need to do two things:

Changed line 73 from:

8i) Edit the ssh configuration file (I use http://www.nslu2-linux.org/wiki/Unslung/Nano nano as my editor on the slug, but you can use any editor of your choice)

to:

9i) Edit the ssh configuration file (I use http://www.nslu2-linux.org/wiki/Unslung/Nano nano as my editor on the slug, but you can use any editor of your choice)

Changed line 81 from:

8ii) To correct the startup script so that the updated configuration file is called up we have to edit the init.d script:

to:

9ii) To correct the startup script so that the updated configuration file is called up we have to edit the init.d script:

Changed line 97 from:

9) Having set up the server as we want it all we have to do now is to connect with Putty. Start->Programs->Putty->Putty. It will come up with the options for the server (IP address etc) which you need to set. Also set up the SSH authentication by key - pointing the key to the *.ppk file that you created and saved in (6).

to:

10) Having set up the server as we want it all we have to do now is to connect with Putty. Start->Programs->Putty->Putty. It will come up with the options for the server (IP address etc) which you need to set. Also set up the SSH authentication by key - pointing the key to the *.ppk file that you created and saved in (6).

Changed line 99 from:

10) Click open and when requested log in as 'root'. It should authenticate using the keys and a shell prompt will appear.

to:

11) Click open and when requested log in as 'root'. It should authenticate using the keys and a shell prompt will appear.

Changed line 111 from:

11) If you want to allow other users to use ssh to access the slug, you will need to create the users in the normal way using the Linksys web interface, update the /etc/passwd file to allocate them a shell and give them a path to their home directory. The important thing will be to ensure that the directory is set up with appropriate permissions and also that the parent directories have appropriate permissions both for the public and for the groups. Once this folder has been created, then follow steps (5) to (7) to create keys for the user. Follow up by chowning the newly created folder to the new user, e.g.

to:

12) If you want to allow other users to use ssh to access the slug, you will need to create the users in the normal way using the Linksys web interface, update the /etc/passwd file to allocate them a shell and give them a path to their home directory. The important thing will be to ensure that the directory is set up with appropriate permissions and also that the parent directories have appropriate permissions both for the public and for the groups. Once this folder has been created, then follow steps (5) to (7) to create keys for the user. Follow up by chowning the newly created folder to the new user, e.g.

February 03, 2005, at 09:33 AM by MattMcNeill --
Changed line 36 from:

NOTE: if when you logged in it came up with a messahe stating that the home directory could not be found, you need to create one and ensure that the permissions are correct. Permissions are very important, since OpenSSH checks very carefully them before allowing logins authenticated by keys.

to:

NOTE: if when you logged in it came up with a message stating that the home directory could not be found, you need to create one and ensure that the permissions are correct. Permissions are very important, since OpenSSH checks them very carefully before allowing logins authenticated by keys.

February 02, 2005, at 11:04 PM by ByronT --
Changed lines 68-69 from:
 i) Add an option into the OpenSSH? configuration script
 ii) Correct the OpenSSH? startup script so that it actually calls the configuration script (this imay be an error in the ipkg installation procedure ?)
to:
i) Add an option into the OpenSSH? configuration script
ii) Correct the OpenSSH? startup script so that it actually calls the configuration script (this imay be an error in the ipkg installation procedure ?)
February 02, 2005, at 04:28 PM by paulhar --
Deleted lines 2-3:

If you would like to use DropBear rather than OpenSSH then follow the http://www.nslu2-linux.org/wiki/HowTo/UseDropBearForRemoteAccess UseDropBearForRemoteAccess HowTo instead.

February 02, 2005, at 09:28 AM by MattMcNeill --
Changed lines 170-171 from:

<38>Jan 31 11:28:46 sshd[12798]: Illegal user test from 200.27.232.100 \\

to:

<38>Jan 31 11:28:46 sshd[12798]: Illegal user test from 200.27.232.100

February 02, 2005, at 09:27 AM by MattMcNeill --
Changed lines 117-172 from:

If you want to be able to access your files, upload and download over SSH then you need an SCP client. For myself, wanting to access my files over the internet securely from my Windows box at work, I downloaded WinSCP (http://winscp.sourceforge.net/) and simply configured it up, by entering the IP address, pointing to the key file and entering the username. It worked out of the box, I could browse all the files on the SLUG as if logged in to console.

to:

If you want to be able to access your files, upload and download over SSH then you need an SCP client. For myself, wanting to access my files over the internet securely from my Windows box at work, I downloaded WinSCP (http://winscp.sourceforge.net/) and simply configured it up, by entering the IP address, pointing to the key file and entering the username. It worked out of the box, I could browse all the files on the SLUG as if logged in to console.


Note: It is worth ensuring your internet connection is secured with SSH and also that you are limiting it to key access only. I had only exposed SSH through my firewall for a few hours when I notices scans like this in my /var/log/messages file:

<38>Jan 31 11:19:31 sshd[12585]: Did not receive identification string from 200.27.232.100
<38>Jan 31 11:24:40 sshd[12588]: Illegal user patrick from 200.27.232.100
<38>Jan 31 11:24:42 sshd[12590]: Illegal user patrick from 200.27.232.100
<38>Jan 31 11:24:55 sshd[12602]: Illegal user rolo from 200.27.232.100
<38>Jan 31 11:24:57 sshd[12604]: Illegal user iceuser from 200.27.232.100
<38>Jan 31 11:24:59 sshd[12606]: Illegal user horde from 200.27.232.100
<38>Jan 31 11:25:02 sshd[12608]: Illegal user cyrus from 200.27.232.100
<38>Jan 31 11:25:04 sshd[12610]: Illegal user www from 200.27.232.100
<38>Jan 31 11:25:06 sshd[12612]: Illegal user wwwrun from 200.27.232.100
<38>Jan 31 11:25:09 sshd[12614]: Illegal user matt from 200.27.232.100
<38>Jan 31 11:25:11 sshd[12616]: Illegal user test from 200.27.232.100
<38>Jan 31 11:25:13 sshd[12618]: Illegal user test from 200.27.232.100
<38>Jan 31 11:25:15 sshd[12620]: Illegal user test from 200.27.232.100
<38>Jan 31 11:25:18 sshd[12622]: Illegal user test from 200.27.232.100
<38>Jan 31 11:25:20 sshd[12624]: Illegal user www-data from 200.27.232.100
<38>Jan 31 11:25:22 sshd[12626]: Illegal user mysql from 200.27.232.100
<38>Jan 31 11:25:24 sshd[12628]: Illegal user operator from 200.27.232.100
<38>Jan 31 11:25:26 sshd[12630]: Illegal user adm from 200.27.232.100
<38>Jan 31 11:25:28 sshd[12632]: Illegal user apache from 200.27.232.100
<38>Jan 31 11:25:31 sshd[12634]: Illegal user irc from 200.27.232.100
<38>Jan 31 11:25:33 sshd[12636]: Illegal user irc from 200.27.232.100
<38>Jan 31 11:25:35 sshd[12638]: Illegal user adm from 200.27.232.100
<38>Jan 31 11:25:44 sshd[12646]: Illegal user jane from 200.27.232.100
<38>Jan 31 11:25:46 sshd[12648]: Illegal user pamela from 200.27.232.100
<38>Jan 31 11:25:59 sshd[12660]: Illegal user cosmin from 200.27.232.100
<38>Jan 31 11:27:28 sshd[12734]: Illegal user cip52 from 200.27.232.100
<38>Jan 31 11:27:30 sshd[12736]: Illegal user cip51 from 200.27.232.100
<38>Jan 31 11:27:35 sshd[12740]: Illegal user noc from 200.27.232.100
<38>Jan 31 11:27:45 sshd[12750]: Illegal user webmaster from 200.27.232.100
<38>Jan 31 11:27:47 sshd[12752]: Illegal user data from 200.27.232.100
<38>Jan 31 11:27:50 sshd[12754]: Illegal user user from 200.27.232.100
<38>Jan 31 11:27:52 sshd[12756]: Illegal user user from 200.27.232.100
<38>Jan 31 11:27:58 sshd[12758]: Illegal user user from 200.27.232.100
<38>Jan 31 11:28:00 sshd[12760]: Illegal user web from 200.27.232.100
<38>Jan 31 11:28:02 sshd[12762]: Illegal user web from 200.27.232.100
<38>Jan 31 11:28:04 sshd[12764]: Illegal user oracle from 200.27.232.100
<38>Jan 31 11:28:06 sshd[12766]: Illegal user sybase from 200.27.232.100
<38>Jan 31 11:28:08 sshd[12768]: Illegal user master from 200.27.232.100
<38>Jan 31 11:28:15 sshd[12770]: Illegal user account from 200.27.232.100
<38>Jan 31 11:28:17 sshd[12772]: Illegal user backup from 200.27.232.100
<38>Jan 31 11:28:19 sshd[12774]: Illegal user server from 200.27.232.100
<38>Jan 31 11:28:21 sshd[12776]: Illegal user adam from 200.27.232.100
<38>Jan 31 11:28:23 sshd[12778]: Illegal user alan from 200.27.232.100
<38>Jan 31 11:28:26 sshd[12780]: Illegal user frank from 200.27.232.100
<38>Jan 31 11:28:28 sshd[12782]: Illegal user george from 200.27.232.100
<38>Jan 31 11:28:30 sshd[12784]: Illegal user henry from 200.27.232.100
<38>Jan 31 11:28:32 sshd[12786]: Illegal user john from 200.27.232.100
<38>Jan 31 11:28:46 sshd[12798]: Illegal user test from 200.27.232.100
Cheeky, cheeky, cheeky !!!

January 30, 2005, at 09:34 PM by MattMcNeill --
Changed line 1 from:

This howto covers the setup and usage of the OpenSSH secure shell for remote command line access. OpenSSH is a fully featured daemon which also requires the OpenSSL libraries. It is more sophisticated than {http://www.nslu2-linux.org/wiki/HowTo/UseDropBearForRemoteAccess DropBear?} and has more advanced features such as agent forwarding. It may also get around some of the multiple user problems that people experienced with DropBear.

to:

This howto covers the setup and usage of the OpenSSH secure shell for remote command line access. OpenSSH is a fully featured daemon which also requires the OpenSSL libraries. It is more sophisticated than http://www.nslu2-linux.org/wiki/HowTo/UseDropBearForRemoteAccess DropBear and has more advanced features such as agent forwarding. It may also get around some of the multiple user problems that people experienced with DropBear.

Changed line 3 from:

If you would like to use DropBear rather than OpenSSH then follow the {http://www.nslu2-linux.org/wiki/HowTo/UseDropBearForRemoteAccess UseDropBearForRemoteAccess} HowTo instead.

to:

If you would like to use DropBear rather than OpenSSH then follow the http://www.nslu2-linux.org/wiki/HowTo/UseDropBearForRemoteAccess UseDropBearForRemoteAccess HowTo instead.

Changed line 73 from:

8i) Edit the ssh configuration file (I use {http://www.nslu2-linux.org/wiki/Unslung/Nano nano} as my editor on the slug, but you can use any editor of your choice)

to:

8i) Edit the ssh configuration file (I use http://www.nslu2-linux.org/wiki/Unslung/Nano nano as my editor on the slug, but you can use any editor of your choice)

Changed line 77 from:

To this file change the PasswordAuthentication? option to 'no' and uncomment it. (for the full set of configuration details for this file see the {http://www.openbsd.org/cgi-bin/man.cgi?query=sshd_config&sektion=5&arch=&apropos=0&manpath=OpenBSD+Current sshd_config man page}

to:

To this file change the PasswordAuthentication? option to 'no' and uncomment it. (for the full set of configuration details for this file see the http://www.openbsd.org/cgi-bin/man.cgi?query=sshd_config&sektion=5&arch=&apropos=0&manpath=OpenBSD+Current sshd_config man page

January 30, 2005, at 09:30 PM by dyoung --
Changed line 7 from:

1) Unsling your slug - see {http://www.nslu2-linux.org/wiki/Unslung/HomePage Unslung}

to:

1) Unsling your slug - see http://www.nslu2-linux.org/wiki/Unslung/HomePage Unslung

Changed line 117 from:

If you want to be able to access your files, upload and download over SSH then you need an SCP client. For myself, wanting to access my files over the internet securely from my Windows box at work, I downloaded WinSCP (http://winscp.sourceforge.net/) and simply configured it up, by entering the IP address, pointing to the key file and entering the username. It worked out of the box, I could browse all the files on the SLUG as if logged in to console.

to:

If you want to be able to access your files, upload and download over SSH then you need an SCP client. For myself, wanting to access my files over the internet securely from my Windows box at work, I downloaded WinSCP (http://winscp.sourceforge.net/) and simply configured it up, by entering the IP address, pointing to the key file and entering the username. It worked out of the box, I could browse all the files on the SLUG as if logged in to console.

January 30, 2005, at 07:09 PM by MattMcNeill --
Changed lines 1-117 from:
to:

This howto covers the setup and usage of the OpenSSH secure shell for remote command line access. OpenSSH is a fully featured daemon which also requires the OpenSSL libraries. It is more sophisticated than {http://www.nslu2-linux.org/wiki/HowTo/UseDropBearForRemoteAccess DropBear?} and has more advanced features such as agent forwarding. It may also get around some of the multiple user problems that people experienced with DropBear.

If you would like to use DropBear rather than OpenSSH then follow the {http://www.nslu2-linux.org/wiki/HowTo/UseDropBearForRemoteAccess UseDropBearForRemoteAccess} HowTo instead.

I have a Windows 2000 machine which I want to be able to use from work (behind a number of firewalls) to access the slug on my home broadband network. So what do I need to do?

1) Unsling your slug - see {http://www.nslu2-linux.org/wiki/Unslung/HomePage Unslung}

2) Install the OpenSSH package which gives you your SSH daemon. You can do this by executing the following via telnet.

# ipkg update
# ipkg install openssh

3) Reboot and check OpenSSH is running.

# ps -ef

And look for a line something like the following:

1735 root 3208 R /opt/sbin/sshd

4) OK so it's running. What the heck do you do now? Well, you need to get an SSH client for your Windows box. I use the free client called Putty (http://www.chiark.greenend.org.uk/~sgtatham/putty/) so that's what I'm going to talk about here. Download it and install.

5) Now we need to generate some keys. So run Start->Programs->Putty->Puttygen key generation program. Click the "generate" button to generate some new keys. In the top part of the window you will see a public key string something like the following (The key here has been shortened for display purposes. Your generated key will be a much longer string):

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAA......aJ3Wy+Ws4IZEgdJgPlTYUBWWtCWOGc= someone@hostname

This is what is called a public key.

6) First of all save your private key pair (*.ppk) file with a password to encrypt it.

7) Copy the public key similar to the string in (5) above to the clipboard. Now what we need to do is load that public key as an authorized key for 'root'. We'll look at other users later on.

First of all telnet into the SLUG as the user we want to authorise (e.g. root) and change to the home directory:

# cd ~/

NOTE: if when you logged in it came up with a messahe stating that the home directory could not be found, you need to create one and ensure that the permissions are correct. Permissions are very important, since OpenSSH checks very carefully them before allowing logins authenticated by keys.

# mkdir /root
# chmod a+rx /root
# chmod og-w /root

This should result in a folder which everyone can read but no-one but the owner (i.e. root) can write. Check this by:

# ls -l /

And look for a line which looks like the following (noting the dwrxw-xw-x particularly)

drwxr-xr-x 1 root root 0 Jan 30 16:21 root

Now create the hidden directory for the SSH settings

# mkdir .ssh
# cd .ssh

Once we have this we want to save our public key into the authorized keys file which can be done easily as follows (The key here has been shortened for display purposes. Your generated key will be a much longer string):

# echo ssh-rsa AAAAB3NzaC1yc2EAAAABIwAA......aJ3Wy+Ws4IZEgdJgPlTYUBWWtCWOGc= someone@hostname > authorized_keys

NOTE: I found problems using nano (small compact file editor) to create the file, because it kept changing the spacing and carriage returns which causes the key not to validate. The whole key should be on a single line.

Check that this file is not editable by anyone but the current user ensure that the write permissions are write only for the user (i.e. have a mask like -rwxr--r-- when you do an ls -l)

# chmod a+r authorized_keys
# chmod og-wx authorized_keys

8) OK so that should get us ready for authentication by key file. Furthermore we can prevent anyone logging in via SSH without a key. To do this we need to do two things:

 i) Add an option into the OpenSSH? configuration script
 ii) Correct the OpenSSH? startup script so that it actually calls the configuration script (this imay be an error in the ipkg installation procedure ?)

8i) Edit the ssh configuration file (I use {http://www.nslu2-linux.org/wiki/Unslung/Nano nano} as my editor on the slug, but you can use any editor of your choice)

# nano /opt/etc/openssh/sshd_config

To this file change the PasswordAuthentication? option to 'no' and uncomment it. (for the full set of configuration details for this file see the {http://www.openbsd.org/cgi-bin/man.cgi?query=sshd_config&sektion=5&arch=&apropos=0&manpath=OpenBSD+Current sshd_config man page}

8ii) To correct the startup script so that the updated configuration file is called up we have to edit the init.d script:

# nano /opt/etc/init.d/S40sshd

and change the line which startsup the daemon from:

/opt/sbin/sshd

to:

/opt/sbin/sshd -f /opt/etc/openssh/sshd_config

What we need to do is restart the SSH Daemon processe and restart them. This can be done simply by calling the script that we just edited:

# /opt/etc/init.d/S40sshd

9) Having set up the server as we want it all we have to do now is to connect with Putty. Start->Programs->Putty->Putty. It will come up with the options for the server (IP address etc) which you need to set. Also set up the SSH authentication by key - pointing the key to the *.ppk file that you created and saved in (6).

10) Click open and when requested log in as 'root'. It should authenticate using the keys and a shell prompt will appear.

login as: root
Authenticating with public key "root@slug" from agent

BusyBox? v0.60.4 (2004.07.01-03:05+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.

#

Voila!!

11) If you want to allow other users to use ssh to access the slug, you will need to create the users in the normal way using the Linksys web interface, update the /etc/passwd file to allocate them a shell and give them a path to their home directory. The important thing will be to ensure that the directory is set up with appropriate permissions and also that the parent directories have appropriate permissions both for the public and for the groups. Once this folder has been created, then follow steps (5) to (7) to create keys for the user. Follow up by chowning the newly created folder to the new user, e.g.

# chown -R mynewuser:everyone /home/mynewuserhome

If you want to be able to access your files, upload and download over SSH then you need an SCP client. For myself, wanting to access my files over the internet securely from my Windows box at work, I downloaded WinSCP (http://winscp.sourceforge.net/) and simply configured it up, by entering the IP address, pointing to the key file and entering the username. It worked out of the box, I could browse all the files on the SLUG as if logged in to console.