== The problem of encrypted SSH keys and _screen_

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 SshIdentitiesSuggestions]] 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
http://www.reasonablyopinionated.com/2009/03/automatically-reconnecting-to-ssh-agent.html]]
for details (or [[here
https://gist.github.com/martijnvermaat/8070533]] 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 http://screen.frogcircus.org/ssh-agent]].

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
../linux/EncryptedSSHKeyMigration]].)

=== 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_.