SSH with public key authentication

Every time in the past that I've tried to set up SSH with public key encryption, it's always seemed like I'm doing it for the first time. There are, of course, a lot of HOWTO's on the web and I've made good use of them. This time when I went through the exercise, however, a few things struck me, and I thought it was worth capturing a few simple points.

The Setup:

I have a linux box at home to which I'd like to be able to SSH to from a variety of other hosts - both linux and PC's. The hosts are as follows:

1. The same linux box on which the server was running (just as a test).
2. A PC that is on the same LAN as the linux box. (Client is Putty).
   
3. A PC work laptop. (Client is Secure Shell).
   
4. The unix environment at work. (Using the usual linux/unix clients).
   

One observation is that the client list is heterogeneous both with regard to OS as well as to the specific client implementation.

A second observation is that unlike most config tasks you do as a linux sysadmin, setting up SSH is very client-centric. By this I mean that aside from editing /etc/ssh/sshd_conf (I'll want do disallow password authentication for example, and only allow public key authentication), the rest of the config is done entirely from the client perspective.

This seems obvious in retrospect and furthermore makes sense because in the real world, most folks don't have root privileges on the host that they want to SSH to.

General Approach:

1. For each client - we generate a key pair. How this is done depends on the OS and the client software being used. For *nix it's by means of ssh-keygen. For Windows it's done within the particular client software. In all cases, we generate a public key, a private key, and a passphrase that unlocks the private key.
2. The private key is kept on the client and should have the most restrictive file permissions.
3. It's safest to avoid zero-length passphrases but instead configure a passphrase so that the security provided by the private key is now both something you have and something you know. The passphrase is used by the client to decrypt the private key.
   
4. The public key is uploaded to the server and typically stored in the file ~/.ssh/authorized_keys (although this is configurable by means of the sshd_conf file). Typically we append (>> operator) the key to the file so as to have multiple keys in the same file.
   
5. There is one more important issue to consider. Some clients (seems like especially Windows clients) generate public keys that are not in the correct format. Linux's sshd wants/needs public keys that are in a single line format. What I learned this time is that the incorrect format is termed "SSH2-compatible format" and what linux's sshd expects is "Open SSH format". To fix this run ssh-keygen with the -i option and also we give it -f and the filename of the public key. This does the necessary conversion (and puts the result in stdout).
   

   ssh-keygen -i -f <my_id_rsa.pub>

I found it helpful when debugging this setup to start the sshd process with a different port and in non-daemon mode with maximum debugging turned on. E.g.

/usr/sbin/sshd -d -p 1234

Then one can point the client to this new port, 1234, and get the benefits of the sshd debug output.