遇到了一个非常奇怪的问题，我自己无法解决。
带有 openssh 8.8p1-1 的 Archlinux 服务器我没有使用密码进行身份验证，只使用 SSH-RSA 密钥。公钥存储在服务器上的 /home/stiw47/.ssh/authorized_keys 中。ssh 目录权限为 700，authorized_keys 文件权限为 600 多年来一切都运行正常，直到几天前服务器上的 openssh 从 8.7p1-2 更新到 8.8p1-1 除 MobaXterm 外，所有 ssh/sftp 客户端中的一切都仍在运行。
让我尝试更好地解释一下：
- 如果我尝试从 FileZilla (sftp) 或 Android 上的 JuiceSSH (ssh) 进行连接，则一切正常，因为私钥和往常一样，这么多年一直都是这样。
- 如果我尝试从其他 Linux 机器上的终端或 MobaXterm 终端手动连接，手动的意思是使用命令：- 一切又正常了
ssh -i 'C:\Users\stiw4\Documents\keys\id_rsa' [email protected] - 如果我尝试在 MobaXterm 中使用书签（我喜欢书签），那么我会收到“服务器拒绝我们的密钥”消息
我必须提到，相同的书签，使用相同的私钥，在服务器上的 openssh 包升级之前可以正常工作，现在如果我将服务器上的 openssh 降级回 8.7p1-2，我已经在 Windows 机器上删除了 MobaXterm known_hosts 文件，但什么都没有改变。
我尝试通过在服务器上运行以下命令来调试它：
sudo `which sshd` -p 2020 -Dd
并从端口 2020 上的书签进行连接，这是日志，我不太理解：
[sudo] password for stiw47:
debug1: sshd version OpenSSH_8.8, OpenSSL 1.1.1l 24 Aug 2021
debug1: private host key #0: ssh-rsa SHA256:uMBMgYez8RvbToK8ZpuVIOT6Kt9DtjwvEEmObduXSaw
debug1: private host key #1: ecdsa-sha2-nistp256 SHA256:s/mpg8gbKeFRefGxYjuHYgXFkL8KrklpgivPk9veSXI
debug1: private host key #2: ssh-ed25519 SHA256:MopYaB4XAi8QBkE+RumfZl6IT3y17c3Mu85X+11+wRY
debug1: rexec_argv[0]='/usr/bin/sshd'
debug1: rexec_argv[1]='-p'
debug1: rexec_argv[2]='2020'
debug1: rexec_argv[3]='-Dd'
debug1: Set /proc/self/oom_score_adj from 0 to -1000
debug1: Bind to port 2020 on 0.0.0.0.
Server listening on 0.0.0.0 port 2020.
debug1: Bind to port 2020 on ::.
Server listening on :: port 2020.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: sshd version OpenSSH_8.8, OpenSSL 1.1.1l 24 Aug 2021
debug1: private host key #0: ssh-rsa SHA256:uMBMgYez8RvbToK8ZpuVIOT6Kt9DtjwvEEmObduXSaw
debug1: private host key #1: ecdsa-sha2-nistp256 SHA256:s/mpg8gbKeFRefGxYjuHYgXFkL8KrklpgivPk9veSXI
debug1: private host key #2: ssh-ed25519 SHA256:MopYaB4XAi8QBkE+RumfZl6IT3y17c3Mu85X+11+wRY
debug1: inetd sockets after dupping: 3, 3
Connection from 192.168.0.53 port 50385 on 192.168.0.21 port 2020 rdomain ""
debug1: Local version string SSH-2.0-OpenSSH_8.8
debug1: Remote protocol version 2.0, remote software version MoTTY_Release_0.73
debug1: compat_banner: no match: MoTTY_Release_0.73
debug1: permanently_set_uid: 65534/65534 [preauth]
debug1: list_hostkey_types: rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug1: kex: algorithm: diffie-hellman-group-exchange-sha256 [preauth]
debug1: kex: host key algorithm: ssh-ed25519 [preauth]
debug1: kex: client->server cipher: aes256-ctr MAC: hmac-sha2-256 compression: none [preauth]
debug1: kex: server->client cipher: aes256-ctr MAC: hmac-sha2-256 compression: none [preauth]
debug1: expecting SSH2_MSG_KEX_DH_GEX_REQUEST [preauth]
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received [preauth]
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth]
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT [preauth]
debug1: SSH2_MSG_KEX_DH_GEX_INIT received [preauth]
debug1: rekey out after 4294967296 blocks [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: rekey in after 4294967296 blocks [preauth]
debug1: KEX done [preauth]
debug1: userauth-request for user stiw47 service ssh-connection method none [preauth]
debug1: attempt 0 failures 0 [preauth]
debug1: PAM: initializing for "stiw47"
debug1: PAM: setting PAM_RHOST to "192.168.0.53"
debug1: PAM: setting PAM_TTY to "ssh"
debug1: userauth-request for user stiw47 service ssh-connection method publickey [preauth]
debug1: attempt 1 failures 0 [preauth]
userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]
Received disconnect from 192.168.0.53 port 50385:14: No supported authentication methods available [preauth]
Disconnected from authenticating user stiw47 192.168.0.53 port 50385 [preauth]
debug1: do_cleanup [preauth]
debug1: monitor_read_log: child log fd closed
debug1: do_cleanup
debug1: PAM: cleanup
debug1: Killing privsep child 64262
这对我来说是非常奇怪的情况，你有什么想法吗？
谢谢。
答案1
这是由于 OpenSSH 8.8 禁用使用 SHA-1 哈希算法的 RSA 签名造成的：
此版本默认禁用使用 SHA-1 哈希算法的 RSA 签名。进行此更改是因为 SHA-1 哈希算法在加密方面存在漏洞，并且有可能以不到 5 万美元的价格创建选择前缀哈希冲突
您还可以在您提供的日志中看到相应的消息：
userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]
PubkeyAcceptedKeyTypes +ssh-rsa可以通过添加并重新启动 sshd来恢复这些旧密钥的功能/etc/ssh/sshd_config。但这只能作为临时解决方案，用使用更现代、更安全的算法（如 Ed25519）的密钥替换旧密钥（请参阅ArchWiki - SSH 密钥 - Ed25519)，因为存在安全隐患。
密钥在终端中起作用的原因似乎是 SSH 协议的实现较新（与 MobaXterm 中使用的协议相比），该协议会自动使用这些旧密钥的 SHA-256/512 而不是 SHA-1。我无法验证这一点，但根据OpenSSH 8.8 - 可能不兼容的变化：
[...] 现有的 ssh-rsa 密钥将在可能的情况下自动使用更强大的算法。