NSLU2-Linux
view · edit · print · history

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:

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

After installing the package, the OpenSSH server should be running. You can confirm this by 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 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.

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.

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.

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

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

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

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.

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)

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:

 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 -ld /root

and look for a line which looks like the following (noting the drwxr-xr-x particularly):

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

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
 mkdir .ssh
 chmod og= .ssh
 cd .ssh

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

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

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.

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

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

 chmod og= authorized_keys

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:

 nano /opt/etc/openssh/sshd_config

Inside this file, change the PasswordAuthentication option to no and uncomment it:

 PasswordAuthentication no

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

 /opt/etc/init.d/S40sshd

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:

 login as: root
 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ą!!

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

Configure SSH Authentication for Other 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. 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:

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

The meaning of these fields is:

 username:encrypted password:user id:group id:description:home directory:login shell

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:

 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:

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

Finally, change the login shell (the last field) to /bin/sh:

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

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:

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

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:

 cd ~
 mkdir .ssh
 chmod og= .ssh
 chown john:john .ssh
 cd .ssh

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

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

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

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.

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

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.

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 (ipkg install perl). For the mounting in SHFS, make sure all binaries and mount points have the appropriate ownership and accessibility.

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

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.

  chmod 777 /dev/null

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

Using Putty

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:

 @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

 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

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.

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

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.

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.

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>Auth, point to your .ppk key file -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"

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(approve sites). Another option is CopSSH which installs a minimalistic version of Cygwin specifically meant for running OpenSSH?.

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(approve sites)), use the following command:

 C:\cygwin\bin\ssh.exe -ax -c blowfish-cbc -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.


Change root jail

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


A security story

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

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