sshunder 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:
We also need to turn on 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":
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:
This is not the key itself, but its fingerprint, which is much more readable and sufficient for verifying that it is the correct value.
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:
This will echo the public key for the server, and you should confirm that it matches what you got from
sshabove. And if you look on the client (in a second Terminal window) in
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:
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:
Hit return to choose the default. It will prompt for a password---use a strong password. Then, you will get something like this:
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):
Test login by quitting Terminal and restarting, then do:
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.