为什么我仍然收到带有公钥身份验证的 ssh 的密码提示？

Question

我正在使用我在这里找到的 URL：

http://web.archive.org/web/20160404025901/http://jaybyjayfresh.com/2009/02/04/logging-in-without-a-password-certificates-ssh/

我的 ssh 客户端是 Ubuntu 64 位 11.10 桌面，我的服务器是 Centos 6.2 64 位。我已按照指示进行操作。我仍然在 ssh 上收到密码提示。

我不知道接下来要做什么。

Answer 1

确保~/.ssh目录及其内容的权限正确。当我第一次设置我的 ssh 密钥身份验证时，我没有~/.ssh正确设置文件夹，它对我大喊大叫。

• 您的主目录~、您的~/.ssh目录和~/.ssh/authorized_keys远程机器上的文件必须只能由您写入：rwx------并且rwxr-xr-x很好，但rwxrwx---不好¹，即使您是组中唯一的用户（如果您更喜欢数字模式：700或755，不是775） .
  如果~/.ssh或authorized_keys是符号链接，则检查规范路径（扩展符号链接）。
• 您的~/.ssh/authorized_keys文件（在远程机器上）必须是可读的（至少 400），但如果您要向其中添加更多密钥，则需要它也是可写的（600）。
• 您的私钥文件（在本地机器上）必须只能由您读写：rw-------，即600.
• 此外，如果 SELinux 设置为 enforcing，您可能需要运行restorecon -R -v ~/.ssh（参见例如Ubuntu 错误 965663和Debian 错误报告 #658675；这已在 CentOS 6 中修补）。

¹_{某些发行版（Debian 和衍生版）除外，如果您是组中的唯一用户，它们已修补代码以允许组可写。}

Answer 2

如果您对服务器具有 root 访问权限，那么解决此类问题的简单方法是在调试模式下运行 sshd，方法是/usr/sbin/sshd -d -p 2222在服务器上发出类似命令（需要 sshd 可执行文件的完整路径，which sshd可以提供帮助），然后使用ssh -p 2222 user@host. 这将强制 SSH 守护进程留在前台并显示有关每个连接的调试信息。寻找类似的东西

debug1: trying public key file /path/to/home/.ssh/authorized_keys
...
Authentication refused: bad ownership or modes for directory /path/to/home/

如果无法使用替代端口，您可以暂时停止 SSH 守护程序并在调试模式下将其替换为一个。停止 SSH 守护进程不会终止现有连接，因此可以通过远程终端执行此操作，但有些风险 - 如果在调试替换未运行时连接确实以某种方式中断，您将被锁定在机器之外直到您可以重新启动它。所需的命令：

service ssh stop
/usr/sbin/sshd -d
#...debug output...
service ssh start

（根据您的 Linux 发行版，第一行/最后一行可能是systemctl stop sshd.service/systemctl start sshd.service代替。）

Answer 3

你的家目录加密了吗？如果是这样，对于您的第一个 ssh 会话，您将必须提供密码。到同一台服务器的第二个 ssh 会话正在使用 auth 密钥。如果是这种情况，您可以将您authorized_keys的目录移动到未加密的目录并更改~/.ssh/config.

我最终做的是创建一个/etc/ssh/username文件夹，由用户名拥有，具有正确的权限，并将authorized_keys文件放在那里。然后将 AuthorizedKeysFile 指令更改/etc/ssh/config为：

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

这允许多个用户在不影响权限的情况下拥有此 ssh 访问权限。

Answer 4

只需尝试以下这些命令

1. ssh-keygen

   按 Enter 键直到出现提示

2. ssh-copy-id -i root@ip_address

   （它会询问主机系统的密码）

3. ssh root@ip_address

   现在您应该无需任何密码即可登录

Answer 5

将密钥复制到远程机器并将它们放入其中后，authorized_keys您必须执行以下操作：

ssh-agent bash
ssh-add ~/.ssh/id_dsa or id_rsa

Answer 6

当远程主目录没有正确的权限时，我遇到了挑战。在我的情况下，用户将主目录更改为777，以便在团队中进行一些本地访问。机器无法再使用 ssh 密钥连接。我将权限更改为744，然后它又开始工作了。

Answer 7

我们遇到了同样的问题，我们按照答案中的步骤操作。但它仍然对我们不起作用。我们的问题是登录可以从一个客户端运行，但不能从另一个客户端登录（.ssh 目录是 NFS 挂载的，并且两个客户端都使用相同的密钥）。

所以我们不得不更进一步。通过以详细模式运行 ssh 命令，您可以获得大量信息。

ssh -vv user@host

我们发现默认密钥 (id_rsa) 未被接受，而是 ssh 客户端提供了一个与客户端主机名匹配的密钥：

debug1: Offering public key: /home/user/.ssh/id_rsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: /home/user/.ssh/id_dsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: user@myclient                                          
debug2: we sent a publickey packet, wait for reply                                        
debug1: Server accepts key: pkalg ssh-rsa blen 277                  

显然，这不适用于任何其他客户端。

因此，我们的解决方案是将默认的 rsa 密钥切换到包含 user@myclient 的密钥。当密钥为默认值时，不会检查客户端名称。

然后我们遇到了另一个问题，在切换之后。显然，密钥缓存在本地 ssh 代理中，我们在调试日志中收到以下错误：

'Agent admitted failure to sign using the key'

这是通过将密钥重新加载到 ssh 代理来解决的：

ssh-add

Answer 8

RedHat/CentOS 6上的SELinux存在公钥身份验证问题，可能是在创建某些文件时 selinux 未正确设置其 ACL。

要为 root 用户手动修复 SElinux ACL：

restorecon -R -v /root/.ssh

Answer 9

这将是服务器端的 SSH 未命中配置。必须编辑服务器端 sshd_config 文件。位于/etc/ssh/sshd_config。在该文件中，更改变量

• ChallengeResponseAuthentication、PasswordAuthentication、UsePAM 的“是”到“否”

• PubkeyAuthentication 的“否”到“是”

基于http://kaotickreation.com/2008/05/21/disable-ssh-password-authentication-for- added-security/

Answer 10

过去，我遇到过一些描述如何实现 ssh 无密码设置的教程，但有些教程是错误的。
让我们重新开始，检查每一步：

1. 来自客户端- 生成密钥：ssh-keygen -t rsa
   公钥和私钥（id_rsa.pub和id_rsa）将自动存储在~/.ssh/目录中。
   如果您使用空密码，设置会更容易。如果您不愿意这样做，那么仍然遵循本指南，但还要检查下面的要点。
   
   
2. 从客户端- 将公钥复制到服务器：ssh-copy-id user@server
   客户端公钥将被复制到服务器的位置 ~/.ssh/authorized_keys。
   
   
3. 从客户端- 连接到服务器：ssh user@server
   
   

现在，如果在执行上述 3 个步骤后仍然无法正常工作，请尝试以下操作：

• 检查客户端和服务器~/.ssh计算机中的文件夹权限。
• 检查/etc/ssh/sshd_config服务器以确保和选项未被禁用，默认情况下可以使用启用它们。RSAAuthenticationPubkeyAuthenticationUsePAMyes
• 如果您在生成客户端密钥时输入了密码，那么您可以尝试ssh-agent在ssh-add会话中实现无密码连接。
• 检查服务器/var/log/auth.log上的内容以查找根本跳过密钥身份验证的问题。

Answer 11

确保AuthorizedKeysFile指向正确的位置，用作用%u户名的占位符：

# /etc/ssh/sshd_config
AuthorizedKeysFile /home/%u/authorized_keys

可能您只需要取消注释该行：

AuthorizedKeysFile .ssh/authorized_keys

请注意，您必须重新加载 ssh 服务才能进行更改：

service sshd reload

Answer 12

我错误的一件事是服务器系统上我的主目录的所有权。服务器系统设置为默认：默认，所以我：

chown -R root:root /root

它奏效了。另一个廉价的解决方法是禁用 StrictModes：StirctModes no。在 sshd_config.php 中 这至少会告诉您密钥交换和连接协议是否良好。然后你就可以去寻找坏权限了。

Answer 13

我遇到了类似的问题，并使用调试模式按照步骤操作。

/usr/sbin/sshd -d

这显示了以下结果

debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
Authentication refused: bad ownership or modes for directory /root
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys2
debug1: Could not open authorized keys '/root/.ssh/authorized_keys2': No such file or directory
debug1: restore_uid: 0/0
Failed publickey for root from 135.250.24.32 port 54553 ssh2
debug1: userauth-request for user root service ssh-connection method gssapi-with-mic

真的很困惑

[root@sys-135 ~]# ls -l /
drwxrwxrwx.   2 root root     4096 Dec 14 20:05 bin
drwxrwxrwx.   5 root root     1024 May  6  2014 boot
drwxrwxrwx.   2 root root     4096 Dec  2  2013 cgroup
drwxrwxrwx.  10 root root     1024 Sep 25 23:46 data
drwxrwxrwx. 124 root root    12288 Dec 16 10:26 etc
drwxrwxrwx.  11 root root     4096 Jan 14  2014 lib
drwxrwxrwx.   9 root root    12288 Dec 14 20:05 lib64
drwxrwxrwx.   2 root root    16384 Jan 10  2014 lost+found
drwxrwxrwx.   2 root root     4096 Jun 28  2011 media
drwxr-xr-x.   2 root root        0 Dec 10 14:35 misc
drwxrwxrwx.   2 root root     4096 Jun 28  2011 mnt
drwxrwxrwx.   4 root root     4096 Nov 24 23:13 opt
dr-xr-xr-x. 580 root root        0 Dec 10 14:35 proc
drwxrwxrwx.  45 root root     4096 Dec 16 10:26 root

它显示根目录对每个人都有权限。我们更改了它，以便其他人没有权限。

[root@sys-135 ~]# chmod 750 /root

密钥认证开始工作。

Answer 14

检查权限并尝试此处列出的其他几种解决方案后，我最终删除了服务器上的 ssh 目录，然后再次设置我的公钥。

服务器命令：

rm -rf ~/.ssh

本地命令：

ssh-copy-id user@192.168.1.1        # where <user> is your username and <192.168.1.1> is the server IP

Answer 15

在 /etc/selinux/config 文件中，将 SELINUX 更改为禁用，使无密码 ssh 成功工作。

早些时候我可以用一种方式做到这一点。现在，我可以通过这两种方式进行无密码 ssh。

Answer 16

在服务器上：

$ ls -lh /home
$ sudo chmod 700 /home/$USER

它是directory permission issue。服务器上的号码是 777，所以I changed it back to 700. 即使复制到服务器后，这fixed也是我的问题。ssh password less login failure$USER/.ssh/id_rsa.pub$USER/.ssh/authorized_keys

Answer 17

如果服务器接受私钥和用户名/密码身份验证方法，那么如果私钥失败，它将简单地退回到提示输入用户名/密码而不显示任何错误。

您可以使用该-vvv标志来确定是否尝试了私钥（以及具体是哪些密钥）以及密钥失败的原因。例子：ssh -T -vvv myHost.com。或者，您可以LogLevel DEBUG3在 中使用~/.ssh/config。

常见的故障是服务器拒绝密钥。在这种情况下，你会看到类似这样的内容：

debug1: Next authentication method: publickey
debug1: Trying private key: /c/Users/myUsername/.ssh/id_rsa
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password
myUsername@myServer.com's password:

根据 SSH 协议的官方规范 (RFC 4252)，身份验证数据包具有以下值：

SSH_MSG_USERAUTH_REQUEST    50
SSH_MSG_USERAUTH_FAILURE    51
SSH_MSG_USERAUTH_SUCCESS    52

这意味着debug3: receive packet: type 51服务器拒绝了该密钥。