web-dev-qa-db-ja.com

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:
ubuntusshmac-osxforwarding
60
pupeno

私のキーがエージェントになかったことがわかりました、そしてこれはそれを修正しました：

OS X：

ssh-add -K

Linux/Unix：

ssh-add -k

次のコマンドを使用して、ロードされたキーをリストできます。

ssh-add -l

ssh-add -L # for more detail
97
pupeno

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

  2. B1のpupeno/.ssh/authorized_keysに正しい公開鍵があることを確認し、authorized_keysの末尾に改行があるかどうかを確認します。

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

  4. ssh -Kを使用してGSSAPIベースの認証と転送を試す

8
Daniel Prata Almeida

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

ssh -vは当時：

debug1: Remote: Agent forwarding disabled: mkdtemp() failed: No space left on device
6
BartBiczBoży

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

6
W.Mann

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

〜/ .ssh/configファイル内の誤った空白も、頭をひっかくようにすることがあります。

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

# incorrect
Host foobar ForwardAgent yes

これの代わりに：

# correct
Host foobar
  ForwardAgent yes

私は、ホストのリストの下にあるディレクティブのインデントがないために、機能に違いがあると思われることもありますが、そうではない場合もあります。

2
Dale Anderson

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

  Host **Server_Address**
     ForwardAgent yes

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

 ssh-add -K

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

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

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

ssh -T [email protected]

ターゲットのgitリポジトリに対してlsリモートテストを実行する

git ls-remote --heads [email protected]:**account**/**repo**.git
0
Tahsin Turkoz