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上看到密码提示。
我不确定下一步该怎么做。
#1 楼
确保对~/.ssh目录及其内容的许可权是正确的。当我第一次设置ssh key auth时，没有正确设置~/.ssh文件夹，它对我大吼大叫。您的主目录
~，您的~/.ssh目录和远程计算机上的~/.ssh/authorized_keys文件只能由您自己写：rwx------和rwxr-xr-x很好，但是rwxrwx---不好，即使您是组中的唯一用户（如果您更喜欢数字模式：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和衍生产品）上的补丁已对代码进行了修补以允许组可写性（如果您是组中唯一的用户）除外。
评论
非常感谢您指出restorecon。我已经在这个问题上抓了一段时间了。
–理查德·巴雷尔（Richard Barrell）
2012年12月3日14:56
奇怪的是，我的一个朋友在他的VPS上设置了一个帐户，但该服务器上的pubkey auth无法正常工作。我以为所有权限都是正确的，但请记住/ home / USER必须为700或755，这一点很重要
–抢夺
2013年1月25日19:22
还要记住检查所有者和组设置，我使用RSYNC复制了authorized_keys文件，却没有注意到所有者/组设置为1000而不是root！
– nak
13年2月16日在17:23
另外，在您的ssh命令中添加-v以查看该键的操作。 ssh -v user @ host。
–tedder42
2014-2-17在19:38
chmod -R 700〜/ .ssh为我工作，以满足该答案的限制（RHEL 7）
–scottysseus
15年11月16日在20:33
#2 楼
如果您具有对服务器的root访问权，则解决此类问题的简单方法是在服务器端发出/usr/sbin/sshd -d -p 2222之类的内容（需要sshd可执行文件的完整路径，which sshd可以提供帮助），然后在调试模式下运行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。）评论
我刚刚尝试过...并且在运行sshd -d时运行良好，但是一旦我实际运行service sshd start就会失败。我敢肯定这很简单，但是我不是Linux专家。有什么想法吗？
– N Rohler
2012年11月30日下午5:18
作为参考，本文介绍了解决我的问题的SELinux解决方案。
– N Rohler
2012年11月30日5:36
我在使公钥身份验证正常工作方面也遇到了麻烦，我很确定目录权限不是问题。在调试模式下运行SSH之后，我很快发现我错了，而权限是问题所在。
– ub3rst4r
2014年5月14日下午5:36
很好的建议，我的用户文件夹权限错误。
– gdfbarbosa
2014-12-18 10:23
谢谢。出于所有原因，我的用户被禁止登录，因为在用户创建时ansible（/ bin / zsh）指定的shell不存在。我永远都不会猜到。
–chishaku
15-10-27在0:56
#3 楼
您的家庭目录是否已加密？如果是这样，则在您的第一个ssh会话中，您将必须提供密码。到同一服务器的第二个ssh会话正在使用auth密钥。在这种情况下，您可以将authorized_keys移至未加密的目录并更改~/.ssh/config中的路径。我最终要做的是创建一个
/etc/ssh/username文件夹，该文件夹由用户名拥有，并具有正确的权限，并将authorized_keys文件放在其中。然后将/etc/ssh/config中的AuthorizedKeysFile伪指令更改为：AuthorizedKeysFile /etc/ssh/%u/authorized_keys
，这允许多个用户具有此ssh访问权限而不会损害权限。
评论
其中的ubuntu文件：help.ubuntu.com/community/SSH/OpenSSH/Keys#Troubleshooting
– FabV。
2014年3月12日在7:32
这个答案很明显，对任何想知道这是否是问题的人来说，它都对我有所帮助-您可能会在auth.log中看到“ pam_ecryptfs：密码文件包装”；以某种方式不足以提示我记住homedir已加密。另外，您可能会发现第一次登录要求输入密码，随后的会话则不需要（因为在其他会话打开时它已被解密）。
–和平主义者
2014年6月20日在8:21
我已经搜索wayyyy太久了，无法解决该问题，请耐心等待！
– h3。
15年2月13日在17:33
错误...不要给出不正确或错误的建议。不好您为什么讨厌寻求帮助的人？ kali @ kali2：〜/ .ssh $ ssh -oKexAlgorithms = + diffie-hellman-group1-sha1 root@10.11.1.136 /home/kali/.ssh/config：第4行：错误的配置选项：authorizedkeysfile / home / kali /。 ssh / config：终止，1个错误的配置选项
– Zack A
7月11日在16:23
#4 楼
只需尝试以下命令ssh-keygen 按Enter键，直到出现提示
ssh-copy-id -i root@ip_address （它将一次询问主机系统的密码）
ssh root@ip_address 现在您应该可以登录没有任何密码
评论
在哪个服务器上？
–阿马尔戈维努斯
2014年6月17日19:47
@Amalgovinus显然，您在客户端而不是您要连接的计算机上运行此命令-您不希望在服务器上复制私钥！ :)
–nevelis
2014年9月24日16:09
请注意，通常不建议允许远程root用户登录。
–arielf
15年6月22日在18:21
#5 楼
将密钥复制到远程计算机并将其放入authorized_keys后，您必须执行以下操作：ssh-agent bash
ssh-add ~/.ssh/id_dsa or id_rsa
评论
其实不，你不知道。 ssh会自动使用〜/ .ssh / id_rsa（或id_dsa），而不必使用密钥代理。
–干粉
13年7月7日在1:29
如果要在〜/ .ssh / config中指定其他名称的键（例如，在主机* .mydomain.org ... IdentityFile〜/ .ssh / some_limited_use.pub上-ssh-add〜/），这仍然可能是有用的建议。 .ssh / some_limited_use.pub）。
– 89c3b1b8-b1ae-11e6-b842-48d705
14年2月3日，12：11
这解决了我添加密钥后提示输入密码的问题。正如89c3b1b8-b1ae-11e6-b842-48d705所指出的那样，手动运行这些命令的原因是密钥文件的非标准名称。
– Mikhail Lisakov
18-09-18在11:40
如上面注释中所指出的，如果您使用的是默认密钥以外的任何密钥，则默认情况下不会将其添加到ssh代理中。因此，请确保检查要使用的密钥在代理的钥匙串中：ssh-add -L
–詹姆斯
19 Mar 11 '19 at 17:58
我不得不做ssh-add〜/ .ssh / id_rsa非常感谢！
–腮红
4月13日晚上11:59
#6 楼
当遥控器上的主目录没有正确的权限时，我面临挑战。在我的情况下，用户将主目录更改为777，以便在团队中进行某些本地访问。机器无法再通过ssh密钥进行连接。我将许可更改为744，它再次开始工作。评论
我们也遇到了这个问题-755在家庭Dirs上解决了它
– davidfrancis
2012年7月18日在14:52
我的权限设置为777，它被忽略了，谢谢！！！
– ka_lin
16年7月4日在13:56
同样在这里。谢谢。 wtf正在挠我的头一段时间。
–马辛
18-10-27在6:40
是的，请参阅此处的答案以获取更多详细信息unix.stackexchange.com/questions/205842/…
– Tim
19年2月19日，下午3:53
对于正确完成密钥生成但仍提示输入密码的人来说，这可能是答案。
– Fergie
19年2月21日在12:37
#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
#8 楼
RedHat / CentOS 6上的SELinux具有pubkey身份验证问题，可能是在创建某些文件时selinux无法正确设置其ACL。要为根用户手动修复SElinux ACL：
restorecon -R -v /root/.ssh
评论
在Windows上使用openssh客户端，我可以将root @ mymachine毫无问题地转换为CentOS6 mymachine，但是我有一个优先使用的特权较低的用户，但是ssh normalUser @ mymachine仍然提示我输入密码。有什么想法吗？
–Groostav
18-11-11在10:06
#9 楼
这将是服务器端的SSH Miss配置。服务器端sshd_config文件必须进行编辑。位于/etc/ssh/sshd_config中。在该文件中，将ChallengeResponseAuthentication，PasswordAuthentication和UsePAM的变量
'yes'更改为'no'，将'no'更改为'yes'用于PubkeyAuthentication
基于http://kaotickreation.com/2008/05/21/disable-ssh-password-authentication-for-add-security/
评论
如对问题的评论中所述，检查/ var / log / secure或/var/log/auth.log。在我的情况下，我看到“由于XXX中未列出用户xxx而导致的用户xxx”，“ input_userauth_request：无效的用户xxx [preauth]”（和/ var / log / messages中的“ rexec第35行：不建议使用的选项ServerKeyBits”，尽管我不知道是什么）那是）。要解决vi / etc / ssh / sshd_config，请将用户xxx添加到AllowUsers列表中，请重新启动服务sshd ***请注意，如果sshd_config不正确，则重新启动sshd服务可能会使您无法使用！ ***。那行得通。
–gaoithe
19年1月3日，12：30
#10 楼
确保AuthorizedKeysFile指向正确的位置，将%u用作用户名的占位符：# /etc/ssh/sshd_config
AuthorizedKeysFile /home/%u/authorized_keys
可能只需要取消注释该行：
AuthorizedKeysFile .ssh / authorized_keys
请记住，必须重新加载ssh服务才能进行更改：
service sshd reload
#11 楼
两条评论：这将覆盖原始文件。我只复制生成的公钥，然后执行以下操作：此外，某些系统使用文件authorized_keys2，因此，以防万一，在authorized_keys和authorized_keys2之间建立硬链接是一个好主意。评论
是的，我也注意到有关覆盖的问题，但是我没有任何覆盖，所以没关系。我创建了一个指向authorized_keys2的符号链接，但这没有帮助。
–汤姆
2012年4月16日14:46
另外，检查文件/目录权限。它们在您提供的网站上有描述。
– Wojtek
2012年4月16日的15:00
您的〜/ .ssh目录必须为700您的私钥文件必须为600您的公钥文件必须为644您的身份验证文件（在远程上）必须为644
–抢夺
2012年4月16日15:03
@Rob就是问题所在。如果您将其发布为答案，我会接受。
–汤姆
2012年4月17日在9:08
#12 楼
我的解决方案是该帐户已被锁定。 >评论
我通过更改/ etc / shadow中该用户的密码字段来解决它！至 *。此后，仍然无法进行密码验证，但是用户不再被锁定。
–user3132194
16年4月7日在11:53
#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
密钥验证开始工作。
评论
我有同样的问题。昨天，我发出了rsync -av ./root/ root @ THE_HOST：/ root从本地工作目录上载一些文件，然后发生了这个问题（实际上，起初我没有注意到它。主机在第二天早上发生故障，我开始挖掘原因）。 rsync -av ./root/ root @ THE_HOST：/ root命令更改了远程主机/ root目录的所有者和权限。修复了权限问题已解决。
– LiuYan刘研
2015年6月13日在3:41
来自135.250.24.32端口54553 ssh2的root的公共密钥失败，当我忘记将公钥添加到主机authorized_keys时，我得到了相同的消息和问题。在我的情况下添加此注释，通常在检查调试和所有权限以及配置文件＃：o <之后，我才意识到自己的错误。
–tuk0z
16-09-17在21:48
#14 楼
在检查了权限并尝试了此处列出的其他几种解决方案之后，我最终只是删除了服务器上的ssh目录，然后再次设置了我的公钥。服务器命令：
rm -rf ~/.ssh
评论
正是我所做的（检查完以上所有内容之后！），但在主机上进行了本地化，然后它开始工作。不幸的是，我永远不会知道为什么没有。谢谢。
– Pozinux
1月9日22:25
调试和理解总是好的，但是当您现在需要一切正常工作时，就是这样。
–不露面
8月9日18:47
#15 楼
在/ etc / selinux / config文件中，将SELINUX更改为无法执行，从而使无密码ssh成功工作。更早的时候，我可以用一种方法来实现。现在从两个方面都可以执行无密码的ssh。
#16 楼
我做错的一件事是服务器系统主目录上的所有权。服务器系统设置为default：default，所以我：chown -R root:root /root
并且可以正常工作。另一个便宜的解决方法是禁用StrictModes：StirctModes no。在sshd_config中。这至少会告诉您密钥交换和连接协议是否正确。然后您就可以查找不良权限。
评论
我也是。查看/ var / log / secure中的消息。我看到一条消息：“身份验证被拒绝：所有权或目录模式错误”（$ HOME）。确保没有对$ HOME的“组”或“其他”写权限。如果没有对服务器的未经授权的root访问权限，我将永远找不到。
– SoloPilot
18年5月6日15:43
#17 楼
过去，我遇到过一些教程，描述了如何实现ssh的无密码设置，但是有些错误是令人遗憾的。让我们重新开始，检查每一步：从客户端-生成密钥：ssh-keygen -t rsa公钥和私钥（id_rsa.pub和id_rsa）将自动存储在~/.ssh/目录中如果使用空密码短语，则设置会更容易。如果您不愿意这样做，请仍然按照本指南进行操作，还请检查下面的要点。从客户端-将公用密钥复制到服务器：
ssh-copy-id user@server客户端公用密钥将是复制到服务器的位置~/.ssh/authorized_keys。从客户端-连接到服务器：
ssh user@server 现在，如果在描述的3个步骤后仍然无法工作，请尝试以下操作：
检查客户端和服务器计算机中的
~/ssh文件夹权限。检查服务器中的
/etc/ssh/sshd_config，以确保未禁用RSAAuthentication，PubkeyAuthentication和UsePAM选项，则默认情况下可以使用yes启用它们。如果在生成客户端密钥时输入了密码，则可以尝试使用
ssh-agent和ssh-add在会话中实现无密码连接。检查内容在服务器上进行
/var/log/auth.log，以查找为什么根本跳过密钥身份验证的问题。评论
感谢您列出步骤！我到达“ ssh-copy-id user @ server”，并意识到我最初是通过错误的公共密钥进行复制的。
–马塔瓦塔尔
19年4月15日在18:42
在第一个项目符号中，它应显示为“为客户端和服务器用户检查客户端和服务器上的〜/ .ssh文件夹权限”
– RichVel
19-10-24在5:20
#18 楼
对我而言，该解决方案与Wojtek Rzepala的解决方案相反：我没有注意到我仍在使用authorized_keys2，该产品已被弃用。我的ssh设置在某个时刻停止工作，大概是在服务器更新时。将.ssh/authorized_keys2重命名为.ssh/authorized_keys可以解决此问题。D'oh！
评论
这也是/ etc / ssh / sshd_config中的配置选项，尽管我认为我已经像您一样对其进行了重命名。
–里克·史密斯
2015年10月14日在21:17
#19 楼
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-password-less-authentication不再需要工作吗？lq = 1
#20 楼
在服务器上：$ 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的问题。评论
另请参阅daveperrett.com/articles/2010/09/14/ssh-authentication-refused
–卤化物
19年9月30日14:23在
#21 楼
这些步骤应该可以帮助您。我经常在许多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-copy-id，它会自动执行最后两个步骤。
– jofel
2012年4月17日下午13:05
@jofel请记住，在许多系统中ssh-copy-id不存在。 @Sriharsha在mkdir之后，您也应该在其中添加chmod 700 .ssh，顺便说一句，您不需要在〜/ .ssh里这么冗长，因为.ssh足够了，因为无论如何这些命令都是在主目录中执行的
– janos
2012年4月17日在18:09
#22 楼
我对ssh也有类似的问题。在我的情况下，问题是我安装了hadoop cloudera（从centos 6上的rpm）并创建了具有主目录/var/lib/hadoop-hdfs（非标准/home/hdfs）的用户hdfs。 我将/ etc / passwd
/var/lib/hadoop-hdfs更改为/home/hdfs，将主目录移动到了新位置，现在我可以使用公共密钥身份验证了。#23 楼
我只是遇到了同样的问题，对我来说，解决方法是将UsePAM设置为no。看，即使将PasswordAuthentication设置为no，您仍然会得到keyboard-interactive，在我的情况下，由于某种原因，我的本地ssh程序仍默认使用该设置。 ：我正在从一台运行Dropbear的主机连接到一台运行OpenSSH的主机。使用PasswordAuthentication和UsePAM都在远程计算机上设置no时，如果输入ssh user@server，我将收到以下消息：符合预期。这里可能会有更多信息。
#24 楼
还有一个选择是@Jagadish的答案的变体：ssh守护程序strace。具有显着的优势，我们不需要停止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及其子进程完成的所有操作都将被跟踪到本地目录中名为
sux的文件中。 />然后重现问题。它将有大量的内核调用日志列表，这对我们来说大多是难以理解/不相关的，但并非无处不在。就我而言，重要的是：
6834 sendto(4, "<38>Jan 15 18:49:21 sshd[6834]: User cica not allowed because account is lockedq4312078q", 84, MSG_NOSIGNAL, NULL, 0) = 84
这意味着sshd尝试记录用户cica消息是不允许的，因为帐户已锁定-仅不能，因为记录还不够详细。但是我们已经知道，由于该帐户已被锁定而拒绝了公钥。这很可能是一些琐碎的
/etc/passwd，/etc/shadow向导，但重要的事情已经完成了-问题不是一个神秘的问题，而是一个易于调试/可调试的问题。#25 楼
就我而言，我拥有所有权限，即使使用-vvv标志运行ssh时，我也无法弄清楚问题出在哪里。所以我在远程主机上生成了新证书
ssh-keygen -t rsa -C "your_email@example.com"
，并将生成的密钥复制到本地计算机，并将新的公共密钥添加到远程主机上的〜/ .ssh / authorized_keys中。
现在可以使用从远程主机连接生成的密钥。因此，如果其他解决方案失败，这是另一种尝试。
#26 楼
我的情况是，我有一个NAS服务器，在创建我的主帐户之后，我在该服务器上创建了backupbot用户，该用户能够登录以最初创建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日
#27 楼
如果服务器同时接受了私钥和用户名/密码身份验证方法，则如果私钥失败，它将仅退回到提示输入用户名/密码而不会显示任何错误。您可以使用
-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指示服务器拒绝了密钥。 #28 楼
在我的情况下，authorized_keys文件的所有权是错误的。用户是cz04。 />
评论
您使用-v标志提供给ssh的命令的输出？应该类似于pastebin.com/xxe57kxg还要确保您的.ssh文件夹是chmod 700
假设您具有对该服务器的root访问权限，则/var/log/auth.log将告诉您登录失败的原因。
@UtahJarhead：在CentOS服务器上，它可能位于/ var / log / secure中。
有趣的是，chmod 0700是答案，但是当我在客户端执行ssh -v时，它没有表明与为什么不接受密钥有关的错误，它只是说即使我的客户端发送了密码，它也在下一次尝试输入密码。公钥。他们如何期望我们在没有服务器错误信息的情况下诊断问题？