Our Blog

Ongoing observations by End Point people

GNU Screen + SSH_AUTH_SOCK; my new approach

By David Christensen
February 23, 2011

Over the years, I’ve played around with several different methods of keeping my forwarded SSH-Agent authentication socket up-to-date in long-running screen sessions (referenced via the $SSH_AUTH_SOCK shell variable). The basic issue here is that Screen sees the process environment at the time it was initially launched, not that which exists when reattaching in a subsequent login session. This means that the $SSH_AUTH_SOCK variable as screen sees it will refer to a socket which no longer exists (as it was removed when you logged out after detaching on the initial login when starting screen).

Some of my previous methods have included a hard-coded variable for the socket itself (downsides: if it’s a predictable name you’re potentially opening some security issues, plus if you open multiple sessions to the same account, you kill the latest socket), symlinking the latest $SSH_AUTH_SOCK to a hard-coded value on login (similar issues), dumping $SSH_AUTH_SOCK to a file, and aliasing ssh and scp to first source said file to populate the local window’s enviroment (doesn’t work in scripts, too much manual setup when adapting to a new system/environment, won’t work with any other subsystem not already explicitly handled, etc).

Recently though, I’ve come up with a simple approach using screen’s -X option to execute a screen command outside of screen and just added the following to my .bashrc:

screen -X setenv SSH_AUTH_SOCK "$SSH_AUTH_SOCK"

While not perfect, in my opinion this is a bit of an improvement for the following reasons:

  • It’s dirt-simple. No complicated scripts to adjust/maintain, just a command that’s almost completely self-explanatory.
  • It doesn’t kill the environment for existing screen windows, just adjusts the $SSH_AUTH_SOCK variable for new screen windows. This ends up matching my workflow almost every time, as unless a connection dies, I leave the screen window open indeterminately.
  • If you have multiple sessions open to the same account (even if not running both in screen), you’re not stomping on your existing socket.
  • Did I mention it’s dirt-simple?

There are presumably a number of other environment variables that would be useful to propagate in this way. Any suggestions or alternate takes on this issue?

environment sysadmin tips tools


Comments

Popular Tags


Archive


Search our blog