Secure communications (3)

This is the third post in a series about remote login using ssh under OS X. The first two posts are here and here. This one is working through the details of the server/client setup using RSA, as described in this O'Reilly article (here, printable). The article also has a link to a page for online testing (of your security setup) by Symantec.

I don't normally bother to remind you that (as it says in the profile) YMMV---your mileage may vary. If you follow the notes here that I describe what I did, and your computer is reduced to a smoking heap of twisted metal in under 10 seconds, well, all I can do is to repeat myself: YMMV. So be careful.

For the server, we first need to set up a directory for keyfiles:

mkdir ~/.ssh

We also need to turn on remote login:

System Prefs > Sharing > Remote login

I always have everything locked down (nothing selected under Sharing) but for today we'll turn on the lights and the stereo. In the middle of the System Prefs window it will say something like "to log in to this computer remotely type":

ssh username@ipaddress

where ipaddress is something like 10.0.X.X. The default SSH port is port 22, which will be unblocked through the firewall automatically after you do this. Now, if you are on the same subnet as the server, from a second machine (say, my laptop) you can do:

ssh username@ipaddress The authenticity of host '10.0.X.X (10.0.X.X)' can't be established. RSA key fingerprint is [ 32 hexadecimal digits ]

This is not the key itself, but its fingerprint, which is much more readable and sufficient for verifying that it is the correct value.

Continues:

Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '10.0.X.X' (RSA) to the list of known hosts. Password: Last login: Sat Feb 5 15:19:19 2011 >

At the point where I typed yes, we were about to log in remotely. However, we could be fooled by a malicious evesdropper. At that point, we need to go to the server and do:

ssh-keygen -l -f /private/etc/ssh_host_rsa_key.pub

This will echo the public key for the server, and you should confirm that it matches what you got from ssh above. And if you look on the client (in a second Terminal window) in ~/.ssh:

> cat ~/.ssh/known_hosts 10.0.X.X ssh-rsa __ [ the same server public RSA key ]

To quote the article:

You normally should not see this message again since SSH has written down the key it asked you to check as a "trusted" key for future reference. If you see it again this may mean that someone is impersonating your server. You should immediately disconnect your computer, pick up your phone, and call your network administrator.

From the logged in client enter:

> say I sure love being inside this fancy computer

and hear the message on the server. The default is not Victoria any longer (for that add the option -v Victoria). Our log in currently uses password authentication, but we should really use something more secure. On the client do:

> ssh-keygen -b 1024 -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/Users/telliott/.ssh/id_dsa):

Hit return to choose the default. It will prompt for a password---use a strong password. Then, you will get something like this:

Your identification has been saved in /Users/telliott/.ssh/id_dsa. Your public key has been saved in /Users/telliott/.ssh/id_dsa.pub. The key fingerprint is: [ 32 hexadecimal digits ] telliott@localhost.local The key's randomart image is:

I won't show you the image, but it's pretty cool. Having generated a DSA (cousin of RSA) key pair, we copy our public key over to the server using a secure copy protocol in the current session (which was started with the log in password):

scp ~/.ssh/id_dsa.pub username@serverip:~/.ssh/authorized_keys The server wants a password (the account log in password) and outputs: Password: id_dsa.pub 100% 620 0.6KB/s 00:00 >

Test login by quitting Terminal and restarting, then do:

> ssh username@ipaddress Identity added: /Users/telliott/.ssh/id_dsa (/Users/telliott/.ssh/id_dsa) Last login: Sat Feb 5 15:27:51 2011 from 10.0.X.X >

It works! At this point it would be a good idea to disable automatic login on startup for your client laptop. If a black hat has access to this machine, (s)he could also easily compromise (at least) your account on the server.

Another thing is that if you fail to authenticate by the key (above) the SSH server will fall back on password authentication. We need to edit a file on the server to disable that service. In fact, I recommend turning off Remote Login until we figure that out.