ssh-agent -t[1]で既存の機能についていくつかの簡単な議論があり、2001年までさかのぼってdebian-devel [2]に非アクティブタイムアウト機能を希望する投稿がありました。SEのページェントに関する同様の議論がここ[3]にあります。
地球の他の部分がどのようにSSHキーを保護しているのか疑問に思います。これが私にとってこのような問題点であると思われる明らかなものを欠いているのでしょうか。具体的には、ansibleなどのスクリプト化されたssh対話について考えています。今日、あなたの選択は次のようです：
- エージェントでのキーの有効期間を心配なほど長い期間に設定します。1hまたはスクリプトの最大実行時間は偶然かもしれません（多くの人がsudo re-authタイムアウトがそれだけ長くなることを許可しているのではないかと思います！）-
seahorse/ /gnome-keyring-daemonこれもほとんどサポートしていません[4] - 実行時間の長いスクリプトをベビーシットし、5/10/15分ごとにパスフレーズを再入力し続けます。パスフレーズの入力を1日20回簡単に見ることができます
- おそらくシェルの
TMOUTシェル変数と組み合わせて、この欠けている機能を模倣する独自の自家製ソリューションをハックしてください（その提案についてはfreenode #openssh IRCの人々に感謝します） - キーの有効期間を設定しないでください。つまり、エージェントはキーを永久にロードするか、強制終了または再起動するまでキーをロードし続けます
sshエージェントの短いタイムアウト、強力なパスフレーズ、認証するロールのタイプごとに異なるキーファイルを使用している場合、これは非常にイライラする1日につながります。
私はgpgkey2sshとスマートカードで実験しましたが、これはこの特定の問題を実際に解決しません：ssh-agent機能が引き続き必要で、秘密鍵が公開されないようにするためだけに5分ごとに再認証する必要はありませんコンピュータがアイドル状態のときにメモリに。
私はそれを間違っていますか？
[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
ssh-agentセッションがいつ非アクティブになるかはわかりませんが、少なくとも、起動されたときだけでなく、最後の署名操作が発生したときからタイムアウトssh-agentを開始します。また、私はすでに各スクリプトロールに個別のユーザーアカウントとキーファイルを使用しています。sudoersでは、必要に応じて1つまたは2つのコマンドのみをsudoすることができますlshell。また、さらにロックするために調べました。しかし、それでも、キーファイルを保護する必要がなくなるわけではありません。sudo zfs send特定のキーに許可されているコマンドがだけであるため、そのキーを使用する人にとっては非常に強力なコマンドです。
別の回避策：スクリプトに
—
derobert、2015
ControlMaster/ ControlPath/ ControlPersistオプション（を参照man ssh_config）を使用します。少なくとも1つのホストにのみ接続している場合。
これは興味深い提案であり、私に何かを教えてくれました（ありがとう！）が、
—
csirac2
ssh-agent再起動するまでキーをロードしたままにしておくと何も解決しないようです（数週間かかる場合があります）。
ssh-agentであるセッションのタイプ（ttyセッション、X11セッションなど）にとらわれない場合に、セッションの非アクティブを検出する方法に関していくつかの技術的な課題があります。自動化されたスクリプトがエージェントに読み込まれたキーに依存するべきではないと私が言いたいことが 1つあります。おそらく、それぞれに独自の秘密鍵が必要です。秘密鍵は、適切なサーバーで強制コマンドを介して、各スクリプトの実行に必要な特定のリモートコマンドのみを実行することを許可されています。もちろん、cronなどからそれらを実行できます...