Dan- This paragraph is important to unpack. For each of these, your ssh client uploads the whole public key (not a
nonce, not a hash). Because you’ve sent the whole key, Cisco IOS receives it, hashes it, and if it matches the md5 hash stored in its config, then it says “yes, this one is good for authentication, please use that private key that matches the key you just sent, to log in”, then you get prompted:
Close , but not quite. The fingerprints are used *to identify which public key to use* for the challenge/response. 1. ssh-server uses the fingerprint to quickly determine which *stored public key to use* 2. ssh-server *uses the stored public key* to generate the challenge, and sends it to the client 3. ssh-client *uses the private key* ( either directly or via agent) to decrypt the challenge and respond to ssh-server 4. ssh-server receives the challenge response, and if successful client is authenticated The actual public key is still stored and used for this ; it can't work otherwise. The actual public key is still stored and used for the auth process; it can't work otherwise. Just because the CLI only shows you the fingerprints doesn't mean anything. This other statement is important as well : Those places could have then generated an ssh private key, having a public
key with the same md5 hash. It would have been mathematically hard to do so, but this is a possible offline (massively-parallel) attack. Just sitting generating keys. They would not have to try those keys against your router to attempt auth.
Any circumstance where the public part of *different keypairs* hashed to the same thing would mean that keygen algorithm is instantly dead and no longer usable. Anywhere. On Sun, Aug 31, 2025 at 5:41 AM Dan Mahoney via NANOG <nanog@lists.nanog.org> wrote:
Randy,
Something else I recently discovered that relates to this issue:
I think there’s a serious flaw in the way ssh key hashes are done on IOS. I’ve been in touch with Cisco CSIRT about it, and they’ve approved publication, but in short, if you’re using pubkey auth to a cisco device, you might want to rethink it.
Short version: Unlike normal pubkeys, IOS only stores an md5 hash of your key to auth against, and you can thus use any key that matches that hash. Which an attacker now has.
https://gushi.medium.com/what-i-learned-from-configuring-ssh-pubkey-auth-on-...
(should not be paywalled, email me privately if it is)
On Aug 30, 2025, at 11:30, Randy Bush via NANOG <nanog@lists.nanog.org> wrote:
a fellow nanogger wrote:
I've only *just* gotten to the note from a week or more ago.
+ tftp-server nvram:startup-config <<<<<<====== snmp-server community foo 98 snmp-server trap-source Vlan1 snmp-server location Ashburn VA US
I, too, got this from a RANCID setup I built a long time ago.
and here is the talos report, thanks joe
https://blog.talosintelligence.com/static-tundra/
set `no vstack` in config. no, that is not the default.
I'd told the owner that I didn't think he had control of his gear anymore, but this helped me to convince him to put a new switch in.
moving this to nanog because i did not elaborate on a critical point.
when you get this, presume the config of this trivial ancient devic has been snatched. did the device have any burned in users, a la
username foo privilege 15 password 7 bar
and that uid/pass is used on other, presumably more modern, devices, you need to change the passwords everywhere.
same for other credentials, snmp, bgpmd5, ...
randy _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/HJ64BOPT...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/FKCDTX5W...