debugging authorized_keys and ssh

I saw an interesting question this morning on ServerFault, entitled “SSH Prompts for password even though private keys are available, presented to server and known to it”.

• when my user is not already connected to the server (first ssh connexion), it prompts for password even though privates keys are availiable (PuTTY + Pagent). After that first connection, if I open a secondary or a third connection it gets connected with the keys.
• If I close all connections and open a new one it prompts for the password.
• If I have let say 4 open connections and I close the first one (the one that prompted for the password), the fifth connection will be opened with the keys

Now that is an interesting problem. The answer supplied, with follow-on comments was also interesting, but the process behind solving this is even more fascinating, I think.

The issue is that password-less logins should work. sshd_config has been set properly, and there is a set of matching keys in authorized_keys.

But it doesn’t work, obviously – or there’d be no question raised.

A list of items to look into, both from the supplied answer, and from my own thoughts (somebody else beat me to an answer):

• permissions on .ssh/authorized_keys (must be 600)
• verify sshd has been started/restarted post changes to sshd_config
• check to see if home directory is remotely mounted / mounted on demand
• check to see if key has a passphrase in use
• look at /var/log/auth.log for errors
• check to see if the home directory is encrypted (actual answer)

Debugging is something I have written about recently – it seems to come up over and over in my line of work.

It’s a skill that’s vital to have in the IT world, and yet an awful lot of folks do not.

The answer, for those interested:

It sounds like, for whatever reason, the user’s home directory is not available if the user is not logged in, so that sshd can’t find the authorized_keys file

…

The user’s home directory must be using ecrypt or something like that

…

that’d be the cause, then, since sshd can’t decrypt the contents of the home directory

…

Ubuntu Desktop asks if you want to encrypt the home directory (why not?) without mentioning what it may do to ssh… a simple “note: this will effect SSH…” would be helpful