☰

尝试登录另一台电脑时 ssh 仍要求输入密码

tag-icon • tag-icon linux ssh
尝试登录另一台电脑时 ssh 仍要求输入密码

我最近用几台运行 Linux Ubuntu 12.04 LTS 的旧电脑构建了一个小型的 Beowulf 集群，并一直遵循此页面上的说明：

http://byobu.info/article/Building_a_simple_Beowulf_cluster_with_Ubuntu/

到目前为止，nfs 和 ping 其他节点都进展顺利，但现在没有密码，我无法让 ssh 工作。我花了很多时间阅读其他有类似问题的人的页面，但对他们有帮助的东西似乎都对我没用（更改为 600 模式，编辑 sshd_configure 文件等）。

最终我只是继续执行其余步骤，希望我可能只需要在执行任务时输入密码，并且如果只有一台计算机运行该任务，这确实有效（因为它要求输入 mpiuser@node1 的密码，我只需输入即可）但是，当我尝试在多个节点上运行该任务（该文档后面提到的用于测试集群的 cpi 程序）时，它（毫不奇怪）要求输入两个节点的密码，这是相同的，我输入了密码，但它就冻结了，我认为这与它的询问方式有关（它只是列出它们：mpiuser@node1 的密码： mpiuser@node2 的密码： mpiuser@node3 的密码：等等。

我甚至尝试过卸载并重新安装 ssh，但什么也没发生，ssh-keygen 命令似乎工作正常（它说出了其他人所说的一切），但之后它什么也没做。我能够使用密码让 ssh 工作，因为我发现 ssh 的默认密码是 root 密码，所以我只是更改了它，但除此之外 ssh-keygen 命令似乎什么也没做。

有任何想法吗？

- 编辑 -

打字时

"ssh -v mpiuser@node1" it says:

      master@master:~$ su mpiuser

      **Password:** 

      mpiuser@master:/home/master$ cd

      mpiuser@master:~$ ssh -v mpiuser@node1

    OpenSSH_5.9p1 Debian-5ubuntu1.1, 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 node1 [192.168.0.201] port 22.

    debug1: Connection established.

    debug1: identity file /home/mpiuser/.ssh/id_rsa type 1

    debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048

    debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048

    debug1: identity file /home/mpiuser/.ssh/id_rsa-cert type -1

    debug1: identity file /home/mpiuser/.ssh/id_dsa type -1

    debug1: identity file /home/mpiuser/.ssh/id_dsa-cert type -1

    debug1: identity file /home/mpiuser/.ssh/id_ecdsa type -1

    debug1: identity file /home/mpiuser/.ssh/id_ecdsa-cert type -1

    debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.1

    debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.1 pat OpenSSH*

    debug1: Enabling compatibility mode for protocol 2.0

    debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.1

    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 54:0e:8b:52:4d:41:08:fe:0b:bc:95:e5:93:42:59:40

    debug1: Host 'node1' is known and matches the ECDSA host key.

    debug1: Found key in /home/mpiuser/.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: Offering RSA public key: /home/mpiuser/.ssh/id_rsa

    debug1: Authentications that can continue: publickey,password

    debug1: Trying private key: /home/mpiuser/.ssh/id_dsa

    debug1: Trying private key: /home/mpiuser/.ssh/id_ecdsa

    debug1: Next authentication method: password

    mpiuser@node1's password:

答案1

嗯，这些行：

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/mpiuser/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/mpiuser/.ssh/id_dsa
debug1: Trying private key: /home/mpiuser/.ssh/id_ecdsa
debug1: Next authentication method: password

告诉您服务器允许基于公钥和密码的登录，因此客户端提供 3 个公钥（id_rsa、id_dsa 和 id_ecdsa），而服务器拒绝所有这三个，因此它回退到密码认证。

如果您希望其中一个密钥能够工作，那么您需要查看服务器并了解拒绝它们的原因。查看authorized_keys服务器上的文件，确保它具有与客户端上的私钥相对应的正确公钥，并确保它具有正确的权限 - 必须由您以该身份登录的用户（mpiuser？）拥有，并且其他任何人都无法写入。

答案2

使用 ssh-copy-id 命令将公钥复制到目标服务器。删除该服务器中的 .ssh 目录。这似乎是密钥或 .ssh 目录的权限问题。让 ssh-copy-id 为您完成任务，这样就可以了。

您可以看看该命令，这是一个简单的脚本。

答案3

我终于搞明白了！原来 ssh 对整个“/home/mpiuser”文件夹存在权限问题，因此无法在任何节点上使用。我刚刚在“sshd_config”文件中将“StrictModes”编辑为“no”，现在一切正常。

感谢大家的帮助！

答案4

我遇到了与用户相同的问题。问题确实是由权限设置引起的。之前我的整个 '/home/xxx' 文件夹权限是 drwxrwxrwx (777)。之后我立即将权限更改为 drwx------ (700)。成功了！注意：假设您将公钥附加到 authorized_keys 并且“sshd_config”文件正确。

如果您有任何问题，请告诉我。:)

相关内容