SSH失败，并延迟了公钥错误
在RHEL 7上的/var/log/sshd文件中收到此错误消息
错误：SSH连接失败并延迟了公钥
以下是我的/var/log/sshd中的代码片段。
根据发行版的不同，我们可能还会在/var/log/secure中得到此错误，或者我个人更喜欢使用journalctl来检查所有日志，这样我就不必浏览其他日志了。
Jan 22 12:46:59 server1 sshd[28720]: Connection from 10.43.138.1 port 46668 on 10.43.138.8 port 22 Jan 22 12:46:59 server1 sshd[28720]: Postponed publickey for root from 10.43.138.1 port 46668 ssh2 [preauth] Jan 22 12:47:02 server1 sshd[28720]: ROOT LOGIN REFUSED FROM 10.43.138.1 port 46668 Jan 22 12:47:02 server1 sshd[28720]: Failed publickey for root from 10.43.138.1 port 46668 ssh2: RSA SHA256:mTcxALlpalgvTOaASZ3xbykAoWLrPQk356cd/YhKgg8 Jan 22 12:47:02 server1 sshd[28720]: ROOT LOGIN REFUSED FROM 10.43.138.1 port 46668 [preauth]
我希望我们熟悉与systemd-journald和rsyslog一起工作的日志记录，这与传统的syslog完全不同。
调试：了解环境
熟悉环境非常重要。
我们必须知道允许和期望哪种SSH身份验证。
SSH身份验证方法有6种不同类型，那么我们使用哪种呢？好像我们收到此错误，意味着在服务器端的/etc/ssh/sshd_config中的某些配置已更改。
但这也可能是由于客户端SSH配置(即理想情况下位于/etc/ssh下的ssh_config)引起的，或者也可以将其保留在用户的主目录下。
我们创建这样的客户端SSH配置，以便每次我们对服务器执行SSH时都会解析其他参数，以避免在命令中重复长参数
调试：检查日志
我们需要做的下一件事是"检查日志"以获取与SSH连接失败有关的提示和线索。
SSH日志文件的位置会根据Linux或者Unix发行版而有所不同，但我建议我们使用journalctl(如果支持)
现在，"延迟的公钥"可能并不总是意味着我们有错误`。
这也可能意味着我们启用了不同的SSH通信模式，并且pubkey的auth方法被忽略，SSH寻找了不同的auth方法。
例如，如果我们按照提供的顺序获得此消息，则意味着" SSH确实成功"，因此检查完整的消息很重要
Postponed publickey for user from 10.43.138.9 port 45514 ssh2 [preauth] Accepted publickey for user from 10.43.138.9 port 45514 ssh2
调试：详细执行SSH
现在我们知道了来自服务器的日志和错误消息，但是在我们的案例中并没有太大帮助。
接下来，我们将使用"脚本"工具"捕获SSH客户端日志"。
# script /tmp/SSHclient Script started, file is /tmp/SSHclient
这将启动一个新会话，并将捕获屏幕上的所有内容并将其存储在文件/tmp/SSHclient中，稍后将使用该文件获取RCA。
接下来，我们使用-vvv从客户端执行SSH以启用详细
# ssh -vvv root@server1
我将仅在重要输出中查找重要消息。
debug1: Authenticating to server1:22 as 'root' debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive debug3: authmethod_lookup gssapi-keyex debug1: Next authentication method: gssapi-keyex debug1: No valid Key exchange context debug3: authmethod_is_enabled gssapi-with-mic debug1: Next authentication method: gssapi-with-mic debug1: Unspecified GSS failure. Minor code Jan provide more information No Kerberos credentials available (default cache: KEYRING:persistent:1007) debug1: Unspecified GSS failure. Minor code Jan provide more information No Kerberos credentials available (default cache: KEYRING:persistent:1007) debug2: we did not send a packet, disable method debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/hynman/.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 60 debug1: Server accepts key: pkalg rsa-sha2-512 blen 279 debug2: input_userauth_pk_ok: fp SHA256:mTcxALlpalgvTOaASZ3xbykAoWLrPQk356cd/YhKgg8 debug3: sign_and_send_pubkey: RSA SHA256:mTcxALlpalgvTOaASZ3xbykAoWLrPQk356cd/YhKgg8 Enter passphrase for key '/home/hynman/.ssh/id_rsa': debug3: authmethod_lookup keyboard-interactive debug3: remaining preferred: password debug3: authmethod_is_enabled keyboard-interactive debug1: Next authentication method: keyboard-interactive debug2: userauth_kbdint debug3: send packet: type 50 debug2: we sent a keyboard-interactive packet, wait for reply Password: debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive debug2: userauth_kbdint debug2: we sent a keyboard-interactive packet, wait for reply debug2: input_userauth_info_req debug2: input_userauth_info_req: num_prompts 1 Password:
涉及的步骤
支持的身份验证列表为"公钥，gssapi-keyex，带麦克风的gssapi-mic，密码，键盘交互"。
第一种首选的auth模式是gssapi-keyex，由于没有有效的密钥交换上下文而失败。
下一个SSH客户端使用了" gssapi-with-mic"，由于没有可用的Kerberos凭据而再次失败
下一个首选的auth模式是pubkey。
现在，这变得很有趣，SSH能够找到公钥并要求输入密码，但是由于某些原因，SSH没有通过下一步SSH尝试了" keyboard-interactive"，但再次失败了
最后，SSH尝试通过"密码"进行连接，并且也失败了
解决方案：
现在我们进入获取根本原因分析并修复错误的最后一部分：
在我的环境中，我知道我们仅允许"基于SSH公钥的身份验证"，因此我们要做的第一件事是"从服务器端禁用所有其他类型的SSH身份验证方法"，即"/etc/ssh/sshd_config"和客户端侧面/etc/ssh/ssh_config在sshd_config文件中禁用它们(或者如果我们具有客户端配置，则在ssh_config文件中也禁用)
GSSAPIAuthentication no ChallengeResponseAuthentication no
由于我们使用基于公钥的身份验证，因此已启用
PubkeyAuthentication yes
接下来检查" AllowUsers"和" AllowGroups"部分(如果已添加)，并确保允许用户
最后，在这种情况下，我们知道公钥身份验证不起作用，因此我检查并发现
PermitRootLogin no PasswordAuthentication yes
因此，我们得到了密码提示，因为还启用了基于密码的身份验证，并且用户root的公共密钥身份验证失败，因为PermitRootLogin设置为no。
如果我们还希望以root用户身份登录，则必须使用PubkeyAuthentication将PermitRootLogin设置为without-password。
通过此更改，我重新启动了我的sshd
# systemctl restart sshd
"并且我能够登录到我的服务器"。
但是，如果我们仍然面临SSH连接失败的问题，也可以查看下一章。
检查SSH权限
SSH配置也可能存在一些权限问题，因此请确保在日志文件中在服务器和客户端上查找这些消息。
这些只是来自SSH的一些可能的与权限相关的错误消息，我们也可能会获得其他任何可能的消息：
Load key "/home/hynman/.ssh/id_rsa": Permission denied Authentication refused: bad ownership or modes for file /root/.ssh/authorized_keys User amit from server10 not allowed because none of user's groups are listed in AllowGroups User root from 10.43.138.1 not allowed because none of user's groups are listed in AllowGroups
SSH相关密钥和文件的建议权限值
~/.ssh/authorized_keys必须具有644权限
私钥文件，即~/.ssh/id_rsa应该为600，密钥名称可能因用户环境而异
公钥文件，即~/.ssh/id_rsa.pub应该为644，密钥名称可能因用户环境而异
~/.ssh目录不能在世界范围内可读/可写，因此我们可以在拥有700权限的情况下进行保存
