fighting the lack of good ideas

reading again

Wow. It’s been several months since I last posted a book review. I have been reading in the mean time – just haven’t gotten around to posting any of them hereon.

In the intervening months I’ve read 1434 by Gavin Menzies (follow-on to 1421) and The Lost City of Z by David Grann. I’m currently reading Netherland by Joseph O’Neill and Radical by David Platt.

I also bought a Kobo ereader at one of the Border’s stores in Louisville, and my wife and I have started reading The Adventures of Huckleberry Finn by Mark Twain together.

I’m sure there have been others, too – but I’ll be posting reviews of them over the coming weeks.

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