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 <[email protected]> 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-cisco-ios-cbeb1e5b3b77 > > (should not be paywalled, email me privately if it is) > > > On Aug 30, 2025, at 11:30, Randy Bush via NANOG <[email protected]> > 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/[email protected]/message/HJ64BOPTJ75K3EX5AEHR4E4LW5OZEEQG/ > > _______________________________________________ > NANOG mailing list > > https://lists.nanog.org/archives/list/[email protected]/message/FKCDTX5WO74LJBAE5DDNDBW3V7J76AB7/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/ZA6VF3XMJP3FF5IA7X2CFWB5S7YHTTUB/
