次の失敗に悩まされていました:
<ブロック引用>エージェントは、キーを使用して署名しなかったことを認めました。
残念ながら、これは非診断メッセージです。対処できる (少なくとも) 2 つのクラスの問題があります。
キーがロードされていません
ほとんどの問題では、これはあなたの ssh-agent を意味します ターゲット サーバーのアカウントで受け入れられる ssh キーが読み込まれていません。この場合、この質問に対する @Networker の回答で指摘されているように、解決策はかなり単純です:キーを追加します:
ssh-add
キーがデフォルト以外の場所にある場合は、そのことを ssh-add に伝える必要があります :
ssh-add /path/to/key
エージェントがキーを理解できない
これは GNOME バグ 754028 であり、Seahorse 3.29.90 (2018 年 9 月 3 日にリリースされた安定版 3.30、Ubuntu 18.10、Fedora 29、およびおそらく Red Hat/CentOS 9 に含まれています) で解決されました。 3.29.90 より前の Seahorse (したがって GNOME キーリング) は、ed25519 のような新しいキー タイプや ssh-keygen -o -a 100 で生成されたキーを作成または追加できませんでした。 (Secure Secure Shell チュートリアルで提案されているとおり)。
この問題の診断:
ssh myserver「ssh エージェントが失敗を認めました」で失敗SSH_AUTH_SOCK= ssh myserver正常に動作します- 結論:
gnome-keyring複雑なキーを扱えない
このバグの実行可能な回避策を見つけたばかりで、どこにも公開されていないようです (Ubuntu のバグに追加したばかりのコメントを除いて)、ここに記載します。
回避策: 新しい ssh-agent を起動します gnome-keyring のものと同じソケットを使用 :
ssh-agent -a $SSH_AUTH_SOCK
これにより、ssh-agent の新しいインスタンスが起動されます (GNOME の能力の低いインスタンスを上書きします)、その中にキーはありません (seahorse にもかかわらず) それは古いエージェントに関連付けられているためです)。 ssh-add で追加する必要があります キーがロードされていませんに記載されているとおり 上記のセクション。
ログインするたびにこれを実行する必要があります (または手動で起動スクリプトに追加します)。古いソケットを保持したい場合は、mv $SSH_AUTH_SOCK $SSH_AUTH_SOCK.broken を実行します
ローカル マシンでこのコマンドを実行するだけで問題を解決できました (キーを生成した後):
$ ssh-add