ssh-agent -t在[1]上对现有功能进行了简短的讨论，早在2001年就有一篇关于debian-devel [2]的帖子，希望提供不活动超时功能。SE [3]上针对选美也有类似的讨论。
我想知道地球上的其他地方如何保护ssh密钥-我是否错过了一些明显的东西，而这对于我来说却是一个痛苦点，而且显然没有其他人吗？具体来说，我在考虑脚本化的ssh交互，例如与ansible的交互。今天看来，您的选择是：
- 例如，将代理中密钥的有效期设置为令人担忧的长时间。1h或您的脚本的最大运行时间可能是（我怀疑很多人都允许他们的sudo re-auth超时延长这么长的时间！）-但是
seahorse/gnome-keyring-daemon几乎不支持这么多[4] - 长时间运行脚本，并每5/10/15分钟重新输入一次密码：现在您可以轻松地看到每天输入20次密码
- 破解您自己的自制解决方案以模仿此缺少的功能，也许与您的Shell的
TMOUTShell var 结合使用（感谢freenode #openssh IRC上的人员的建议） - 根本没有设置密钥生存期，即您的代理会永久加载您的密钥，或者直到您杀死/重新启动它为止
如果您对身份验证所使用的每种角色使用简短的ssh代理超时，强密码短语和不同的密钥文件，那么这一天会非常令人沮丧！
我已经尝试了gpgkey2ssh和智能卡，但这并不能真正解决这个特定问题：我仍然想要ssh-agent功能，并且我不想每隔5分钟重新进行身份验证只是为了防止我的私钥暴露我的计算机空闲时在内存中存储。
我做错了吗？
[1] 配置SSH代理的默认超时
[2] https://lists.debian.org/debian-devel/2001/09/msg00851.html
[3] /server/518312/putty-pageant-forget-keys-after-period-of-inactivity
[4] https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/129231
我不希望
—
csirac2
ssh-agent知道会话何时处于非活动状态，但是至少从上一次签名操作发生时（而不是每次ssh-agent启动时）开始超时。另外，我已经为每个脚本角色使用了单独的用户帐户和密钥文件，如果需要的话，sudoers仅允许对1或2条命令进行sudo'd处理，并且我lshell试图将其进一步锁定。但是所有这些仍然不能免除我保护我的sudo zfs send密钥文件的麻烦：仅因为给定密钥允许使用的唯一命令，对于使用该密钥的人来说，这是一个非常强大的命令！
另一个解决方法：为脚本使用
—
derobert
ControlMaster/ ControlPath/ ControlPersist选项（请参阅man ssh_config）。至少如果它仅连接到一台主机。
这是一个有趣的建议，它确实教会了我一些东西（谢谢！），但如果我仍然要
—
csirac2
ssh-agent保持我的钥匙直到重启（这可能要花上几个星期），似乎并不能解决任何问题。
ssh-agent所属的会话类型（例如tty会话，X11会话等）无关的情况下，如何检测会话不活动存在一些技术挑战。有一件事我会想如果可能不应该取决于你的代理加载关键的自动化脚本说。它们可能每个都应具有自己的私钥，该私钥通过适当服务器上的强制命令进行授权，以仅运行每个脚本需要运行的特定远程命令。那当然会让您从cron等运行这些程序