SSH-Key 认证失败

Question 1

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

# paste these into an SSH session that server (probably from
# another user account or root)

# change this to YOUR username on the server.
YOURUSER=example

# paste these lines verbatim:
sudo chown $YOURUSER:$YOURUSER /home/$YOURUSER/{.,.ssh/,.ssh/authorized_keys}
sudo chmod u+rwX,go-rwX,-t /home/$YOURUSER/{.ssh/,.ssh/authorized_keys}
sudo chmod go-w /home/$YOURUSER/

（这是什么用户化在其“shim”脚本中自动执行更新并修复基于团队 Web 仪表板中的更改的任何权限问题。）

如果你的管理员以 root 身份创建了 .ssh/ 目录或 .ssh/authorized_keys 文件（这是最常见的问题所在），那么不允许其他用户拥有该文件，即使该用户是根。

Answer

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

# paste these into an SSH session that server (probably from
# another user account or root)

# change this to YOUR username on the server.
YOURUSER=example

# paste these lines verbatim:
sudo chown $YOURUSER:$YOURUSER /home/$YOURUSER/{.,.ssh/,.ssh/authorized_keys}
sudo chmod u+rwX,go-rwX,-t /home/$YOURUSER/{.ssh/,.ssh/authorized_keys}
sudo chmod go-w /home/$YOURUSER/

（这是什么用户化在其“shim”脚本中自动执行更新并修复基于团队 Web 仪表板中的更改的任何权限问题。）

如果你的管理员以 root 身份创建了 .ssh/ 目录或 .ssh/authorized_keys 文件（这是最常见的问题所在），那么不允许其他用户拥有该文件，即使该用户是根。

Question 2

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

事实证明，在这两种情况下，服务器上的主目录权限都是错误的

服务器上的 auth.log 非常有用

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

在 Linux 上，它有写入/组位 (drwxrwxr--x)，所以我必须至少删除组的写入 (chmod gw ~/)，然后它才能工作

在 Synology 上，无论出于什么原因，有一个粘滞位

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

我必须将其更改为

chmod -t ~/

然后我就可以不用密码连接了

Answer

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

事实证明，在这两种情况下，服务器上的主目录权限都是错误的

服务器上的 auth.log 非常有用

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

在 Linux 上，它有写入/组位 (drwxrwxr--x)，所以我必须至少删除组的写入 (chmod gw ~/)，然后它才能工作

在 Synology 上，无论出于什么原因，有一个粘滞位

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

我必须将其更改为

chmod -t ~/

然后我就可以不用密码连接了

Question 3

使用 CentOS 7 时，我相信这也适用于使用 sshd 的其他 Linux 操作系统。通过 root 访问权限，您可以确定身份验证失败的原因。为此：

启用守护进程的sshd日志记录：sudo vi /etc/ssh/sshd_config
在日志取消注释下：

SyslogFacility AUTH
LogLevel INFO

更改LogLevel为INFODEBUG
保存并退出
使用以下命令重新启动 SSH 守护程序sudo systemctl restart sshd
查看消息文件tail -l /var/log/messages
使用另一个终端，尝试使用 ssh 连接
尝试连接ssh
查看身份验证日志以了解确切原因

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

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

通过这些步骤，我能够确认问题出在authorized_keys文件权限上。通过设置我的用户的chmod 644文件authorized_keys，问题得到了解决。

Answer

使用 CentOS 7 时，我相信这也适用于使用 sshd 的其他 Linux 操作系统。通过 root 访问权限，您可以确定身份验证失败的原因。为此：

启用守护进程的sshd日志记录：sudo vi /etc/ssh/sshd_config
在日志取消注释下：

SyslogFacility AUTH
LogLevel INFO

更改LogLevel为INFODEBUG
保存并退出
使用以下命令重新启动 SSH 守护程序sudo systemctl restart sshd
查看消息文件tail -l /var/log/messages
使用另一个终端，尝试使用 ssh 连接
尝试连接ssh
查看身份验证日志以了解确切原因

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

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

通过这些步骤，我能够确认问题出在authorized_keys文件权限上。通过设置我的用户的chmod 644文件authorized_keys，问题得到了解决。

Question 4

我有过类似的问题，其中 ssh 连接尝试使用 key ~/.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 首先会根据该公钥验证私钥。如果验证失败，则不会尝试使用私钥进行远程连接。

我向 openssh 邮件列表发送了一封电子邮件：https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-April/035048.html。

Answer