Posts tagged with “”

When SSH Public Key Authentication Fails

I’m no Sys Admin, but I connect to enough Unix machines often enough that enabling public key authentication is a real time saver. For those that may not know, public key authentication allows a user to login to another machine via SSH without a password. I’ve written a bit more about the technique itself in my archive. The other day, in the course of setting up authentication for several machines at work, I noticed that it worked for most of the machines but failed for a few others. After spending a little over an hour checking and double checking the files in my ~/.ssh directory, I spent another hour comparing files on the machines that weren’t working with the ones that were. Everything was precisely the same.

Except that it wasn’t. Evidently I neglected to read my own earlier post, specifically step 5. I had no idea that permissions were such a hot button, but it makes sense. The permissions on my ~/.ssh/authorized_keys file were 664. The boxes wouldn’t let me login because the file was writeable by someone other than me (at least in principle). As soon as I changed the permissions to 644, I was able to connect just fine.

Of course, I realize that this is by design and a very good thing, but I wasn’t expecting it so I stumbled over it.

SSH Host Key Checking

One of the things that’s always annoyed me, but not to such a degree that I’ve felt compelled to expend any effort “fixing” it, is the prompt that I get every time I SSH to a machine that I haven’t connected to before. It looks a little something like this:

The authenticity of host 'host.domain.tld (192.168.1.16)' can't be established.
RSA key fingerprint is 58:3d:dc:39:b3:5c:44:0b:ah:9b:7d:01:8e:f2:f8:77.
Are you sure you want to continue connecting (yes/no)?

Because it’s not a huge deal to type “yes” to create the connection, I’ve never cared enough to really look into it.

This morning, though, I was trying to do a pull from one of my git repositories only to find that the server signature had changed and my connection was terminated. As far as I know, the only way to re-establish a connection terminated for this reason is to remove that server from my list of known hosts. To do so I usually crack open my ~/.ssh/known_hosts file, find the line that begins with the host name of the server I’m trying to connect to and delete that line. The next time I try to connect, the server is added back to the file (after typing “yes” again).

Unfortunately, I was working on my Linux machine this morning and I got an unpleasant surprise when I opened my ~/.ssh/known_hosts file. Ubuntu, unlike every other Unix flavor I’ve worked with/in, encrypts the contents of that file. That meant I couldn’t find the line for the particular server whose signature changed for the purpose of surgical deletion. To reset that server as a known host, I’d have to delete the entire contents of the file. I connect to a number of servers and this has become a big file; I didn’t want to have to type “yes” that many times so a “fixing” the annoyance took on a greater urgency.

This is when it’s really handy to work with a Linux sys admin. He heard me expressing my annoyance in a semi-colorful manner and told me to just shut off the authentication prompt. Hearing the ability to kill two birds with one stone, I did a quick search, then cracked open my SSH config file (/etc/ssh/ssh_config) and edited the following line:

# StrictHostKeyChecking ask

I uncommented the line and changed the value to “no” and I’m no longer prompted when connecting to new machines. Now it’s safe to clear my known_hosts file without bother. I do still get a warning that a new host has been added to my file (which is nice), but no interaction is required.