![ssh 在没有密码提示的情况下挂起——在 root 或其他账户下有效](https://linux22.com/image/491769/ssh%20%E5%9C%A8%E6%B2%A1%E6%9C%89%E5%AF%86%E7%A0%81%E6%8F%90%E7%A4%BA%E7%9A%84%E6%83%85%E5%86%B5%E4%B8%8B%E6%8C%82%E8%B5%B7%E2%80%94%E2%80%94%E5%9C%A8%20root%20%E6%88%96%E5%85%B6%E4%BB%96%E8%B4%A6%E6%88%B7%E4%B8%8B%E6%9C%89%E6%95%88.png)
我的基于 ssh 密钥的登录工作正常。然后,我更改了计算机上的主机名,基于密钥的登录停止工作。这似乎很有道理。密钥可能依赖于我的旧主机名。因此,我删除了所有密钥和 ~/.ssh/ 中的所有文件并重新生成它们(并更改了我连接的服务器上的 authorized_keys)
现在,无论我尝试 ssh 到哪里,它都会挂起,没有密码提示,即使我没有设置基于密钥的登录服务器也是如此。.ssh/config 中没有任何内容。
此外,当我使用“su -”切换到 root 时,ssh 运行正常。没有任何问题。这只发生在我的用户帐户上。
以下是来自 ssh 的一些调试信息
SSH-VV[电子邮件保护] OpenSSH_5.2p1,OpenSSL 0.9.8k 2009 年 3 月 25 日 debug1:读取配置数据/Users/myname/.ssh/config debug1:读取配置数据 /usr/etc/ssh_config ...... debug1:主机“myremoteserver.com”已知并且与 RSA 主机密钥匹配。 debug1:在 /Users/myname/.ssh/known_hosts:1 中找到密钥 debug2:位设置:512/1024 debug1: ssh_rsa_verify: 签名正确 调试2:kex_derive_keys debug2: set_newkeys: 模式 1 debug1: SSH2_MSG_NEWKEYS 已发送 debug1:期望 SSH2_MSG_NEWKEYS debug2:set_newkeys:模式 0 debug1: 已收到 SSH2_MSG_NEWKEYS debug1: SSH2_MSG_SERVICE_REQUEST 已发送 调试2:service_accept:ssh-userauth debug1: 已收到 SSH2_MSG_SERVICE_ACCEPT
然后它就挂在这里.....
以下是 dtruss(类似 strace,但适用于 OSX)挂起末端附近的输出:sudo dtruss ssh -vv[电子邮件保护]
选择(0x4,0x508200,0x0,0x0,0x0)= 1 0 读取(0x3,“$\222\351{L\363\261\25063sN\216\300@q7\203\276b\257\354\337\356\260!{\342\017\271=\222,\245\347t\006\225\257\333;\204\020]\242\005z#\0”,0x2000)= 48 0 写入(0x2,“debug2:service_accept:ssh-userauth \r\n\0”,0x26)= 38 0 连接(0x4,0xBFFFEEA2,0x6A)= 0 0 写入(0x4,“\0”,0x4)= 4 0 写入(0x4,“\v5\004\0”,0x1)= 1 0 读取(0x4,“\0”,0x4)= -1 错误#4
它似乎正在尝试读取某些内容,但只是挂在这里。如果有人能提供一些建议或想法,我将不胜感激!
答案1
您的 ssh 客户端挂起,而其他帐户(root)则不会挂起,这可能是因为您的 ssh-agent 出了问题。要么是ssh-agent
没有运行,要么是其配置存在某种错误。
为了确认这一点,您可以尝试以下操作:
unset SSH_AUTH_SOCK
ssh [email protected]
如果随后要求您输入 ssh_key 的密码,则意味着您的 ssh-agent 有问题。
另请参阅我的帖子这个相关问题。
答案2
您对反向 DNS 感兴趣吗?
本质上,客户端正在服务器上执行反向 DNS,反之亦然。
我建议进行一个测试:
通过编辑 /etc/ssh/sshd_config 并确保“UseDNS”设置为“no”来禁用服务器上的 DNS 查找。
运行“service ssh reload”(或任何导致您的 ssh 守护进程重新读取配置的操作),然后重试。
顺便说一下,它不会是经过很长一段时间后才终于提示你,是吗?
您可能还要检查服务器上 /etc/hosts 的内容,以确保没有任何问题。
答案3
检查 ~/.ssh 目录及其中的文件的权限。您的默认 umask 可能过于宽松,当您重新创建文件时,您可能无意中赋予了它们错误的权限。我自己也曾多次遇到这种情况。我使用的所有 ssh 客户端(或服务器)都没有给出关于此问题的有用错误消息...
答案4
我遇到了类似的问题。
ssh domain.ip:user.name
看来我可以通过强制使用这样的登录名来绕过这个问题。
ssh -v domain.ip -l user.name