One of the things that I do from home is that I log in to my office workstation and then from my office workstation I log in to other machines. This works conveniently when I have unencrypted SSH keys on the office workstation, but problems develop in a straightforward implementation of encrypted keys; now I can no longer ssh from my office workstation to other machines without being challenged for either the passphrase to the keys or the remote password.

Part of this can be solved with SSH agent forwarding. If I enable it for the connection from my home machine to my office machine, ssh'ing from my office machine to other machines can use the SSH agent on my home machine (and thus the unlocked keys it holds). This does rely on a somewhat relaxed approach to authorized key source access restrictions in that other machines have to accept my home SSH key identity from my office workstation.

(SSH agent forwarding is somewhat dangerous in that anything running on my office workstation can potentially make use of my home SSH keys. Of course the same is true if I unlocked my office workstation's SSH keys via a local ssh-agent or the like.)

What this doesn't deal well with is screen, or rather a screen session once I've detached from it and then reattached to it. If I just start screen it will inherit the current connection's SSH agent forwarding, but that inheritance breaks once I disconnect; when I log back in I'll have a different SSH agent forwarding and the old one that's preserved inside screen will not work any more.

There turn out to be two half solutions to this, depending on what behavior you want while you're detached from screen. If you don't need ssh to work inside screen while it's detached (eg if you don't have a script running or something), the simple solution is to rewire where the $SSH_AUTH_SOCKET environment variable points so that it goes to a constant place; see this article by Alan Pinstein for details (or here for another version).

(One simple way to set up the SSH agent socket symlink is just to have a cover script for screen that recreates the symlink. This insures that it only gets done when necessary, so that if you just log in another time you don't perturb an existing screen session.)

If you want processes inside screen to keep being able to make ssh connections even when your screen session is detached, then screen needs to run its own ssh-agent (and you have to unlock keys for that ssh-agent). Screen makes this awkward to do since it doesn't directly provide, say, a 'run this command on startup' option; however there are hacky workarounds, such as the one covered in this article by Charles Fry.

PS: I don't want to have my encrypted SSH keys unlocked on my office workstation at all times once I've logged in to it; I actively want them to be locked when I step away from the machine and do things like lock the screen. It would be a compromise to have SSH keys unlocked permanently in a running (but detached) screen session.

(These are the 'unresolved issues with encrypted keys' I mentioned in yesterday's notes on migrating to encrypted SSH keys.)

Sidebar: my likely solution

I have an automated script that runs inside my screen sessions that makes ssh connections, but all it does with them is run a mail status reporting command. What I'll probably do is give that script its own SSH identity with an unlocked key, restrict that key heavily on the destination systems (with eg a 'command=...' setting), and then use the $SSH_AUTH_SOCKET approach to enable me to make other SSH connections from inside screen. That's going to be both easier and more secure than running a full-blown ssh-agent setup from inside screen.