ipkg update
 ipkg install openssh-sftp-server

 chmod 777 /dev/null

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

(:tableend:)

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

(:tableend:)

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.

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

(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.)

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.

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 :)

• ipkg install openssh-sftp-server is required for sshfs* 27/6/8

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.

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.

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:)

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:

 cd /root

 chown john:john .ssh

 chown john:john authorized_keys

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

 ".\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

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.

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:

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.

 @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

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

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

(:tableend:)

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.

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:

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.

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:

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.

PuTTY Tray

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.

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

 BusyBox v0.60.4 (2005.03.22-06:52+0000) Built-in shell (ash)

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.

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".)

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.\\

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

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

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.\\

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"

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

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

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)

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):

 cd /root/.ssh

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.

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.

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.

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.

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)

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...)

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.

Better Interactivity

Secure Copy

Remote access to files over SSH

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

Change root jail

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

A security story

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

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).

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.

• Install OpenSSH server on Unslung
• Install and configure PuTTY in Windows
• Configure SSH server for public key access
• Connect to the Slug using PuTTY
• Configure SSH authentication for other users
• Other notes

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):

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.

Configure SSH Server for Public Key Access

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):

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:

 Authenticating with public key "root@SLUG"
 Passphrase for key "root@SLUG":

 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.

Voilà!!

Configure SSH Authentication for Other Users

 username:scwAynQfOwmF.:2000:501:Some user::/dev/null

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:)

 nano /etc/passwd

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.

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.

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.

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.

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.

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.

(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):

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):

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.\\

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):

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:

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

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-------).

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

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:

(: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.\\

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:)

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

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.

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

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

A security story

Change root jail

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

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

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.

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

Change root jail

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

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

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.

1. 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.

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

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

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".

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)
   \\

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-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".)

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

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.

(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.)

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.

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.)

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.

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)

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.

Install SSH daemon On Unslung

1. Unsling your slug - see Unslung

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

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.

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

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

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.

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.

Remote access to Samba shares over SSH

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.

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.)

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.)

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:\\

Cheeky, cheeky, cheeky !!!

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.

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--).

Remote access to files over SSH

A security story

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

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

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

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

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.

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 \\

1. 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.

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.

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.

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):

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.

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:

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)

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

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.

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.

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.

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

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 !!!

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.

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 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

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

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.

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.

3) Reboot and check OpenSSH is running.

And look for a line something like the following:

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):

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:

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.

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

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

Now create the hidden directory for the SSH settings

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):

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)

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)

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:

and change the line which startsup the daemon from:

to:

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:

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.

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.

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.