使用密钥进行 SSH 身份验证时，中间人攻击是否会构成安全威胁？
我不是网络安全方面的专家，所以如果这个问题不是很聪明，请原谅:)。 我正在使用 ssh 自动登录某些机器。我目前正在使用 StrictHostKeyChecking no 避免主机密钥警告。
我天真地知道有人可以冒充服务器，如果是这样的话，我就有可能将密码丢失给他。但是，如果我仅使用基于公钥/私钥的身份验证（使用 PasswordAuthentication no ），入侵者仍然会造成伤害吗？
所以基本上，使用 ssh -o "StrictHostKeyChecking no" -o "PasswordAuthentication no" ：
1) 入侵者可以破译我的私钥吗？
2）是否存在其他安全威胁？
问候，
太平绅士
I am no expert in network security, so pardon if this question is not very smart :).
I am automating logins to some machines using ssh. I am currently avoiding host-key warnings using StrictHostKeyChecking no.
I naively understand that someone can impersonate as the server and I risk losing my password to him if that were the case. However, if I am using only public/private Key based authentication ( using PasswordAuthentication no ), can the intruder still cause harm?
So basically, with ssh -o "StrictHostKeyChecking no" -o "PasswordAuthentication no" :
1) Can the intruder decipher my private key?
2) Are there any other security threats?
regards,
JP
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
实际上，公钥认证方法可以防止MITM攻击。据我所知，这是一个巧合，而不是有意为之。虽然不可能进行全面的 MITM 攻击，但攻击者仍然可以冒充服务器：接收客户端发送的命令和数据并向客户端返回任意响应。因此，禁用服务器主机密钥检查可能不是一个好主意。
下面解释为什么使用公钥认证时无法执行全面的 MITM 攻击。我的博客文章 http://www.gremwell.com/ssh-mitm-public-key-authentication 包含更多详细信息。
在 MITM 攻击期间，攻击者将自己插入客户端和服务器之间并建立两个单独的 SSH 连接。每个连接都有自己的一组加密密钥和会话 ID。
要使用公钥方法进行身份验证，客户端使用私钥对一堆数据（包括会话 ID）进行签名，并将签名发送到服务器。服务器应验证签名并在签名无效时拒绝身份验证尝试。如上所述，服务器和客户端对于会话 ID 应该是什么有完全不同的想法。这意味着服务器无法接受受 MITM 攻击的客户端生成的签名。
如上所述，客户端-MITM 和 MITM-服务器连接的会话 ID 保证是不同的。它们是根据与 Diffie-Hellman 单独或每个连接协商的共享密钥计算的。这意味着攻击者无法安排两个会话具有相同的会话 ID。
Actually, public-key authentication method prevents MITM attack. As far as I can tell, it is a coincidence, not by design. While full-blown MITM attack is not possible, the attacker still can impersonate the server: receive commands and data sent by the client and return arbitrary responses to the client. So it might be not a good idea to disable server host key checking after all.
Below is the explanation why full-blown MITM attack cannot be executed when public-key authentication is used. My blog post http://www.gremwell.com/ssh-mitm-public-key-authentication contains some more details.
During MITM attack, the attacker inserts themselves in between the client and the server and establishes two separate SSH connections. Each connection will have its own set of encryption keys and session id.
To authenticate using public-key method, the client uses the private key to sign a bunch of data (including the session id) and sends the signature to the server. The server is expected to validate the signature and to reject the authentication attempt if the signature is invalid. As explained above, the server and the client will have completely different idea about what session id is supposed to be. It means there is no way for the server to accept the signature generated by the client under MITM attack.
As mentioned above, the session ids are guaranteed to be different for client-MITM and MITM-server connections. They are calculated from on the shared secret negotiated with Diffie-Hellman, separately or each connection. It means the attacker cannot arrange two sessions to have the same session ids.
没有。或者至少……不是直接的。由于您从未发送过私钥，因此密钥将是安全的。这并不意味着执行 MITM 攻击的人无法执行命令和/或读取您获得的输出。
是的，还有其他风险。如果执行 MITM 攻击的人将数据转发到正确的服务器，则可能会使用您的私钥在您尝试访问的计算机上执行命令。
No. Or atleast... not directly. Since you never send your private key, the key will be safe. That doesn't mean that the person that is executing the MITM attack can't execute commands and/or read the output you're getting.
Yes, there are other risks. If the person executing the MITM attack forwards the data to the correct server than it might be possible to use your private key to execute commands on the machine you were trying to access.