9

There are some brief discussions about the existing ssh-agent -t feature at [1], and there was a post as far back as 2001 on debian-devel [2] wishing for an inactivity timeout feature. There's a similar discussion here on SE [3] for pageant.

I have to wonder how the rest of the planet is protecting ssh keys - am I missing something obvious for this to be such a pain point for me, and apparently nobody else? Specifically I'm thinking of scripted ssh interactions, such as with ansible. It seems that today, your choices are:

  • Set the lifetime of your key in the agent to a worryingly long period of time, Eg. 1h or whatever the maximum running time of your scripts may happen to be (I doubt many people allow their sudo re-auth timeout to stretch that long!) - but seahorse/gnome-keyring-daemon barely even support this much [4]
  • Babysit your long-running scripts and keep re-entering your passphrase every 5/10/15 minutes: now you can be easily watched entering your passphrase 20 times a day
  • Hack your own home-brew solution to mimic this missing feature, perhaps in conjunction with your shell's TMOUT shell var (thanks folks on freenode #openssh IRC for that suggestion)
  • Don't have a key lifetime set at all, i.e. your agent keeps your key loaded forever or until you kill/reboot

If you're using brief ssh agent timeouts, strong passphrases, and different keyfiles for each type of role you authenticate as: this leads to a very frustrating day!

I've experimented with gpgkey2ssh and smartcards, but this doesn't really solve this particular issue: I still want ssh-agent functionality and I don't want to have to re-auth every 5 minutes just to prevent my private keys being exposed in memory while my computer is idle.

Am I doing it wrong?

[1] Configuring the default timeout for the SSH agent

[2] https://lists.debian.org/debian-devel/2001/09/msg00851.html

[3] https://serverfault.com/questions/518312/putty-pageant-forget-keys-after-period-of-inactivity

[4] https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/129231

Community
  • 1
csirac2
  • 171
  • 1
    Not an answer, but, yes, there are some technical challenges around how to detect session inactivity when ssh-agent is agnostic to the type of session it is part of (e.g. tty session, X11 session, or something else). The one thing I would like to say if that your automated scripts probably shouldn't be depending on the key loaded in your agent. They should probably each have their own private key, which is authorized via forced commands on the appropriate servers to run only the specific remote commands that each script needs to run. That would of course let you run those from cron etc... – Celada Mar 21 '15 at 05:56
  • I don't expect ssh-agent to know when a session is inactive, but at least start the timeout from whenever the last signing operation occurred, not just whenever ssh-agent was launched. Also, I already use separate user accounts and keyfiles for each script role, sudoers allows only 1 or 2 commands to be sudo'd if necessary, and I've looked at lshell to lock things down further.

    But all that still doesn't absolve me from needing to protect my keyfiles: just because sudo zfs send is the only command allowed for a given key, that's a pretty powerful command for whoever wields that key!

     – csirac2 Mar 21 '15 at 07:43
  • Another workaround: use the ControlMaster/ControlPath/ControlPersist options (see man ssh_config) for your script. At least if its only connecting to one host. – derobert Apr 24 '15 at 18:56
  • That's an interesting suggestion and it did teach me something (thanks!) but doesn't seem to solve anything if I'm still going to have ssh-agent keep my keys loaded until I reboot (which could be weeks). – csirac2 Apr 27 '15 at 07:15

1 Answers1

2

If this concerns you then you can easily use the xscreensaver-command -watch interface to run ssh-add -D when the screen is locked. Check the man page for a very simple example.

Marco d'Itri
  • 488