The server creates the challenge using the public key the client just sent to it. The server knows it's the right public key because it matches the hash. Without the hash, the client could send any random public key and the server would challenge it and the client would pass, and that would be silly.
But it's not a security risk (yet) because of the other message I just sent regarding MD5. On 31 August 2025 15:43:58 CEST, Tom Beecher via NANOG <[email protected]> wrote: >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/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/O2EEE65S7KDVY22PI6CYX66AECE2RWOE/
