I'm not educated on the subject matter, so it doesn't matter when I think that this absolutely is non-issue and does not impact SSH security. For people like me, could someone showcase how, given the MD5 hash, they successfully login to the device, not having access to the private key of the client. Don't explain to me why it works, show me how you login to Cisco device using this. Explaining won't work, because from my perspective in this thread it has been very well explained why it doesn't matter, why there is no security issue. Another thought, suggestion not to use public key because of this may not be warranted, even if this would be a problem. Because in practice BCP (people may argue, but it is true) is to ignore the host key of network devices, people configure their tooling (rancid, etc) to ignore keys, because for commanding majority managing the keys is not a reasonable ask. I have repeatedly asked vendors to expose the router private key in config, so that the key would transfer in the normal process when broken RE is swapped etc. I believe in practice this would yield to some of us actually enabling key checking, reducing little bit theoretical security and increasing massively practical security. Having said that, my understanding is that because client public key encrypts the sessionID, and because sessionID is different between client-MITM and MITM-server, MITM cannot proxy client's connection to the server, when using key auth, but can when using password auth. So even with very poor host key hygiene MITM is not possible with key auth. On Thu, 4 Sept 2025 at 01:04, nanog--- via NANOG <nanog@lists.nanog.org> wrote:
On 3/09/25 15:39, Tom Beecher via NANOG wrote:
Brent-
Yes, IOS is storing the MD5 of the binary key data, not the base64 version. I had that wrong. Still a distinction without a difference. The preimage problem still exists. Except it's not a problem, as already discussed. And as you've been clearly ramping up the condescension in the last few messages, I don't feel inclined to debate this with you any further. Take care.
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/CHEAQZRP...
-- ++ytti