SSH密钥身份验证失败

我正在尝试进入无法控制的CentOS服务器。管理员已将我的公钥添加到服务器，并坚持认为问题出在我身上，但我不知道出了什么问题。

在.ssh中配置：

tim@tim-UX31A:~$ cat ~/.ssh/config
User root
PasswordAuthentication no
IdentityFile ~/.ssh/id_rsa

我的密钥文件的权限：

tim@tim-UX31A:~$ ls -l ~/.ssh/id_rsa*
-rw------- 1 tim tim 3326 Okt 20 17:28 /home/tim/.ssh/id_rsa
-rw-r--r-- 1 tim tim  746 Okt 20 17:28 /home/tim/.ssh/id_rsa.pub

我无法理解的连接日志：

tim@tim-UX31A:~$ ssh -vvv root@10.0.12.28
OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /home/tim/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "10.0.12.28" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 10.0.12.28 [10.0.12.28] port 22.
debug1: Connection established.
debug1: identity file /home/tim/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/tim/.ssh/id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 10.0.12.28:22 as 'root'
debug3: hostkeys_foreach: reading file "/home/tim/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/tim/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys from 10.0.12.28
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: host key algorithms: ssh-rsa,ecdsa-sha2-nistp256
debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: MACs ctos: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: MACs stoc: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: 
debug3: hostkeys_foreach: reading file "/home/tim/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/tim/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys from 10.0.12.28
debug1: Host '10.0.12.28' is known and matches the ECDSA host key.
debug1: Found key in /home/tim/.ssh/known_hosts:3
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug2: key: /home/tim/.ssh/id_rsa (0x55ee619ab2b0), explicit, agent
debug2: key: /home/tim/.ssh/id_rsa (0x55ee619bcfa0), agent
debug2: key: tim@Tim-UX31A-Debian (0x55ee619b9370), agent
debug3: send packet: type 5
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive
debug3: authmethod_lookup gssapi-keyex
debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive
debug3: authmethod_is_enabled gssapi-keyex
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/tim/.ssh/id_rsa
debug3: send_pubkey_test
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,gssapi-keyex,gssapi-with-mic,password
debug1: Offering RSA public key: /home/tim/.ssh/id_rsa
debug3: send_pubkey_test
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,gssapi-keyex,gssapi-with-mic,password
debug1: Offering RSA public key: tim@Tim-UX31A-Debian
debug3: send_pubkey_test
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,gssapi-keyex,gssapi-with-mic,password
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

假设没有对权限进行其他更改，这通常可以解决服务器端大多数SSH授权的密钥权限问题。

sudo chown yourusername:yourusername /home/yourusername/ -R
sudo chmod o-rwx /home/yourusername/ -R

如果您的管理员以root用户身份创建了.ssh /目录或.ssh / authorized_keys文件（这通常是完成此操作的方式），则不允许该文件由另一个用户拥有（即使root用户！）。

Userify（免责声明：共同创始人）自动以完全相同的方式执行此操作。.https : //github.com/userify/shim/blob/master/shim.py#L285

我在两台服务器上遇到了完全相同的问题：一个运行Debian Stretch的Linux和一个NAS（Synology DS715）

原来，在两种情况下，服务器上的主目录权限都是错误的

服务器上的auth.log很有帮助

Authentication refused: bad ownership or modes for directory /home/cyril

在Linux上，它在（drwxrwxr--x）上具有write / group位，因此我至少要删除对group（chmod gw〜/）的写操作，然后它才能工作

在Synology上，无论出于何种原因，都有一些粘性

drwx--x--x+ 4 toto users 4096 Jan 6 12:11 /var/services/homes/toto

我不得不用

chmod -t ~/

然后我可以不用密码连接

当使用CentOS 7时，我很有信心也适用于其他使用sshd的Linux操作系统。使用root访问，您可以确定有关身份验证失败原因的更多信息。去做这个：

1. 启用sshd的日志记录： vi /etc/ssh/sshd_config
2. 在日志取消注释下：

SyslogFacility AUTH LogLevel INFO

1. 将LogLevel INFO更改为LogLevel DEBUG
2. 保存并退出
3. 重启sshd systemctl restart sshd
4. 观看消息文件 tail -l /var/log/messages
5. 使用另一个终端，尝试与ssh连接
6. 尝试与SSH连接
7. 查看身份验证日志中的确切原因

例如，我遇到了一些与上述相同的问题。

Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys

通过使用这些步骤，我能够确认问题是authorized_keys文件的权限。通过在我的用户的授权密钥文件上将chmod设置为644，此问题已解决。

您.ssh文件夹的权限似乎没有正确复制粘贴。您能再添加一次吗？

如果启用了严格模式，那么我们必须确保.ssh具有以下正确权限：

• .ssh/ 应该有烫发 0700/rwx------
• .ssh/*.pub 文件应该是 644/rw-r--r--
• .ssh/* （.ssh中的其他文件） 0600/rw-------

权限如何看待您？

以防万一有人偶然发现了这个答案-在我的情况下，没有任何建议可以奏效。最后，问题是我创建了一个没有设置密码的帐户。一旦我使用设置了密码usermod -p "my password" username，然后强行解锁了帐户，usermod -U username一切就变得扑朔迷离了。

我遇到过类似的问题，其中ssh连接~/.ssh/id_rsa在意外停止之前会尝试输入密钥：

debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

就我而言，这是由于目录中存在旧的公共密钥文件造成的.ssh：

[gitlab-runner@validation-k8s-1 ~]$ ll .ssh/id_rsa*
total 16
-rw------- 1 gitlab-runner gitlab-runner 1675 Sep 18 18:02 id_rsa      --> new private key
-rw-r--r--. 1 gitlab-runner gitlab-runner  423 Jun 12 13:51 id_rsa.pub --> old public key

id_rsa.pub从.ssh目录中移动/删除可以解决此问题。

据我了解：客户端上存在公钥时，SSH 1st会针对它验证私钥。如果失败，它将不会尝试使用私钥进行远程连接。

我已将电子邮件发送到openssh邮件列表：https : //lists.mindrot.org/pipermail/openssh-unix-dev/2016-April/035048.html。

我们遇到了这个问题。.ssh文件的权限和所有权都是正确的。在/ var / log / messages中，我们发现：

Mar 29 15:45:36 centos70 setroubleshoot: SELinux is preventing /usr/sbin/sshd from read access on the file authorized_keys. For complete SELinux messages run: sealert -l 05963b94-f318-4615-806c-b6c3a9066c82

因此，对于我们不关心安全性的开发人员vm的解决方案是禁用selinux。编辑/ etc / sysconfig / selinux并更改SELINUX = disabled并重新启动。

以防万一这也可以救人。我试图将密钥从我的Ubuntu 18.04计算机复制到2台CentOS 7服务器。我曾经ssh-copy-id转移他们。一个工作，一个没有。因此，我经历了所有权限调试，却一无所获。因此，最后我/etc/ssh/sshd_config在两台服务器上都拉起文件，并逐行通过它们。最终，我找到了它，可能是有人在我上任之前很久就对其进行了修改。

一读： AuthorizedKeysFile .ssh/authorized_keys

还有另一种读法： AuthorizedKeysFile ~/.ssh/authorized_keys，它在服务器上不接受我的密钥。显然，在两个文件之间查找并注意到指出默认搜索模式的注释不包括前导，因此~/我将其删除并重新启动了sshd。问题解决了。

也遇到了这个问题。setroubleshoot在我的环境中似乎不起作用，因此/ var / log / messages中没有这样的日志记录。禁用SELinux不是我的选择，所以我做了

restorecon -Rv ~/.ssh

之后，通过rsa键登录即可正常工作。

在我的情况下，原因是AuthorizedKeysFilefile中一个自定义设置的选项/etc/ssh/sshd_config。它被设置为另一个用户的主目录（/home/webmaster/.ssh/authorized_keys），因此我尝试登录的用户无法访问该文件/目录。

更改并重新启动ssh-server（service ssh restart）之后，一切恢复正常。我现在可以用我的私钥登录。

在我们的案例中，问题与防火墙和NAT规则未正确设置有关。

端口22，被定向到未识别我们的密钥和用户的错误服务器。

如果有人到这一点。tcpdump和telnet可以成为您的朋友

[aaron@aaron-pc ~]$ telnet someserver 22
Trying 1.1.1.1...
Connected to someserver.
Escape character is '^]'.
SSH-2.0-OpenSSH_6.7p1
^]
telnet> 

[aaron@aaron-pc ~]$ telnet someotherserver 22
Trying 1.1.1.2...
Connected to someotherserver.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
^]

您会注意到这两个服务器具有不同的openssh版本。这有助于我很快发现问题。如果您的主机使用的是相同的ssh版本，则必须尝试对目标进行打包跟踪，以查看流量​​是否确实到达了目标。

SSH会产生大量流量，这使tcpdump out很难找到您想要的内容。

这对我有帮助

 tcpdump -i any  "not host [mylocalip] and not localhost and not ip and not arp"

尝试从3个不同的服务器而不是您当前的计算机@ [mylocalip]进行telnet。您想查看实际到达服务器的流量。

客户端错误日志以如下方式结束：

Enter passphrase for key '/root/.ssh/id_rsa':
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
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
root@x.x.x.x's password:

当sshd配置文件包含以下内容时，可能是由于根登录的服务器端（远程）限制引起的：

PermitRootLogin: no

JonCav建议启用日志记录有助于调试此类问题。尽管客户端调试喷头无济于事，但请将以下内容放入sshd服务器的sshd_config文件中：

SyslogFacility AUTH
LogLevel DEBUG

最终产生了有用的日志消息：

Jul 19 19:16:38 500265-web1 sshd[21188]: Found matching RSA key: ...
Jul 19 19:16:38 500265-web1 sshd[21188]: ROOT LOGIN REFUSED FROM ...
Jul 19 19:16:38 500265-web1 sshd[21188]: Failed publickey for root from ... port ... ssh2
Jul 19 19:16:38 500265-web1 sshd[21189]: ROOT LOGIN REFUSED FROM ...

如果只有root用户登录失败，并且您的安全策略允许仅使用基于密钥的身份验证进行root登录，则对sshd_config文件进行更改可以帮助：

 PermitRootLogin without-password

您的里程可能会有所不同，尽管这通常会有所帮助，但是根据某些sshd_config文件中的注释，某些其他配置可能仍然会干扰：

# Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".

即使您无法轻松地更改远程服务器配置以这种方式进行调试，也可以通过使用相同的身份文件将SSH SSH到同一远程服务器上的非root帐户来在某种程度上证明客户端配置。

我知道为什么安全会打扰人们。我又遇到了ssh won't use my key问题。我通过登录到远程服务器并运行来解决了

/usr/sbin/sshd -sDp 23456

然后在我的桌面上（尝试SSH到服务器）

ssh -vvvv server -p 23456

在服务器上，我得到了 Authentication refused: bad ownership or modes for directory /

一些新的系统管理员弄乱了权限和所有权，我将其固定为：

chmod 0755 / ; chown root:root /

（我习惯于需要，chmod 0600 ~/.ssh/* ; chmod 0644 ~/.ssh/*.pub但是sshd检查/查找root权限对我来说是一个新权限。）现在，我将检查rootkit，然后无论如何都要擦除并重新安装。

就我而言，问题出在不正确的shell exec上。

journalctl -f
....
Feb 25 11:45:54 59a02b89e0f6 sshd[]: User user not allowed because shell /usr/bin/env /bin/bash does not exist
....

该用户的/ etc / passwd文件已更改

vi /etc/passwd 
....
user:x:1000:1000::/home/user:/bin/bash
....

我在CentOS 7上遇到了这个问题。我是基于Debian的常规Linux用户，所以我不知所措。我注意到在某些服务器中它可以工作，而在其中一台中却没有。audit.log表示没有任何用处，secure.log也不提供任何内容。我发现，唯一真正的区别是文件和目录的有效上下文和无效的上下文之间的区别。通过获取安全性

sudo ls -laZ <user-home>/.ssh

目录（我假设sshd_config上有很多默认值）。

你应该会看到一些ssh_home_t和user_home_t属性。如果不这样做，请使用chcon命令添加缺少的属性。

例如

home="$(getent passwd <user> | cut -d: -f6)"
sudo chcon -R unconfined_u:object_r:ssh_home_t:s0 "$home".ssh
sudo chcon unconfined_u:object_r:user_home_t:s0 "$home"

就我而言，我怀疑用户是以非标准方式创建的。他的家在中/var/lib。

更多信息请参见：https : //www.linuxquestions.org/questions/linux-security-4/selinux-preventing-ssh-login-with-~-ssh-authorized_keys-4175469538/