SSH 公钥登录失败,无模式

SSH 公钥登录失败,无模式

(之前错误地发布在 stackoverflow 上)

我运行了一堆装有 Ubuntu 14.04.1 的服务器(sun、hyperion 等),所有这些服务器都使用公钥(所有机器上都是 OpenSSH_6.6.1、OpenSSL 1.0.1f 6 Jan 2014)进行 rsync,没有任何问题。几乎所有...

一个连接失败,配置或密钥没有任何变化。然后我会尝试重新添加密钥,检查 ECDSA,重新启动/重启 ssh,它又可以正常工作了。或者不行。在这种情况下,我只需等待一段随机的时间(1 小时到 3 个月)然后做同样的事情。这一次它解决了问题——暂时的。

ssh -vvv diff 的相关部分:

连接成功

debug1: Host 'hyperion.internal' is known and matches the ECDSA host key.
debug1: Found key in /home/bar/.ssh/known_hosts:20
debug1: ssh_ecdsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/bar/.ssh/id_rsa (0x7f..),
debug2: key: /home/bar/.ssh/id_dsa ((nil)),
debug2: key: /home/bar/.ssh/id_ecdsa ((nil)),
debug2: key: /home/bar/.ssh/id_ed25519 ((nil)),
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/bar/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp 95:...
debug3: sign_and_send_pubkey: RSA 95:...
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to hyperion.internal ([172.16.0.10]:22).

连接失败

debug1: Host 'hyperion.internal' is known and matches the ECDSA host key.
debug1: Found key in /home/bar/.ssh/known_hosts:20
debug1: ssh_ecdsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/bar/.ssh/id_rsa (0x7f..),
debug2: key: /home/bar/.ssh/id_dsa ((nil)),
debug2: key: /home/bar/.ssh/id_ecdsa ((nil)),
debug2: key: /home/bar/.ssh/id_ed25519 ((nil)),
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/bar/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/bar/.ssh/id_dsa
debug3: no such identity: /home/bar/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/bar/.ssh/id_ecdsa
debug3: no such identity: /home/bar/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /home/bar/.ssh/id_ed25519
debug3: no such identity: /home/bar/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password

我已检查过多次的事情:

  • 所有机器上 .ssh/ 和 id_rsa 的权限
  • 我使用的是正确的按键
  • 将正确的密钥复制到正确的 authorized_hosts 文件ssh-copy-id -i /home/bar/.ssh/id_rsa [email protected]

以下方法并没有什么帮助,但增加了 vodoo/heisenbug 的效果:

  • 重启机器
  • 重新启动 ssh 服务
  • 摆弄全局 ssh 选项

我已将完整日志和一些删节过的信息粘贴至 pastebin:原木墙

答案1

问题已解决,它根本与 ssh 无关:

hyperion.internal 有一个加密的 home,因此当它未安装到 时,密钥查找会失败/home/europe

事后看来很明显,但是它解释了在观察机器上的日志时不会失败的海森堡效应(当然,是在登录时……)

希望这至少能对其他人有所帮助。

答案2

debug1: Offering RSA public key: /home/bar/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password

这表明服务器不接受您的私钥。遗憾的是,服务器没有向客户端提供有关其不接受密钥的原因的更多详细信息,因此您确实需要在服务器上排除故障。

/var/log我将首先检查服务器上的系统日志,查找任何表明sshd为何拒绝身份验证尝试的消息。

如果您在远程服务器上具有 root 访问权限,则可以运行 的调试实例sshd,然后使用客户端连接到它。在远程服务器上,成为 root 并运行/path/to/sshd -d -p 2222。这将启动 sshd 的实例,该实例侦听端口 2222。它将接受一个连接,并将调试信息打印到您的终端。

然后,在客户端上ssh正常运行,但包括-p 2222连接到正确的端口。如果登录失败,请检查服务器打印的调试输出。

答案3

对我来说,这也是涉及主目录的权限问题。目标服务器上主目录的权限设置为 775。据我发现,主目录权限必须设置为 755 或更低。这将设置为除主目录所有者之外的任何用户都不允许具有写权限。

答案4

将 root 创建的文件(不仅仅是 chmod)改回原始用户帐户。您还可以尝试使用 Userify 进行测试,看看它是否有效,以及您是否拥有没有错误的公钥。

相关内容