ssh special

Any good network administrator uses SSH extensively.

Of course, any network administrator also interested in security uses public/private key authentication as opposed to password authentication. ssh-agent adds a wonderful convenience to this system, eliminating the need to enter your password for every host you SSH to. Combined with ssh-agent forwarding (-A or ForwardAgent in ssh_config), you would only have to enter your password once when starting ssh-agent the very first time. See this article for a good lesson in how this works.

In addition, any good sysadmin probably uses screen in some pretty sick and twisted ways.

The problem is: screen and ssh-agent don’t really quite get along. This is because ssh-agent uses an environment variable to point at a socket that ssh uses to pass authentication requests to. If you’re re-attaching to a screen session, however, this environment variable will no doubt be out of date.

Following some advice that I got on the GNU Screen mailing list, I made a few changes that have saved me a lot of headaches.

Basically, I just made my .profile update a symlink to the ssh-agent socket created in /tmp. I then modified my .screenrc to set SSH_AUTH_SOCK to point at THIS file rather than the actual socket. This way it never gets out of date.

.profile:

if [ “x$SHLVL” = “x1” ]; then # we are a login shell
rm -rf /tmp/ssh-agent-sock-screen
ln -s $SSH_AUTH_SOCK /tmp/ssh-agent-sock-screen
fi

.screenrc:

unsetenv SSH_AUTH_SOCK
setenv SSH_AUTH_SOCK /tmp/ssh-agent-sock-screen

Now, when I log into X on my laptop, ssh-agent runs automatically, I add my keys, enter the passwords, and off I go – I never enter another password again!


Comments

Nice solution, except it’s broken in one very major respect:

If you log in twice into the same machine that .profile is set up on, you’ll clobber the /tmp/ssh-agent-sock-screen symlink which points to the first existing agent sessions’ socket.

You then get to manually figure out what agent is what (since they’re all mindlessly stored in /tmp with semi-unique identifiers), figure out which is the original (from your first ssh session to the machine), and re-setup the symlinks.

I go through this on a regular basis, and, needless to say, it’s bloody annoying. :-)

There is a way around this – by testing whether or not the shell is a “login” shell and then making sure you only clobber the symlink if it’s a login shell.

Then you have to make sure that, say, your first xterm runs a “login” shell, but every one after that is not a login shell – including others in screen..

Make sense?

Of course, I say this, but I never quite got it working right. I’ll try to fix my .bash_profile one of these days and post an update..

Nice idea, but what happens if you open two ssh-sessions? Or what happens if you connect from a Box without ssh-agent? That’s why I have written a litte startup-script, where you get asked if you want to change the link or not:

#!/bin/sh if [ -z $SSH_AUTH_SOCK ]; then echo “NO $SSH_AUTH_SOCK found… attatching without change… (Press ENTER)” read line screen -r else echo $SSH_AUTH_SOCK ls -l /tmp/ssh-agent-sock-screen echo “Renew the ssh-agent-sock-screen? (Y/n)” read line if [ “$line” = “y” ] || [ “$line” = “Y” ] || [ -z “$line” ]; then rm /tmp/ssh-agent-sock-screen ln -s echo $SSH\_AUTH\_SOCK /tmp/ssh-agent-sock-screen screen -r elif [ “$line” = “n” ] || [ “$line” = “N” ]; then screen -r else exit 0 fi fi

I hope some ppl out there like and use it… ;)

Common SenseApril 12, 2007 at 09:24 · reply

This page is a good argument for using passwords ;-)

Thanks! Your comment has been submitted and will appear shortly.


Leave a comment