为什么我仍通过公共密钥身份验证通过ssh收到密码提示？

我正在使用在这里找到的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上收到密码提示。

我不确定下一步该怎么做。

确保对~/.ssh目录及其内容的权限正确。当我第一次设置ssh key auth时，我没有~/.ssh正确设置文件夹，它对我大吼大叫。

• 你的主目录~，你的~/.ssh目录和~/.ssh/authorized_keys远程计算机上的文件只能由你可写：rwx------和rwxr-xr-x都很好，但rwxrwx---没有good¹，即使你是你的小组中唯一的用户（如果你喜欢的数字模式：700或者755，没有775） 。
  如果~/.ssh或是authorized_keys符号链接，则检查标准路径（符号链接已展开）。
• 您的~/.ssh/authorized_keys文件（在远程计算机上）必须是可读的（至少400），但是如果您要向其添加更多密钥，则还必须是可写的（600）。
• 您的私钥文件（在本地计算机上）必须只能由您读写：rw-------，即600。
• 另外，如果SELinux设置为强制执行，则可能需要运行restorecon -R -v ~/.ssh（请参阅例如Ubuntu错误965663和Debian错误报告＃658675；这已在CentOS 6中进行了修补）。

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

如果您具有对服务器的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。）

您的主目录是否已加密？如果是这样，则在您的第一个ssh会话中，您将必须提供密码。到同一服务器的第二个ssh会话正在使用auth密钥。如果是这种情况，则可以将您移动authorized_keys到未加密的目录，然后更改中的路径~/.ssh/config。

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

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

这允许多个用户拥有此ssh访问权限，而不会影响权限。

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

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

只需尝试以下命令

1. ssh-keygen

   按Enter键直到出现提示

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

   （它将一次询问主机系统的密码）

3. ssh root@ip_address

   现在您应该可以不用任何密码登录

当遥控器上的主目录没有正确的权限时，我面临挑战。在我的情况下，用户将主目录更改为777，以便在团队中进行某些本地访问。机器无法再通过ssh密钥进行连接。我将许可更改为744，它再次开始工作。

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

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

restorecon -R -v /root/.ssh

我们遇到了同样的问题，并且按照答案中的步骤进行操作。但这仍然对我们不起作用。我们的问题是登录只能从一个客户端进行，而不能从另一个客户端进行（.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

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

• 对于ChallengeResponseAuthentication，PasswordAuthentication，UsePAM，从“是”到“否”

• 对于PubkeyAuthentication，从“否”到“是”

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

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

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

可能您只需要取消注释：

AuthorizedKeysFile .ssh / authorized_keys

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

service sshd reload

两条评论：这将覆盖原始文件。我只复制生成的公钥，然后执行以下操作：

cat your_public_key.pub >> .ssh/authorized_keys

这会将您要使用的密钥附加到先前存在的密钥列表中。另外，某些系统使用file authorized_keys2，因此以防万一，在authorized_keys和之间建立硬链接是一个好主意authorized_keys2。

我的解决方案是该帐户已被锁定。在/ var / log / secure中找到消息：不允许用户，因为帐户已锁定解决方案：为用户提供新密码。

我遇到了类似的问题，并使用调试模式执行了以下步骤。

/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

密钥认证开始工作。

在/ etc / selinux / config文件中，将SELINUX更改为无法执行，从而使无密码ssh成功工作。

之前，我能够以一种方式做到这一点。现在从两个方面都可以执行无密码的ssh。

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

chown -R root:root /root

而且有效。另一个便宜的解决方法是禁用StrictModes：StirctModes no。在sshd_config中。这至少会告诉您密钥交换和连接协议是否正确。然后，您可以搜索不良权限。

对我来说，该解决方案与Wojtek Rzepala的解决方案相反：我没有注意到我仍在使用authorized_keys2，但已弃用。我的ssh设置在某个时刻停止工作，大概是在服务器更新时。重命名.ssh/authorized_keys2为已.ssh/authorized_keys解决的问题。

天哪！

过去，我遇到了一些教程，描述了如何实现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的服务器，以保证RSAAuthentication，PubkeyAuthentication而且UsePAM选项没有被禁用，他们可以在默认情况下启用yes。
• 如果您在生成客户端密钥时输入了密码，则可以尝试ssh-agent＆ssh-add在会话中实现无密码的连接。
• 检查服务器/var/log/auth.log上的内容，以查找为什么根本跳过密钥身份验证的问题。

PuTTY连接到Ubuntu 16.04计算机时遇到了完全相同的问题。令人困惑的是，PuTTY的pscp程序可以使用相同的密钥正常工作（并且相同的密钥在PuTTY中可以工作以连接到另一台主机）。

感谢@UtahJarhead的宝贵意见，我检查了/var/log/auth.log文件并发现以下内容：

sshd[17278]: userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes [preauth]

事实证明，默认情况下，较新版本的OpenSSH不接受DSA密钥。从DSA切换到RSA密钥后，它可以正常工作。

另一个方法：这个问题讨论了如何配置SSH服务器以接受DSA密钥：https : //superuser.com/questions/1016989/ssh-dsa-keys-no-longer-work-for-password-less-authentication?lq = 1

这些步骤应该可以帮助您。我经常在许多64位Ubuntu 10.04计算机中使用此功能。

[ ! -f ~/.ssh/id_rsa.pub ] && ssh-keygen -t rsa;
ssh <username>@<remote_machine> 'mkdir -p ~/.ssh'
cat ~/.ssh/id_rsa.pub | ssh <username>@<remote_machine> 'cat >> ~/.ssh/authorized_keys'

您可以将其放入带有一些提示的脚本中，并以

script_name username remote_machine

我对ssh也有类似的问题。就我而言，问题是我安装了hadoop cloudera（从centos 6上的rpm开始），并且它创建了具有主目录的用户hdfs

/var/lib/hadoop-hdfs（非标准/home/hdfs）。

我在/ etc / passwd中更改/var/lib/hadoop-hdfs为/home/hdfs，将主目录移动到了新位置，现在我可以使用公共密钥身份验证进行连接了。

我只是遇到了同样的问题，对我来说，解决方案是设置UsePAM为no。看，即使PasswordAuthentication设置为no，您仍然会得到keyboard-interactive，由于某种原因，在我的情况下，我的本地ssh程序仍默认为该设置。

额外的背景知识可为处于相同情况的任何人提供帮助：我正在从一台运行Dropbear的主机连接到一台运行OpenSSH的主机。在远程计算机上同时设置PasswordAuthentication和时，如果输入，我将收到以下消息：UsePAMnossh user@server

ssh: Connection to user@server:22 exited: Disconnect received

向身份文件提供-i，一切都会按预期进行。

这里可能会有更多信息。

在检查了权限并尝试了此处列出的其他几种解决方案之后，我终于删除了服务器上的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

在服务器上：

$ 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

另一个选择是@Jagadish的答案的变体：stracessh守护程序。

它具有显着的优势，即我们无需停止sshd，如果出现问题，这可能导致完全锁定。

首先，我们找到主sshd进程的pid。在这里，我们可以通过执行看到它pstree -pa|less。

  |-sshd,633 -D  <-- THIS IS WHAT WE WANT!
  |   `-sshd,21973   
  |       `-sshd,21996    
  |           `-bash,22000
  |               `-screen,638 -r

知道pid是633之后，我们可以strace跟随它的子进程进行操作：

strace -p 633 -s 4096 -f -o sux

其结果将是一切这是什么sshd的，并且其子流程都做了，将与strace-ED到指定的文件sux在本地目录。

然后重现该问题。

它将包含大量的内核调用日志列表，这对我们来说大多是难以理解/不相关的，但并非无处不在。就我而言，重要的是：

6834  sendto(4, "<38>Jan 15 18:49:21 sshd[6834]: User cica not allowed because account is locked\0", 84, MSG_NOSIGNAL, NULL, 0) = 84

这意味着，sshd尝试记录消息“ 用户cica”不允许，因为帐户已锁定 -只能这样做，因为日志记录不够冗长。但是我们已经知道，由于该帐户已被锁定，因此公钥被拒绝。

这还不是解决方案-现在我们需要使用google，对于sshd来说，这意味着“锁定帐户”。这将是最有可能的一些琐碎的/etc/passwd，/etc/shadow巫术，但重要的是做-问题是不是一个神秘，而是一种可调试/ googlable之一。

就我而言，我拥有所有权限，即使使用-vvv标志运行ssh时，我也不知道是什么问题。

所以我在远程主机上生成了新证书

ssh-keygen -t rsa -C "your_email@example.com"

并将生成的密钥复制到本地计算机，并将新的公共密钥添加到远程主机上的〜/ .ssh / authorized_keys

cat id_rsa.pub >> authorized_keys

现在可以使用从远程主机连接生成的密钥。因此，如果其他解决方案失败，这是另一回事。

我的情况是backupbot，在创建主帐户后，我有一台创建用户的NAS服务器，该服务器能够登录以最初创建backupbot用户。摆弄sudo vim /etc/ssh/sshd_config并创建backupbot用户后，vim至少可以在Ubuntu 16.04上并根据您的~/.vimrc配置，创建在vim会话中编辑留下的交换文件/etc/ssh/sshd_config。

检查是否/etc/ssh/.sshd_config.swp存在：是否存在，是否将其删除并重新启动sshd守护程序：

$ sudo rm /etc/ssh/.sshd_config.swp
$ sudo service sshd restart

这神奇地解决了我的问题。以前，我已经检查了我所有的权限，甚至检查了公钥和私钥的RSA指纹。这很奇怪，可能是带有的错误sshd，特别是此版本：

OpenSSH_7.4p1 Ubuntu-10，OpenSSL 1.0.2g 2016年3月1日