SSHエージェントから特定の転送キーを使用しますか？

Githubのキーと他のキーがあるとしましょう。ssh-add -L自宅のコンピューターAでsshエージェントに多数のキーを追加しました（たくさんの行を返します）A.で、.ssh/configどのホストでどのキーを使用するかを設定しました。

ssh -T -vvv git@github.com 2>&1 | grep Offering

与える

debug1: Offering RSA public key: /Users/doxna/.ssh/id_rsa.github

予想どおり、1つのキーのみが提供されます。しかし、その後、いくつかのホストBにssh-ingしForwardAgent yesて同じコマンドを繰り返して、私は

debug1: Offering RSA public key: /Users/doxna/.ssh/id_rsa.linode2
debug1: Offering RSA public key: /Users/doxna/.ssh/id_rsa.helium
debug1: Offering RSA public key: /Users/doxna/.ssh/id_rsa.github

つまり、すべてのキーを試します。サーバーが戻る前に限られた数のキーしか試すことができないので、これは問題Too many authentication failuresです。そこで.ssh/config、ホストBで編集して、

Host github.com
  IdentityFile /Users/doxna/.ssh/id_rsa.github
  IdentitiesOnly yes

しかし、私はキーの提供を取得しませんが、むしろ

debug2: key: /Users/doxna/.ssh/id_rsa.github ((nil))

これは、キーが見つからなかったことを意味します（？）そして、結局のところ、キーはホストBではなく自宅のコンピュータAにあるので、ホストBでそれを参照する方法は問題ですか？質問を説明できたと思います。

ssh ssh-agent

— ダンミカロ
ソース

回答:

あなたは正しい考えを得ました。不足している唯一の部分は、が指すファイルIdentityFileが存在する必要があるということです。秘密鍵を含める必要はありません。公開鍵だけがあれば十分です。

ホストBでは、次のように入力してエージェントから公開キーを抽出し、ssh-add -L | grep /Users/doxna/.ssh/id_rsa.github > ~/.ssh/id_rsa.github.pubそのファイルをポイントできます。~/.ssh/config

— カスパード
ソース

参考までに、公開鍵の名前は重要ではありません。コンテンツに基づいてエージェントから適切なキーを選択します。

— アコスタディノフ

@akostadinovはい。sshプライベートキーファイルが関連付けられていないパブリックキーファイルをポイントする場合、ファイルからパブリックキーを読み取り、エージェントに対応するプライベートキーを使用して署名を生成させるだけです。

— カスペルド

これにより、ホストBのキーが効果的に保存されます！サーバーにキーを保存しないソリューションについては、@ mc0eによる以下の回答を参照してください。

— ピット

@ピットいいえ、そうではありません。公開鍵のみを保存します。そして、そもそも公開鍵が決して秘密にされることは期待されていなかったので、それは問題ではありません。エージェント転送は、エージェント転送が行われている限り、ホストがキーを使用するためのアクセスを許可しますが、エージェントは秘密キーをどこにも送信しません。

— カスパード

@kasperdでは、キーを使用してユーザーエージェントにライブ接続している間、秘密キーの実際のコピーは必要ありません。rootとして、ログインしている他のユーザーのエージェント接続にアクセスできます。

— mc0e

@Kasperdからの良い答えですが、ホストBが危険にさらされた場合、またはホストBのルート特権を持つすべてのホストを信頼していない場合は、ログインしている限り、すべてのキーを不正使用にさらしていることに注意してくださいそのホストに。

したがって、より良いアプローチは、必要なキーへのアクセスのみを転送することです。ssh-agent-filterdebian / Ubuntuリポジトリ、またはgithubにあるものを試してみてください。

編集：キーを選択的に転送するのでssh-identはなく解決しましたが、ssh-agent-filter期待するほどスムーズな体験ではありません。

— mc0e
ソース

彼の答えに対する@kasperdのコメントから：「それはありません。公開鍵のみを保存します。公開鍵はそもそも秘密にされることは決して期待されていなかったので問題はありません。エージェント転送が行われている限りキーを使用しますが、エージェントはどこにもシークレットキーを送信しません」

— -Bdoserror

@Bdoserror rootとして、関連付けられたユーザーがログインしている間にssh-agent接続を悪用できSSH_*ます。実際のコピーがなくても、環境変数をコピーして、キーを使用したい場所にログインするだけです。

— mc0e

明確にするために：この答えは確かに間違っています-mc0eからの不正使用シナリオは現実ですが、公開鍵の保存とは関係ありません-中間ホストが危険にさらされた場合、エージェント接続を使用して秘密鍵で認証できます中間ホストに公開鍵を保存するかどうか。秘密鍵は侵害されず、公開鍵を保存しても簡単にはなりません。エージェントに接続している攻撃者は、とにかく公開鍵を要求できるからです。

— モニカを

@ marc-lehmannは私が書いたものを読み直しました。キーを転送すると公開されますが、転送するキーを制限できます。

— mc0e

私はあなたが書いたものを読みます-人ではなく、私たちのコメントの内容に対処してください問題は、あなたが書いているように、鍵がリモートホストに「転送される」と仮定しているため、答えが単に間違っているということです。そのようなことは発生せず、キー自体は公開されません。

— モニカを