YubikeyでSSHキーを使用しているので、ssh-agentの代わりにgpg-agentを使用しています。これは、標準的な癖(時々scdaemonを殺さなければならない)を除いて、基本的に正常に機能しています。
ただし、SSHキー転送は機能していないようです。
これが私の設定です:
Yubikeyが挿入されたOffice(RedHat 7.6)、opensshおよびgpg-agent-> destinationを使用:動作します。
PuTTYとgpg-agentを使用してYubikeyが挿入されたホーム(Windows 10)-> Office:動作します
ホーム->オフィス(gpg-agent)->宛先:エラーメッセージ「エージェントが操作を拒否しました」。
ホーム->オフィス(ssh-agent)->宛先:動作します(実際にはテストしていませんが、以前に何度もセットアップしました)。
HomeのPuTTY接続とOfficeの/ etc/ssh/sshd_configでエージェント転送を有効にしました。
私は何か間違ったことをしていますか、それともgpg-agentは仲介者であるときにエージェント転送をサポートしていませんか?
エージェント転送がどのように機能するかについて、多少誤解しています。
秘密鍵はどこにも送信されません。エージェント転送は反対のメカニズムを使用します。リモートシステムで実行されているSSHクライアントは署名要求をローカルシステムに送り返します。ここで、ローカルのgpg-agentが操作を実行し、結果を送り返します。
(さらに、スマートカードから秘密鍵を抽出することは不可能であるため、ローカルのgpg-agentでさえ実際の秘密鍵を持っていません。)
「仲介エージェント」のようなものはありません。唯一の中間ソフトウェアはローカルSSHクライアントとリモートsshdデーモンです。リモートシステムは、転送を処理するためにssh-agentsまたはgpg-agentsを開始しません。すでに実行されている場合、それらは完全に未使用のままであり、この接続を認識しません。
自宅にいて、エージェント転送を有効にして(たとえば)HOMEからOFFICEに接続すると、sshdプロセスが所有するソケットを指す$ SSH_AUTH_SOCKが表示されます。ログイン–スタンドアロンエージェントプロセスではありません。 (Sudo lsof $SSH_AUTH_SOCK
で確認できます。)
チェックで、リモートシステムが実際に$ SSH_AUTH_SOCKを独自のssh-agentまたはgpg-agentプロセスにポイントしていることが示された場合、それは問題です。サーバーがエージェント転送要求を受け入れていないか、ログインスクリプト(〜/ .profileなど)が環境変数を不必要に上書きしています。
次に、OFFICEからさらに別のサーバーに接続しようとすると、OFFICEのsshクライアントは、そのソケットを介してローカルエージェントに直接署名要求を送信します。ほとんどの場合から区別できませんローカルリクエスト。(ローカルエージェントは、ローカルsshクライアントのみをこのリクエストを行っていると見なすため、エージェント転送を「サポートしない」オプションはありません。)
ローカルエージェントがこの要求を拒否した場合、トラブルシューティングプロセスは通常の直接接続の場合とほとんど同じです。gpg-agentの場合は、$ GPG_TTYが設定されていることを確認してください。必要に応じて、最初の接続を行う前にgpg-connect-agent updatestartuptty /bye
を実行し、他の端末からのgpgコマンドを使用しないように注意してください。