主页 / server / 问题 / 404447
Accepted
Pablo
Asked: 2012-07-04 08:32:45 +0800 CST

为什么 ssh 代理转发不起作用？

  • 772

在我自己的电脑上，运行 MacOSX，我在 ~/.ssh/config 中有这个

Host *
ForwardAgent yes
Host b1
ForwardAgent yes

b1 是运行 Ubuntu 12.04 的虚拟机。我 ssh 是这样的：

ssh pupeno@b1

而且我没有被要求输入密码就登录了，因为我已经复制了我的公钥。由于转发，我应该能够从 b1 ssh 到 pupeno@b1，它应该可以工作，而不需要我输入密码，但事实并非如此。它要求我输入密码。

我错过了什么？

这是第二个 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:
ubuntu mac-osx ssh forwarding

11 个回答

  1. Best Answer

    事实证明我的密钥不在代理中，这修复了它：

    操作系统：

    ssh-add -K

    Linux/Unix：

    ssh-add -k

    您可以使用以下方式列出加载的密钥：

    ssh-add -l

ssh-add -L # for more detail
    • 114

  2. 另一个可能的原因是连接共享：一个人可能已经在没有启用代理转发和连接共享的情况下登录到另一台主机。ssh -A通过共享连接的第二次登录（或在配置文件中等效指定）将静默忽略该-A标志。只有在完全注销或禁用二次登录连接共享后，代理转发才会起作用。

    • 14

    1. 检查您的~/.ssh/id_rsa ~/.ssh/id_dsa ~/.ssh/id_ecdsa文件是否具有正确的权限，您的用户应该拥有这些权限并进行 chmoded 600。

    2. pupeno/.ssh/authorized_keys检查b1上的公钥是否正确，并检查authorized_keys密钥末尾是否有换行符。

    3. 检查你是否有 ssh-agent 运行，尝试通过加载密钥ssh-add

    4. 尝试基于 GSSAPI 的身份验证和转发ssh -K

    • 8

  4. 由于 /tmp 中没有剩余空间，我遇到了 sshd 服务器拒绝代理转发请求的问题。这是因为 sshd 需要在 /tmp 中创建套接字。清理磁盘解决了我的问题。

    ssh -v 当时说：

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

  5. 为了也遇到这个问题的其他谷歌员工的利益：

    ~/.ssh/config 文件中不正确的空格也会导致一些头疼。

    我最近帮助了一位有此问题的同事：

    # incorrect
host foobar ForwardAgent yes

    而不是这个：

    # correct
host foobar
  ForwardAgent yes

    我还遇到过这样的情况，主机列表下指令的缩进缺失对功能产生了影响，即使它不应该如此。

    • 4

  6. 对我来说，只是我连接到的主机（原始海报示例中的b1）正在运行它自己的 persistent ssh-agent。我看不到任何调试输出来解释发生了什么，主机只是默默地使用它的现有内容ssh-agent并且没有发生转发。回想起来，这对我来说很有意义：p

    转发就像 ssh 端口转发：它是隧道，而不是客户端-服务器协商。

    我认为是后者——ssh-agent代理转发需要在主机上运行，​​所以我在一开始就设置了它，但这是一个错误。

    请参阅以下示例：

    首先，我在没有代理转发的情况下通过 ssh 托管ccam（一个树莓派），并确认没有代理套接字或添加的密钥：

    无代理转发

    其次，我进行编辑.bashrc以确保 ssh-agent 在主机上运行（这是我的错误）。您可以看到当我使用-A启用代理转发重新连接时，代理套接字存在，但代理没有身份（我现在意识到这是因为它显示的是本地 ssh-agent 套接字而不是转发的套接字）：

    向主机添加了 ssh-agent

    最后，我删除了ssh-agentraspberry-pi 主机（未显示）上的并重新连接。您可以在使用检查时看到密钥终于可用ssh-add -L：

    成功转发 ssh key

    • 4

  7. 将以下行添加到 .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
    • 1

  8. 还有一个原因：如果目标主机的指纹与您的不匹配~/.ssh/known_hosts，SSH 会自动禁用代理转发。

    解决办法是：

    $ ssh -A -o UserKnownHostsFile=/dev/null  my-target-host
    • 1

  9. 每个 SSH 守护进程都必须有：

    AllowAgentForwarding yes

    • 1

  10. 如果您连接到运行byobu /tmux 的机器，似乎有时您需要在连接后在目标机器上创建一个新窗口（例如 Ctrl-B + C），ssh -A以便您可以使用 ssh 代理进行后续身份验证.

    • 0

相关问题