简而言之：寻找一些 ELI5 来解释 [KEX 后] 用户密钥验证（谁做什么）的协议和/或实现（openssh），而无需使用我不懂的代码，或者为新手设置密钥身份验证的过于简单的网站。我们让 Workday 和 Red Hat 对此进行了调查，但我试图在与他们打交道时成为知情的消费者。
此验证如何围绕 mm_answer_keyverify 进行？他们如何验证用户密钥（在检查并允许 authorized_keys 之后）？
- 双方是否签署了他们的密钥并且签名是否匹配？
- 他们是否使用本地签名算法加密某些内容，然后进行比较？
更多详情：
我们在从另一台服务器连接到我们内部的 EL9 系统时遇到了一些奇怪的问题。一切都运行正常，EL7 系统（正在被替换）也一样 - 使用相同的密钥（RSA）、相同的用户、相同的文件（NFS 主目录）等。主机密钥和 KEX 甚至 authorized_keys 检查均成功，并且它似乎在用户密钥上失败：我们从 Workday 和运行 curl+sftp 的 AIX 系统（但不是单独使用 sftp 的 AIX）中遇到失败）:
debug1: /home/USER/.ssh/authorized_keys:12: matching key found: RSA SHA256:aGrK...
Accepted key RSA SHA256:aGrK... found at /home/USER/.ssh/authorized_keys:12
debug3: mm_answer_keyallowed: publickey authentication: RSA key is allowed
debug3: mm_answer_keyverify: publickey RSA signature unverified: error in libcrypto
我们只好运行 LEGACY 加密策略来尝试诊断（没有成功）。就我个人而言，我认为我们遇到了库差异，其中一个仍在使用 ssh-rsa 算法，而另一个正在使用兼容性算法（“您要求使用 ssh-rsa，但我将使用 rsa-sha256-512”），因此出现了问题和我的问题，但这只是猜测，而且我是门外汉。
为了清楚起见，以下是我在服务器日志中看到的成功信息：
debug3: userauth_pubkey: have rsa-sha2-512 signature for RSA SHA256:aGrK.....
和同一台服务器，出现故障（请记住，我们暂时允许 SHA1 等，所以这不是问题；我们的用户密钥是 2k RSA sshv2 密钥，所以这也没问题）：
debug3: userauth_pubkey: have ssh-rsa signature for RSA SHA256:aGrK.....
最明显的一点是签名的差异，但我不知道为什么服务器会使用不同的签名，除非这真的是客户端对服务器说的......
谢谢您的指点！
答案1
以上都不是。该机制是签名——但只有客户端发送签名；服务器验证那个签名。
关于猜测：
-
双方是否签署了他们的密钥并且签名是否匹配？
这是不可能的，因为只有一方拥有私钥来签名——服务器无法在只有公钥的情况下签名，而且这没有任何实际意义。（公钥/私钥的这种不对称实际上是非对称算法的重点；它与 HMAC 或密码哈希完全不同。）相反，当一方签署某些内容时，另一方将核实对数据进行签名——与加密/解密非常相似，签名有一个补充的“验证”操作。
因此，如果服务器说“有 ssh-rsa 签名”，则意味着它有已收到来自客户端的这样的签名并且即将执行验证（由于某些奇怪的原因失败了）。
-
他们是否使用本地签名算法加密某些内容，然后进行比较？
你不需要使用签名算法来加密；你符号签名算法。即使底层数学恰好相似（并且这仅适用于某些算法），您也不应该认为它们是相同的。
此外，“加密和比较”没有用，因为 RSA 加密仅使用公钥完成 - 而公钥通常是公开的 - 因此很容易被欺骗。您需要一个涉及私钥的操作，即签名或解密。
顺便提一下，加密/解密曾经是 SSHv1 的方法：服务器用来加密质询并请求客户端解密。但在 SSHv2 中，不再采用这种方式，它只使用签名（和签名验证）：拥有私钥的一方（对于 authorized_keys 而言，即用户）将签署“质询”——对手提供的随机数据块——并发送签名，对手将验证该签名。
请注意，“签名”操作仅接受有限大小的输入，因此签名的永远不是实际的挑战数据，而是哈希数据。ssh-rsa和之间的区别rsa-sha256-512仅在于对挑战应用了什么哈希；较新的 SSH 客户端将使用 SHA256 对其进行哈希处理，而较旧的客户端将使用 SHA1。（并且 RSA 是唯一具有灵活大小密钥且已经超越 SHA1 时代的受支持算法；EC 和 EdDSA 都使用固定大小的密钥并使用与曲线位大小完全匹配的哈希算法，因此它们不存在此类兼容性问题。）
就我个人而言，我认为我们遇到了库差异，其中一个仍在使用 ssh-rsa 算法，而另一方使用兼容性算法（“您要求使用 ssh-rsa，但我会使用 rsa-sha256-512”），因此存在问题和我的疑问，但这只是猜测，而且我是个外行。
虽然客户端可能会以错误的格式发送签名（如上所述，服务器不会自行生成签名），但失败情况通常会有所不同，因为软件会明确告知加密库要使用哪些算法。（或者，如果 SSH 服务器确实太旧而无法理解 rsa-sha256-512，那么它会拒绝该签名，认为其类型无法识别前将其传递给加密库。）