Three SSH tips (Shallow Thoughts)

Three SSH tips

Today I have three tips I've found useful with ssh.

Clearing ssh control sockets

We had a network failure recently while I had a few ssh connections open. After the network came back up, when I tried to ssh to one host, it always complained Control socket connect(/home/username/ssh-username@example.com:port): Connection refused -- but then it proceeded to connect anyway. Another server simply failed to connect.

Here's how to fix that: on the local machine -- not the remote one -- there's a file named /home/username/ssh-username@example.com:port. Remove that file, and ssh will work normally again.

Connection Sharing

I think the stuck control socket happened because I was using ssh connection sharing, a nifty feature introduced a few years back that lets ssh-based commands re-use an existing connection without re-authenticating.

Suppose you have an interactive ssh session to a remote host, and you need to copy some files over with a program like scp. Normally, each scp command needs to authenticate with remotehost, sometimes more than once per command. Depending on your setup and whether you're running a setup like ssh-agent, that might mean you have to retype your password several times, or wait while it verifies your host key.

But you can make those scps re-use your existing connection. Add this to .ssh/config:

Host *
  ControlMaster auto
  ControlPath ~/ssh-%r@%h:%p

Eliminating strict host key checking

The final tip is for my biggest ssh pet peeve: strict host key checking. That's the one where you ssh to a machine you use all the time and you get:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

... and many more lines of stuff like that. And all it really means is something like

• that machine has re-installed its OS, or rebooted into a different distro; or
• the DHCP server has given that IP address to a different machine from the one that had it last time.

The really frustrating thing is that there's no flag you can pass to ssh to tell it "look, it's fine, just let me in." The only solution is to edit ~/.ssh/known_hosts, find the line corresponding with that host (not so easy if you've forgotten to add HashKnownHosts no) so you can actually see the hostnames) and delete it -- or delete the whole ~/.ssh/known_hosts file. ssh does have an option for StrictHostKeyChecking no, and the documentation implies it might help; but it doesn't get you past this error, and it doesn't prevent ssh asking for confirmation when it sees a new host, either. I'm not sure what it actually does.

What does get you past the error? Here's a fun trick. Add a stanza like this to .ssh/config:

Host 192.168.1.*
  StrictHostKeyChecking no
  UserKnownHostsFile /dev/null

Translation: for every host on your local net (assuming it's 192.168.1), pretend /dev/null has the list you'd normally get from ~/.ssh/known_hosts. Since there's definitely no host line there matching your intended remote host, it will ask you whether it's okay, then connect.

I wish I could find a way to eliminate the prompt too (I thought that was what StrictHostKeyChecking no was supposed to do); but at least you can just hit return, which is a lot easier than editing known_hosts every time.

And yes, this all makes ssh less secure. You know what? For hosts on my local network, that are sitting in the same room with me, I'm really not too concerned about that.

Tags: linux, ssh
[ 17:53 Apr 27, 2011    More linux | permalink to this entry | ]