无论我做什么，SSH 权限都被拒绝（公钥）

Question 1

数据包类型 51 表示“SSH_MSG_USERAUTH_FAILURE”，通常当服务器无法识别（或喜欢/支持）客户端提供的公钥时发生。

在这种情况下，最好的故障排除方法是启用服务器端的调试日志记录，并查看服务器的调试日志输出以确定拒绝公钥的原因。

常见问题包括：

您尝试验证的用户帐户的 SSH 服务器上尚未正确配置 .pub 文件（或相应的密钥）。
.pub 文件（或相应的密钥）存在于服务器上，但它所在文件的权限过于开放，您需要先修复该服务器端文件的权限，然后服务器才会允许它尝试进行身份验证。

您提供了有关权限的信息，但不清楚您显示的权限是 SSH 客户端计算机上的 .ssh 目录还是 SSH 服务器计算机上的 .ssh 文件夹（即 izuhu 用户帐户主文件夹中的 .ssh 文件夹）。

下一步的最佳选择是检查 ssh 服务器端的日志，以找出它拒绝公钥的原因。

Answer

数据包类型 51 表示“SSH_MSG_USERAUTH_FAILURE”，通常当服务器无法识别（或喜欢/支持）客户端提供的公钥时发生。

在这种情况下，最好的故障排除方法是启用服务器端的调试日志记录，并查看服务器的调试日志输出以确定拒绝公钥的原因。

常见问题包括：

您尝试验证的用户帐户的 SSH 服务器上尚未正确配置 .pub 文件（或相应的密钥）。
.pub 文件（或相应的密钥）存在于服务器上，但它所在文件的权限过于开放，您需要先修复该服务器端文件的权限，然后服务器才会允许它尝试进行身份验证。

您提供了有关权限的信息，但不清楚您显示的权限是 SSH 客户端计算机上的 .ssh 目录还是 SSH 服务器计算机上的 .ssh 文件夹（即 izuhu 用户帐户主文件夹中的 .ssh 文件夹）。

下一步的最佳选择是检查 ssh 服务器端的日志，以找出它拒绝公钥的原因。

Question 2

如果两台机器上的所有权限都是正确的，你已经通过更改重新启动了 ssh，确保每台机器都有各自的密钥，等等，并且仍然失败

请

确保你没有sudo在一台电脑上运行 ssh，而在另一台电脑上运行。当你这样做时，将使用两个不同的密钥。一个用于 root，一个用于普通用户。你看，在我的情况下....ssh 正在寻找 root 密钥，而我甚至还没有生成一个，这就是它不断抛出错误的原因SSH Permission denied (publickey)。

我为此浪费了太多时间，这让我很沮丧，并且因为沮丧而毫无必要地彻底清除了 Debian 系统。我猜想这就是我在旧的 Debian 设置上所做的，因为我仍然在努力尝试让 ssh 在全新安装上工作。直到我像 jdev 咨询的那样调试另一台机器时，我才发现问题......

我希望这真的能帮助别人，因为我浪费了太多时间了我很自豪地说。我从这一切中学到的教训是……

如果您遇到任何问题都可以使用详细模式或调试模式....

充分利用它！不要固执！！

Answer