sshエージェントの転送が機能しないのはなぜですか？

MacOSXを実行している自分のコンピューターでは、これは〜/ .ssh / configにあります

Host *
ForwardAgent yes
Host b1
ForwardAgent yes

b1は、Ubuntu 12.04を実行している仮想マシンです。私はこのようにsshします：

ssh pupeno@b1

また、公開鍵をすでにコピーしているため、パスワードを求められることなくログインします。転送のため、私はb1からpupeno @ b1にsshできるはずで、パスワードを要求することなく機能するはずですが、機能しません。パスワードの入力を求められます。

私は何が欠けていますか？

これは、2番目のsshの詳細出力です。

pupeno@b1:~$ ssh -v pupeno@b1
OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to b1 [127.0.1.1] port 22.
debug1: Connection established.
debug1: identity file /home/pupeno/.ssh/id_rsa type -1
debug1: identity file /home/pupeno/.ssh/id_rsa-cert type -1
debug1: identity file /home/pupeno/.ssh/id_dsa type -1
debug1: identity file /home/pupeno/.ssh/id_dsa-cert type -1
debug1: identity file /home/pupeno/.ssh/id_ecdsa type -1
debug1: identity file /home/pupeno/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 35:c0:7f:24:43:06:df:a0:bc:a7:34:4b:da:ff:66:eb
debug1: Host 'b1' is known and matches the ECDSA host key.
debug1: Found key in /home/pupeno/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/pupeno/.ssh/id_rsa
debug1: Trying private key: /home/pupeno/.ssh/id_dsa
debug1: Trying private key: /home/pupeno/.ssh/id_ecdsa
debug1: Next authentication method: password
pupeno@b1's password:

私の鍵はエージェントになかったことが判明し、これにより修正されました：

OS X：

ssh-add -K

Linux / Unix：

ssh-add -k

ロードされたキーをリストするには、次を使用します。

ssh-add -l

ssh-add -L # for more detail

1. ./ssh/id_rsa .ssh/id_dsa .ssh/id_ecdsaファイルに、ユーザーが所有し、chmoded 600である必要がある正しい許可があるかどうかを確認します。

2. pupeno/.ssh/authorized_keysb1に正しい公開キーがあることを確認しauthorized_keys、キーの最後に改行があるかどうかを確認します。

3. ssh-agentが実行されているかどうかを確認し、経由でキーをロードしてみてください ssh-add

4. GSSAPIベースの認証と転送を試してください ssh -K

/ tmpにスペースが残っていないため、sshdサーバーがエージェント転送要求を拒否する問題がありました。これは、sshdが/ tmpにソケットを作成する必要があるためです。ディスクをクリーンアップすると問題が解決しました。

ssh -vは当時言いました：

debug1: Remote: Agent forwarding disabled: mkdtemp() failed: No space left on device

もう1つの考えられる理由は、接続の共有です。エージェントの転送と接続の共有が有効になっていない状態で、もう一方のホストに既にログインしている可能性があります。ssh -A共有接続を介した（または構成ファイルで同等に指定された）2回目のログインでは、警告なしに-Aフラグが無視されます。完全にログアウトするか、2回目のログインの接続共有を無効にした後にのみ、エージェントの転送が機能します。

この質問に到着した他のグーグルの利益のために：

〜/ .ssh / configファイル内の空白が間違っていると、頭に傷がつくこともあります。

私は最近、これを持っていた私の同僚の一人を助けました：

# incorrect
host foobar ForwardAgent yes

これの代わりに：

# correct
host foobar
  ForwardAgent yes

また、ホストのリストの下でディレクティブのインデントが欠落していると、想定されていなかったとしても機能に違いが生じる場合があります。

.ssh / configファイルに次の行を追加します

  Host **Server_Address**
     ForwardAgent yes

SSHエージェントにキーを追加

 ssh-add -K

リモートサーバーに接続する

ssh -v **username**@**Server_Address**

GitHubに対して接続テストを実行する

ssh -T git@github.com

対象のGitリポジトリに対してlsリモートテストを実行する

git ls-remote --heads git@github.com:**account**/**repo**.git