We use screen a lot. We use ssh-agent a lot. But they don’t work well together. At least, not without some trouble.
The biggest problem was probably the fact that if you detach a screen and log out from the server, on next login and reattach, the shell in your screen isn’t able to find your ssh-agent anymore. This is not a really big problem in normal setups, but since we have disabled password-logins on many servers, this can be very annoying. It took me a little while to find a solution, but in the end implementing the “fix” was easy. The only problem is security, but it’s a relative small item.
First of all, on the machine on which I start screen, I need the following ~/.screenrc:
unsetenv SSH_AUTH_SOCK setenv SSH_AUTH_SOCK $HOME/.screen/ssh-auth-sock.$HOSTNAME
This is not shell-dependent, the syntax is internal to screen. It makes sure that the SSH_AUTH_SOCK variable point to a file in my home directory. Always the same file, which is probably what the security problem could be. But how does that file get created? For this, we need some code when starting our shell, for instance in my ~/.bash_profile:
_ssh_auth_save() {
ln -sf "$SSH_AUTH_SOCK" "$HOME/.screen/ssh-auth-sock.$HOSTNAME"
}
alias screen='_ssh_auth_save ; export HOSTNAME=$(hostname) ; screen'
This makes sure then when we start screen, a symlink is created from the file in our homedir to wherever the ssh-agent socket file is created by ssh-agent. This way, the environment variable within the screen is always set to the correct file. It’s a bit of a hack and as I said, I think there are some security concerns here (the random SSH_AUTH_SOCK file isn’t randomized just for fun, I presume), but I haven’t been able to think of a way to abuse it.
Thanks to Bart Trojanowski’s blog for this solution!