Uhm.. Okey, this is bad.. But, is it really an issue? Do really people keep theirs infra access on public Internet? So anyone can poke around or even if firewalling, ACLs are wide? Maybe I am paranoid myself, but I keep stuff in non-routable network via jumpbox. Jumpbox itself is accessed only via VPN. So, its a long way to start poking around on my SSH ports devices. And even if, It will be quickly noticed... ---------- Original message ---------- From: Dan Mahoney via NANOG <nanog@lists.nanog.org> To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Dan Mahoney <danm@prime.gushi.org> Subject: Re: beware: being old sucks Date: Sun, 31 Aug 2025 02:40:12 -0700 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...

Dan, good point about Cisco IOS's implementation of ssh pubkey storage. One typo in your Medium article: You typed 'You’ve “uploaded” your private key', you meant 'You’ve “uploaded” your public key'. Indeed, Cisco's implementation is not great. A quick fix for them (while still conserving storage) would be to store a salted hash instead, and while they're at it, make it SHA instead of MD5. On Sun, Aug 31, 2025 at 5:40 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...

On Aug 31, 2025, at 06:43, Tom Beecher <beecher@beecher.cc> wrote:

Dan-

This paragraph is important to unpack.

[snip] Close , but not quite. The fingerprints are used *to identify which public key to use* for the challenge/response.

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.

I do not believe that to be the case. If it were, why does copying the same hash to a different router/switch cause it to let you in? (I tested this, and say as much.) I call out RFC 4252 section 7 here for a reason, it specifies that what’s transmitted is referred to as a “binary blob”, which is later broken down into the components in 4253 Section 6.6. What’s transmitted for RSA keys is the modulus (i.e your semiprime) and e (your exponent), which is effectively the entire public key, less the comment field.

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.

Correct. It hasn’t happened, yet. But there have been rashes of weak rng’s in openssl (decades ago) that led to poor key choices that were more factorable, and there are now lists of public-key-blacklists (which IOS devices don’t check). (https://factorable.net/, https://wiki.debian.org/SSLkeys) And because it needs to be an md5 hash of the product of two prime numbers, it’s not like one can just pad random binary data in there to affect the hash. I say that much in the paper, but I call out what could have been done differently, as well: * Vendor could have stored the whole key, and not just given you the illusion it was being stored. * Vendor could have placed limitations on allowable key length. * Vendor could have updated the signature alg. * Vendor could have advised the use of a key only for this purpose. Is it likely that someone’s still using a weak key from that long ago? God I hope not, but we’re still using 8 inch floppies in our nuclear arsenal and still have ATMs running WIndows XP, so I wouldn’t be shocked if some key were buried in some provisioning system somewhere. Algorithms move, and at one point, DES and even 3DES was considered unbreakable. Right now, it would seem that generating a deliberate key that matches a known hash isn’t possible (even with the md5 weaknesses), but in my heart, I believe a dedicated nation-state with a good cyberwarfare budget would try anyway. RSA key generation is really only about finding primes, and if one good thing came out of cryptocurrency, it was a better understanding of how easy it is to get into custom FPGAs and ASICs to do this stuff. Anyway, my point was that in light of Randy’s recently posted vulnerabilites, that any key that you might have used for pubkey auth into *any* device here should probably be retired, and that if for some reason pubkey is part of your workflow, you should probably generate and use a key *only* for that purpose, and not your general purpose id_rsa.pub. At the very least, one should think about how this is different from every other system out there. -Dan

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 <nanog@lists.nanog.org> 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 <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...

---

NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZA6VF3XM...

(Not a sec guy disclaimer) && (sorry I think I don’t see the full history of the thread for some reason) Hashes are indeed a compromise - don’t provide sensitive information; only provide a good enough hint that you possess that information. Storing a hash instead of the key protects the key, but if it is a pub key there’s not so much point in protecting it… still, stealing the hash is mostly useless unless the hash can also be used on other devices. In that case it is effectively the same as having the”password”. Thinking quickly it might be slightly preferable to store a hash than the pub key if you don’t need to encrypt data back to the priv key owner… (/disclaimers and sorries) *Pedro Martins Prado* pedro.prado@gmail.com / +353 83 036 1875 (FaceTime & WhatsApp) On Sun 31 Aug 2025 at 20:54, Dan Mahoney via NANOG <nanog@lists.nanog.org> wrote:

...

On Aug 31, 2025, at 11:16, nanog--- via NANOG <nanog@lists.nanog.org> wrote:

There is currently no known way to generate a private key that would match your private key hash, faster than brute force, and MD5 still provides adequate protection against brute-force attacks.

While nobody should be designing new protocols using MD5 just because there is no reason to use a hash algorithm that has *any* known weaknesses, its known weaknesses are not relevant to this application.

A method is known to generate two pieces of data with the same MD5 hash. This isn't the same thing as saying that a method is known to generate a piece of data with any given MD5 hash, or the same MD5 hash as another piece of data.

And that’s why this isn’t a CVE with a CVSS score. It’s just an indication of someone cutting corners in a way I’ve never seen before, that makes me wonder what other choices were made. I say that much.

-Dan _______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/G2NJ5JEF...

Well, that's even more complicated. When we talk about MD5 hash collision in the context of passwords the problem is still complex but at the same time way more complex when considered in the context of SSH keys. See for password collision, you merely need to find _any_ string that would cause an MD5 collision and can use that string as a password - however it does not need to be the correct password, it just needs to hash to the same thing. When we talk about SSH, complexity explodes, because you need to find an MD5 collision that is also a "collision" with the public key (which means both have to have the same moduly). To say it simpler, you will have to calculate multiple MD5 collisions and test each one of them if it can satisfy the public key. On Sun, Aug 31, 2025 at 12:54 PM Dan Mahoney via NANOG < nanog@lists.nanog.org> wrote:

...

On Aug 31, 2025, at 11:16, nanog--- via NANOG <nanog@lists.nanog.org> wrote:

There is currently no known way to generate a private key that would match your private key hash, faster than brute force, and MD5 still provides adequate protection against brute-force attacks.

While nobody should be designing new protocols using MD5 just because there is no reason to use a hash algorithm that has *any* known weaknesses, its known weaknesses are not relevant to this application.

A method is known to generate two pieces of data with the same MD5 hash. This isn't the same thing as saying that a method is known to generate a piece of data with any given MD5 hash, or the same MD5 hash as another piece of data.

And that’s why this isn’t a CVE with a CVSS score. It’s just an indication of someone cutting corners in a way I’ve never seen before, that makes me wonder what other choices were made. I say that much.

-Dan _______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/G2NJ5JEF...

So I will correct myself here a little bit, specifically this statement that I am wrong on : The actual public key is still stored and used for the auth process; it

can't work otherwise

Dan is correct here in that : - SSH_MSG_USERAUTH_REQUEST contains the pubkey in the blob. - Cisco appears to be just taking that pubkey, taking its MD5, and if that MD5 matches what it has in the config, it will then use that pubkey for the rest of the bits. With MD5 , generating a collision is solved. But for this to be exploitable, you would have to : 1. Generate a colliding result that is ALSO valid for the public key algorithm specified. 2. Generate a private half of the key that is also valid for the algorithm specified. #1 is perhaps theoretically possible, but without knowing the math I'd say almost impossible. #2 still being impossible is the bedrock principle that makes asymmetric crypto work. On Sun, Aug 31, 2025 at 2:12 PM Dan Mahoney <danm@prime.gushi.org> wrote:

...

On Aug 31, 2025, at 06:43, Tom Beecher <beecher@beecher.cc> wrote:

Dan-

This paragraph is important to unpack.

[snip] Close , but not quite. The fingerprints are used *to identify which public key to use* for the challenge/response.

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.

I do not believe that to be the case.

If it were, why does copying the same hash to a different router/switch cause it to let you in? (I tested this, and say as much.)

I call out RFC 4252 section 7 here for a reason, it specifies that what’s transmitted is referred to as a “binary blob”, which is later broken down into the components in 4253 Section 6.6. What’s transmitted for RSA keys is the modulus (i.e your semiprime) and e (your exponent), which is effectively the entire public key, less the comment field.

...

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.

Correct. It hasn’t happened, yet. But there have been rashes of weak rng’s in openssl (decades ago) that led to poor key choices that were more factorable, and there are now lists of public-key-blacklists (which IOS devices don’t check).

(https://factorable.net/, https://wiki.debian.org/SSLkeys)

And because it needs to be an md5 hash of the product of two prime numbers, it’s not like one can just pad random binary data in there to affect the hash.

I say that much in the paper, but I call out what could have been done differently, as well:

* Vendor could have stored the whole key, and not just given you the illusion it was being stored. * Vendor could have placed limitations on allowable key length. * Vendor could have updated the signature alg. * Vendor could have advised the use of a key only for this purpose.

Is it likely that someone’s still using a weak key from that long ago? God I hope not, but we’re still using 8 inch floppies in our nuclear arsenal and still have ATMs running WIndows XP, so I wouldn’t be shocked if some key were buried in some provisioning system somewhere.

Algorithms move, and at one point, DES and even 3DES was considered unbreakable. Right now, it would seem that generating a deliberate key that matches a known hash isn’t possible (even with the md5 weaknesses), but in my heart, I believe a dedicated nation-state with a good cyberwarfare budget would try anyway. RSA key generation is really only about finding primes, and if one good thing came out of cryptocurrency, it was a better understanding of how easy it is to get into custom FPGAs and ASICs to do this stuff.

Anyway, my point was that in light of Randy’s recently posted vulnerabilites, that any key that you might have used for pubkey auth into *any* device here should probably be retired, and that if for some reason pubkey is part of your workflow, you should probably generate and use a key *only* for that purpose, and not your general purpose id_rsa.pub. At the very least, one should think about how this is different from every other system out there.

-Dan

While discussing this with someone else, this was brought to my attention: https://natmchugh.blogspot.com/2015/09/md5-collisions-in-ssh-keys.html from 2015, showing colliding 2048-bit public keys to the same MD5 hash. At least, enough that the ssh-keygen tool was happy to interpret it as a valid public key and provide the MD5 fingerprint of it. Happily converts it to PEM format and all that fun stuff. If it's algorithmically sound or if IOS's SSH service will accept or use it I have not explored, but so far it seems potentially usable as a seemingly valid public key. So from that perspective, #1 appears achievable. Now, of course, #2 is where it gets..... complicated. Deriving the private key for the new 2048-bit public key is a wee bit ... hard, we could say. But if we can generate a 1024 or 768 bit pubkey that collides, then this as an attack vector becomes a lot more feasible. Since IOS isn't checking key length/enforcing minimum key lengths (and indeed, is not even storing the length of the original public key that was hashed, which would cripple the potential feasibility of this attack) and allows key lengths down to 768-bit.... The trick there then becomes if a 768-bit public key would ever in the full range collide with the unknown length hashed pubkey you are trying to collide with. If you can generate a 768-bit pubkey that collides with the hash you are targeting, then it becomes a computationally "simple" exercise relatively speaking. In 2010, it took what was estimated to be 1500 years of CPU time of a single core of a 2.2GHz Opteron (a 2009 CPU) to crack a 768-bit key. https://eprint.iacr.org/2010/006 - Obviously, they had parallelized out the problem and it did not actually take that long. Actual real-time it took 6 months. Approximately about 1000 cores were used, I believe. CPU and such system bandwidth has greatly increased since then, at a massive rate. Throw in GPU compute, custom ASICs, etc as well for good fun. But as noted, key length increasing causes an exponential increase in difficulty. Of course, if the only collision is in 2048-space somehow rather safe barring quantum computing. That's a big if. 1024-bit likely is achievable with sufficient resources and time, more resources, less time. Increases your potential collision space, too. A low hanging fruit, or easy win so to speak, here from an IOS perspective would be a configurable minimum key size accepted by the SSH service, switching the hash algorithm, or as someone else pointed out, even just a unique per-device salt - or a combination of all of these to make an easy short-term fix without sizable code changes. The correct fix, of course, would be storing the entire public key and only doing an exact match for authorization... -----Original Message----- From: Tom Beecher via NANOG <nanog@lists.nanog.org> Sent: Sunday, August 31, 2025 5:19 PM To: Dan Mahoney <danm@prime.gushi.org> Cc: North American Network Operators Group <nanog@lists.nanog.org>; Tom Beecher <beecher@beecher.cc> Subject: Re: beware: being old sucks So I will correct myself here a little bit, specifically this statement that I am wrong on : The actual public key is still stored and used for the auth process; it

can't work otherwise

Dan is correct here in that : - SSH_MSG_USERAUTH_REQUEST contains the pubkey in the blob. - Cisco appears to be just taking that pubkey, taking its MD5, and if that MD5 matches what it has in the config, it will then use that pubkey for the rest of the bits. With MD5 , generating a collision is solved. But for this to be exploitable, you would have to : 1. Generate a colliding result that is ALSO valid for the public key algorithm specified. 2. Generate a private half of the key that is also valid for the algorithm specified. #1 is perhaps theoretically possible, but without knowing the math I'd say almost impossible. #2 still being impossible is the bedrock principle that makes asymmetric crypto work. On Sun, Aug 31, 2025 at 2:12 PM Dan Mahoney <danm@prime.gushi.org> wrote:

...

On Aug 31, 2025, at 06:43, Tom Beecher <beecher@beecher.cc> wrote:

Dan-

This paragraph is important to unpack.

[snip] Close , but not quite. The fingerprints are used *to identify which public key to use* for the challenge/response.

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.

I do not believe that to be the case.

If it were, why does copying the same hash to a different router/switch cause it to let you in? (I tested this, and say as much.)

I call out RFC 4252 section 7 here for a reason, it specifies that what’s transmitted is referred to as a “binary blob”, which is later broken down into the components in 4253 Section 6.6. What’s transmitted for RSA keys is the modulus (i.e your semiprime) and e (your exponent), which is effectively the entire public key, less the comment field.

...

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.

Correct. It hasn’t happened, yet. But there have been rashes of weak rng’s in openssl (decades ago) that led to poor key choices that were more factorable, and there are now lists of public-key-blacklists (which IOS devices don’t check).

(https://factorable.net/, https://wiki.debian.org/SSLkeys)

And because it needs to be an md5 hash of the product of two prime numbers, it’s not like one can just pad random binary data in there to affect the hash.

I say that much in the paper, but I call out what could have been done differently, as well:

* Vendor could have stored the whole key, and not just given you the illusion it was being stored. * Vendor could have placed limitations on allowable key length. * Vendor could have updated the signature alg. * Vendor could have advised the use of a key only for this purpose.

Is it likely that someone’s still using a weak key from that long ago? God I hope not, but we’re still using 8 inch floppies in our nuclear arsenal and still have ATMs running WIndows XP, so I wouldn’t be shocked if some key were buried in some provisioning system somewhere.

Algorithms move, and at one point, DES and even 3DES was considered unbreakable. Right now, it would seem that generating a deliberate key that matches a known hash isn’t possible (even with the md5 weaknesses), but in my heart, I believe a dedicated nation-state with a good cyberwarfare budget would try anyway. RSA key generation is really only about finding primes, and if one good thing came out of cryptocurrency, it was a better understanding of how easy it is to get into custom FPGAs and ASICs to do this stuff.

Anyway, my point was that in light of Randy’s recently posted vulnerabilites, that any key that you might have used for pubkey auth into *any* device here should probably be retired, and that if for some reason pubkey is part of your workflow, you should probably generate and use a key *only* for that purpose, and not your general purpose id_rsa.pub. At the very least, one should think about how this is different from every other system out there.

-Dan

_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/UADC46ZE...

On Sun, Aug 31, 2025, 17:25 Tom Beecher <beecher@beecher.cc> wrote:

Which means if IOS does no pubkey packet length validation, you no longer

...

need to generate a keypair that has a pubkey that collides on MD5. You just need a blob that collides with that hash, and will *truncate* to a key you control. Which is much easier to collide.

To actually exploit this :

Generating a collision isn't hard. But you'd have to generate a collision that was also valid to use in the key algorithm specified in SSH_MSG_USERAUTH_REQUEST.

Which is an undefined size, which isn't normally a problem, but keep that in mind. So now you actually need a preimage attack, and even for MD5 that's not

feasible still.

Even if you managed to pull that off, you STILL don't have valid private half of the keypair. And if you could do that you just broke all of modern cryptography so we have other problems. :)

Bob generates an RSA 4096 keypair, *KP1*. This keypair has public key *K1*. On the wire, that pubkey component is sent like this in *SSH_MSG_USERAUTH_REQUEST*: # ( ... ) *0x00000007* (length: 7 bytes follow (or whatever length for the key type, depending on if you're trying to auth with ssh-rsa, ssh-rsa2-sha256, ssh-rsa2-sha512, etc.) *0x7373682d727361* (string, "ssh-rsa". see above) *0x00000003* (length: 3 bytes follow) *0x010001* (RSA's *e*) *0x00000201* (length: 513 bytes follow) *0x......* (RSA's *n*) Worth noting that this is the *same exact* format, encoded to base64, that is the second column in your *~/.ssh/id_<type>.pub* file (e.g. in this case, *~bob/.ssh/id_rsa.pub*). IOS device *foo* has authorized a(ny) key with MD5 *C,* an MD5 checksum of public key *K1*. As stated in the other thread, *foo* only bases authn on if the *checksum* presented key matches *C*. *foo* does not store *K1* locally. It does not use *C* to look up a local *K1*. The only course of action forward, given that ...*interesting* design choice, then is to use the key that the client presents - provided its checksum matches *C*. We agree on that, yes? Alice creates keypair *KP2*, with public key *K2*. Alice then pads junk to *K2*'s *n* until she reaches collision in the wire-packed form with *C,* creating *Blob1*. Let's say Alice had to add 512 bytes to reach collision with *C*. Alice now initiates an SSH connection with *foo*, and starts *SSH_MSG_SERVICE_REQUEST*. Alice sends *Blob1* to *foo* as part of *SSH_MSG_USERAUTH_REQUEST*: # (...) *0x00000007* *0x7373682d727361* *0x00000003* *0x010001* *0x00000401* (length: *1025* bytes follow instead of 513) *0x......* (Alice's RSA's *n)* *0x.... (junk data)* *Foo* reads in that key and parses it. While parsing, it already knows from KEX that it's RSA 4096. So let's say the IOS version of sshd does something extremely stupid[0] and uses a fixed length lookup table. "Oh, it's RSA 4096. I need exactly 3 bytes bytes from the buffer for the pubkey's *e* and 513 bytes for *n*. I can skip over the other unnecessary bits and pieces in the buffer. Efficiency!!1[1]" So it grabs.... 3 bytes for *e*. And it grabs... 513 bytes. For *n*. Hey Tom, what would happen in that case? [0] More stupid than authing based on key checksum, I mean, instead of locally storing keys. And more stupid than using MD5 for that checksum. I'm sure those are just flukes. [1] "Efficiency", like you know. Not storing the entirety of a pubkey locally, or using MD5 instead of a more expensive hashing algo.

There's no known way to do #1. That's called a preimage attack. That's when you have a hash and want to generate a blob that matches it. The known attacks against MD5 are collision attacks. An attacker simultaneously generates two (slightly) different blobs which have the same MD5 hash. Since it generates both blobs at the same time, it only works here if the attacker can generate two blobs, and then put one as the public key in your router. They can then use the other one to log in. But they could also use the first one to log in, since they generated *both* blobs. This is not a real attack. And it's all irrelevant because of #2 anyway - they can't just be any blobs, but have to be public keys corresponding to private keys the attacker can work out. As far as I know, a RSA public key with some bits flipped, or a random public key, is likely to be easily factorable (which is bad), so that could be an actual threat in the collision scenario but the collision scenario is irrelevant because the attacker has to have uploaded the original public key for that to work. On 31 August 2025 23:18:57 CEST, Tom Beecher via NANOG <nanog@lists.nanog.org> wrote:

So I will correct myself here a little bit, specifically this statement that I am wrong on :

The actual public key is still stored and used for the auth process; it

...

can't work otherwise

Dan is correct here in that :

- SSH_MSG_USERAUTH_REQUEST contains the pubkey in the blob. - Cisco appears to be just taking that pubkey, taking its MD5, and if that MD5 matches what it has in the config, it will then use that pubkey for the rest of the bits.

With MD5 , generating a collision is solved. But for this to be exploitable, you would have to :

1. Generate a colliding result that is ALSO valid for the public key algorithm specified. 2. Generate a private half of the key that is also valid for the algorithm specified.

#1 is perhaps theoretically possible, but without knowing the math I'd say almost impossible. #2 still being impossible is the bedrock principle that makes asymmetric crypto work.

On Sun, Aug 31, 2025 at 2:12 PM Dan Mahoney <danm@prime.gushi.org> wrote:

...

...

On Aug 31, 2025, at 06:43, Tom Beecher <beecher@beecher.cc> wrote:

Dan-

This paragraph is important to unpack.

[snip] Close , but not quite. The fingerprints are used *to identify which public key to use* for the challenge/response.

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.

I do not believe that to be the case.

If it were, why does copying the same hash to a different router/switch cause it to let you in? (I tested this, and say as much.)

I call out RFC 4252 section 7 here for a reason, it specifies that what’s transmitted is referred to as a “binary blob”, which is later broken down into the components in 4253 Section 6.6. What’s transmitted for RSA keys is the modulus (i.e your semiprime) and e (your exponent), which is effectively the entire public key, less the comment field.

...

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.

Correct. It hasn’t happened, yet. But there have been rashes of weak rng’s in openssl (decades ago) that led to poor key choices that were more factorable, and there are now lists of public-key-blacklists (which IOS devices don’t check).

(https://factorable.net/, https://wiki.debian.org/SSLkeys)

And because it needs to be an md5 hash of the product of two prime numbers, it’s not like one can just pad random binary data in there to affect the hash.

I say that much in the paper, but I call out what could have been done differently, as well:

* Vendor could have stored the whole key, and not just given you the illusion it was being stored. * Vendor could have placed limitations on allowable key length. * Vendor could have updated the signature alg. * Vendor could have advised the use of a key only for this purpose.

Is it likely that someone’s still using a weak key from that long ago? God I hope not, but we’re still using 8 inch floppies in our nuclear arsenal and still have ATMs running WIndows XP, so I wouldn’t be shocked if some key were buried in some provisioning system somewhere.

Algorithms move, and at one point, DES and even 3DES was considered unbreakable. Right now, it would seem that generating a deliberate key that matches a known hash isn’t possible (even with the md5 weaknesses), but in my heart, I believe a dedicated nation-state with a good cyberwarfare budget would try anyway. RSA key generation is really only about finding primes, and if one good thing came out of cryptocurrency, it was a better understanding of how easy it is to get into custom FPGAs and ASICs to do this stuff.

Anyway, my point was that in light of Randy’s recently posted vulnerabilites, that any key that you might have used for pubkey auth into *any* device here should probably be retired, and that if for some reason pubkey is part of your workflow, you should probably generate and use a key *only* for that purpose, and not your general purpose id_rsa.pub. At the very least, one should think about how this is different from every other system out there.

-Dan

_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/UADC46ZE...

https://natmchugh.blogspot.com/2015/09/md5-collisions-in-ssh-keys.html

yes, md5 is well known to have collision problems. in some uses, e.g. bgpp-md5, it is less of a concenrn. in this case, ssh, it is more of a problem. randy

Few other tips: * check if there’s interfaces/tunnels setup that shouldn’t be there (sh int desc | inc Tu) * check for locally configured users that should not be there * check if nat is enabled while it should not be * Is anyone currently logged on that you don’t expect to * see if there’s unexpected tcl scripts in the flash and/or boot media. * Check if the http/https server is configured while it shouldn’t * Disable finger protocol (sometimes enabled by default) * Apply the Cisco-recommended defensive mitigations for CVE-2017-6736 through CVE-2017-6742 for securing any exposed SNMP community strings against a constrained MIB view (configs may be snatched this way) * Apply mitigations for known exploits in the vStack smart install, this is a common entry vector and it’s sometimes enabled by default while not showing in config, leaving devices wide open (show vstack config / no vstack) * I recommend doing a full nmap scan from a public non-trusted IP to see which ports may be open to the world that should, or you do not expect to be open. Adjust your ACL’s based on this. * Check your tacacs/radius config, make sure it’s not replaced/amended with something else that just functions to intercept your passwords * Verify that your ‘line’ configs don’t refer to non-default AAA configs. If the line configuration references a named AAA profile, the previously entered AAA directives will be ineffective Jeroen Wunnink Sr. Manager - Integration Engineering [A picture containing icon Description automatically generated] www.gtt.net<http://www.gtt.net/> From: Randy Bush via NANOG <nanog@lists.nanog.org> Date: Saturday, 30 August 2025 at 20:30 To: North American Network Operators' Group <nanog@lists.nanog.org> Cc: Randy Bush <randy@psg.com> Subject: Re: beware: being old sucks NOTE: This is an external message. Please use caution when replying, opening attachments or clicking on any links in this e-mail. WARNING: Replies to this message will go to nanog-bounces@lists.nanog.org. If you believe this is malicious or are unsure if this is correct, please report it using the Report Phish button and our analysts will investigate it. 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... NOTICE: This e-mail is only intended for the person(s) to whom it is addressed and may contain confidential information. Unless stated to the contrary, any opinions or comments are personal to the writer and do not represent the official view of GTT Communications Inc or any of its affiliates. If you have received this e-mail in error, please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. All quotes, offers, proposals and any other information in the body of this email is subject to, and limited by, the terms and conditions, signed service agreement and/or statement of work

Brent- IOS device *foo* has authorized a(ny) key with MD5 *C,* an MD5 checksum of

public key *K1*. As stated in the other thread, *foo* only bases authn on if the *checksum* presented key matches *C*. *foo* does not store *K1* locally. It does not use *C* to look up a local *K1*. The only course of action forward, given that ...*interesting* design choice, then is to use the key that the client presents - provided its checksum matches *C*. We agree on that, yes?

Yes.

Alice creates keypair *KP2*, with public key *K2*. Alice then pads junk to *K2*'s *n* until she reaches collision in the wire-packed form with *C,* creating *Blob1*. Let's say Alice had to add 512 bytes to reach collision with *C*.

The key blob is *encoded* , not hashed. base64(x) can never equal base64(y), and therefore cannot collide. !!! My understanding is different, that any colliding hash will match. If pubkey(value) Md5(value) Equals the stored config value, then it approves it.

(Or, rather, the actual bytes that that hex *represents*.) On Tue, Sep 2, 2025 at 7:51 PM brent saner <brent.saner@gmail.com> wrote:

On Tue, Sep 2, 2025 at 1:33 PM Tom Beecher <beecher@beecher.cc> wrote:

...

Alice creates keypair *KP2*, with public key *K2*. Alice then pads junk

...

to *K2*'s *n* until she reaches collision in the wire-packed form with *C,* creating *Blob1*. Let's say Alice had to add 512 bytes to reach collision with *C*.

The key blob is *encoded* , not hashed. base64(x) can never equal base64(y), and therefore cannot collide.

No, Tom; from the described problem in the other thread, the problem is the key is *hashed* *in IOS' implementation*. It's MD5'd, and that MD5 checksum is compared against an auth list of admin-specified key checksums. If it matches, it then accepts *and uses* the *provided* pubkey. (OpenSSH, for instance, properly relies on *local storage* for public key authentication=>crypto rather than comparing checksums and using a session-provided key.)

That's what the entire hootenanny is about.

It's also not sent base64-encoded over the wire. At all. It's sent *as octets* representing the public exponent *e* and (roughly) n/2-bits-long *n* value (a product of *p/q*). (Assuming you're using RSA. ED25519 it's just the public half of the private keys.) https://datatracker.ietf.org/doc/html/rfc8332#section-3 https://datatracker.ietf.org/doc/html/rfc8332#section-3.2

Defined as:

string public key blob: string "ssh-rsa" mpint e mpint n

Note what an mpint is (per terminology <https://datatracker.ietf.org/doc/html/rfc8332#section-1.2>):

mpint

Represents multiple precision integers in two's complement format, stored as a string, 8 bits per byte, MSB first. Negative numbers have the value 1 as the most significant bit of the first byte of the data partition. If the most significant bit would be set for a positive number, the number MUST be preceded by a zero byte. Unnecessary leading bytes with the value 0 or 255 MUST NOT be included. The value zero MUST be stored as a string with zero bytes of data.

By convention, a number that is used in modular computations in Z_n SHOULD be represented in the range 0 <= x < n.

Examples:

value (hex) representation (hex) ----------- -------------------- 0 00 00 00 00 9a378f9b2e332a7 00 00 00 08 09 a3 78 f9 b2 e3 32 a7 80 00 00 00 02 00 80 -1234 00 00 00 02 ed cc -deadbeef 00 00 00 05 ff 21 52 41 11

- https://datatracker.ietf.org/doc/html/rfc4251#section-5

What you may be confused about is the public key's storage *on-disk*.

Your ~/.ssh/id_rsa.pub might look like this:

*ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDx92RsPGT6BnKzVFxaYPKR1hJuUMS79UHtz6WzF1dqeNjcyTAPCQMxtNjEKGbfX6x+JdCPmumyjBX7QHE4ywDxx6gIXhjBThNlvc00ccM0f3FT+DRc6MqdsQeB8lvgbiWBETDD7T+oy20BmQ7xfn5sFXuIwxX3BU3C5OK7n7J7sBf47SLndbvXtT1pkPryV5sTDoZ+Xc3YiIUzum2vsR+8TehXOFNSaOWwEoICiXa7Ob07yxLMzE7V4CofLOM0tAj1NHNR134mUZecGZXqd3beH0c1x5eYByRLobAz3NycUigqoSSdh6g41NcaZ7Mb47V4KG7SgV7zG0RvKRN+oGQMuf9MLfiOJAYi2J2Zvtw+40xtRY8hmVsXTJaaio6wG77MdGSU7oCgcF50I1PPUjlasH0LmNoi+qC0/74gQ3GEMe+fEfAJAJspwtk2FMQX0Tniq0MjZFWVzFqx80dJhPIHnenwVJGZHOJcd9zn3NxXioCQUuEiZne6R4EPjPfJ16EIJQPZCHhxaMGmrdWnV+C1TW3fI2LukFBLPj8ejHNwTEvmInBGc8K95zLiCYZZwfJXTZ5bDVyLwbv94451dHfix8f9Y5bKvwZvJHWSlhZ6Tdyjh5OPfqvH9k4hO1qxIE032mEhzIT8JbPOZDJEOwP04R8Xjn2izTIEJgW4Y2L2jQ== myuser@myhost*

*That is not what is sent over the wire.* What is *actually* sent over the wire to the server is *awk '{print $2}' ~/.ssh/id_rsa.pub | base64 -d | xxd -ps -c 0*

On Wed, Sep 3, 2025 at 2:00 AM Tom Beecher <beecher@beecher.cc> wrote:

Brent-

Yes, you are correct about what is transmitted over the wire. Thank you. That being said, I believe it's still a distinction without a difference.

The only information stored on the router is the MD5 hash *of the base64 encoded public key*. Therefore when someone attempts to authenticate, the router *must* convert the presented mpint to base64, then take the md5sum of the result and compare to the config.

No, Tom; still wrong. See Dan Mahoney's Medium post <https://gushi.medium.com/what-i-learned-from-configuring-ssh-pubkey-auth-on-cisco-ios-cbeb1e5b3b77> . He uploads the key: switch(config)#username testcase privilege 15 switch(config)#ip ssh pubkey-chain switch(conf-ssh-pubkey)#username testcase switch(conf-ssh-pubkey-user)#key-string switch(conf-ssh-pubkey-data)#AAAAB3NzaC1yc2EAAAADAQABAAABgQDW switch(conf-ssh-pubkey-data)#45rLjxwnPeaZtu5h4PzvFaLqLIb1ozO+BAdDwqIY switch(conf-ssh-pubkey-data)#bbnqFnbhD42wZ6Cx2iQ3UKet4PziupgXLm2Yc69Q switch(conf-ssh-pubkey-data)#3HE6hP2Z23qHhemZG1G7O9liZ/+P40s2QLm2iRIm switch(conf-ssh-pubkey-data)#TZ4vsKoHNo51aQw+ZI+vUc+nKbZLFOzdZHuqhrw2 switch(conf-ssh-pubkey-data)#oG209csH3rVcBS3ItZuN2MP9+86Lr+64z4ls0Cqq switch(conf-ssh-pubkey-data)#MpBTZlgnxGtLfLW8ASASJm5Fh9onm60O2enBXsrP switch(conf-ssh-pubkey-data)#vC5ZKaLu0tecPC8hFwE7Bi7hAhpxzq1m8V3rdFlo switch(conf-ssh-pubkey-data)#8F05FXs1U89Ou4kgImAdwuW4YTUF15rfUSXR+hpM switch(conf-ssh-pubkey-data)#0c+HAf1KVLE+484zh00CJw1pvxLXTumacfjM0hdJ switch(conf-ssh-pubkey-data)#sRRoSru325hjKu+zhjUVlI20qt+K7Eb+qV62mDUn switch(conf-ssh-pubkey-data)#bsvIGfvFVAD0vCOqi3pASDxrrcGUHEU0zMAP8+mG switch(conf-ssh-pubkey-data)#6Ai7NZ+ilQs31NZcECubNDXh8xESyQI7w/r8xd5H switch(conf-ssh-pubkey-data)#CBfLE5VdssqZxflw832RQllS5p+d8sU= switch(conf-ssh-pubkey-data)#exit switch(conf-ssh-pubkey-user)#exit switch(conf-ssh-pubkey)#exit We can just copy and paste this right into a text file *t.txt* to prove this. So everyone at home can play along: $ file t.txt t.txt: ASCII text $ head -n1 t.txt switch(config)#username testcase privilege 15 $ b3sum t.txt b2caccb61dfd0d8bab4f864befbe6bc62d6bf376e44db2d118dd2e8e3589d6df t.txt $ head -n1 t.txt | xxd 00000000: 7377 6974 6368 2863 6f6e 6669 6729 2375 switch(config)#u 00000010: 7365 726e 616d 6520 7465 7374 6361 7365 sername testcase 00000020: 2070 7269 7669 6c65 6765 2031 350a privilege 15. $ tail -n1 t.txt | xxd 00000000: 7377 6974 6368 2863 6f6e 662d 7373 682d switch(conf-ssh- 00000010: 7075 626b 6579 2923 6578 6974 0a pubkey)#exit. No extra trailing whitespace, pasted just as-is, nothing up my sleeve. First let's remove the prompt prefixes since those obviously wouldn't be present in the actual uploaded form. $ sed -i -re 's/^.+#//g' t.txt You should now have: $ cat t.txt username testcase privilege 15 ip ssh pubkey-chain username testcase key-string AAAAB3NzaC1yc2EAAAADAQABAAABgQDW 45rLjxwnPeaZtu5h4PzvFaLqLIb1ozO+BAdDwqIY bbnqFnbhD42wZ6Cx2iQ3UKet4PziupgXLm2Yc69Q 3HE6hP2Z23qHhemZG1G7O9liZ/+P40s2QLm2iRIm TZ4vsKoHNo51aQw+ZI+vUc+nKbZLFOzdZHuqhrw2 oG209csH3rVcBS3ItZuN2MP9+86Lr+64z4ls0Cqq MpBTZlgnxGtLfLW8ASASJm5Fh9onm60O2enBXsrP vC5ZKaLu0tecPC8hFwE7Bi7hAhpxzq1m8V3rdFlo 8F05FXs1U89Ou4kgImAdwuW4YTUF15rfUSXR+hpM 0c+HAf1KVLE+484zh00CJw1pvxLXTumacfjM0hdJ sRRoSru325hjKu+zhjUVlI20qt+K7Eb+qV62mDUn bsvIGfvFVAD0vCOqi3pASDxrrcGUHEU0zMAP8+mG 6Ai7NZ+ilQs31NZcECubNDXh8xESyQI7w/r8xd5H CBfLE5VdssqZxflw832RQllS5p+d8sU= exit exit exit Let's of course get rid of the commands as well. Those aren't part of the base64 of the key. $ sed -i -e '19,21d' -e '1,4d' t.txt $ cat t.txt AAAAB3NzaC1yc2EAAAADAQABAAABgQDW 45rLjxwnPeaZtu5h4PzvFaLqLIb1ozO+BAdDwqIY bbnqFnbhD42wZ6Cx2iQ3UKet4PziupgXLm2Yc69Q 3HE6hP2Z23qHhemZG1G7O9liZ/+P40s2QLm2iRIm TZ4vsKoHNo51aQw+ZI+vUc+nKbZLFOzdZHuqhrw2 oG209csH3rVcBS3ItZuN2MP9+86Lr+64z4ls0Cqq MpBTZlgnxGtLfLW8ASASJm5Fh9onm60O2enBXsrP vC5ZKaLu0tecPC8hFwE7Bi7hAhpxzq1m8V3rdFlo 8F05FXs1U89Ou4kgImAdwuW4YTUF15rfUSXR+hpM 0c+HAf1KVLE+484zh00CJw1pvxLXTumacfjM0hdJ sRRoSru325hjKu+zhjUVlI20qt+K7Eb+qV62mDUn bsvIGfvFVAD0vCOqi3pASDxrrcGUHEU0zMAP8+mG 6Ai7NZ+ilQs31NZcECubNDXh8xESyQI7w/r8xd5H CBfLE5VdssqZxflw832RQllS5p+d8sU= Say, there we go! That's looking VERY base64-y! Now, we're looking for the MD5 sum *270C78AD8FB00FD98FEDF00C0E8F4D35* (or *270c78ad8fb00fd98fedf00c0e8f4d35,* same thing; hashes are binary, they're just usually represented in hex because it's a lot easier for human eyes than a lot of 0's and 1's). ip ssh pubkey-chain username testcase key-hash ssh-rsa 270C78AD8FB00FD98FEDF00C0E8F4D35 quit Let's make a standard GNU md5sum check file format. $ cat t.md5 270c78ad8fb00fd98fedf00c0e8f4d35 t.txt Ok! Let's check for that MD5! $ md5sum t.txt ea327a2f162f4ba8d6a9f1fff6f7cc0e t.txt Wow... That's really, really weird, Tom. You keep saying it stores the MD5 of the *base64 encoding* of the key, but that's a totally different checksum. Well, maybe it strips the newlines? $ cat t.txt | tr -d '\n' | md5sum bf91a39b8ff4ce69850dcd945f1319d5 - $ cat t.txt | tr -d '\n' > t.stripped ; mv t.stripped t.txt $ md5sum -c t.md5 t.txt: FAILED md5sum: WARNING: 1 computed checksum did NOT match Huh. No dice, Tom. Hey, you don't suppose it maybe... decodes the base64, and *stores the MD5 checksum of what the pubkey would look like on the wire*? (Sidenote, base64(1) is newline-agnostic when decoding; *cat t.txt | tr -d '\n' | base64 -d | b3sum* will return the same exact sum as *cat t.txt | base64 -d | b3sum*. Still no funny business, promise!) $ cat t.txt | base64 -d | md5sum 270c78ad8fb00fd98fedf00c0e8f4d35 - $ cat t.txt | base64 -d > t.bin ; mv t.bin t.txt $ md5sum -c t.md5 t.txt: OK Holy cats, Tom! Would ya look at that? It looks like it's *storing the MD5 sum of the actual real public key*, not the base64 encoded version! Who could have ever possibly guessed such a thing? $ cat t.txt | head -c 15 | xxd 00000000: 0000 0007 7373 682d 7273 6100 0000 03 ....ssh-rsa.... ]$ cat t.txt | head -c 15 | xxd -ps -c 0 000000077373682d72736100000003 Crazy! That DEFINITELY looks like the straight byte-packed over-the-wire form <https://sshref.dev/#bkdn_rsa_pub_struct>! Man, that's really weird, Tom. It's almost as if *IOS would what to keep the checksum of the actual bytes it'd be checking it against*, rather than *a base64-encoded version of the data it'd be checking it against*, so it wouldn't have to *base64-encode the bytes every time* they were sent during session establishment.

On Wed, Sep 3, 2025 at 9:39 AM Tom Beecher <beecher@beecher.cc> 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.

Tom- Preimage is not the only attack for MD5. It's a prerequisite if you are *only* sending exactly the attacker key on the wire. Merkle–Damgård checksum algorithms have quite a few fun options in this space if you aren't restricted with a fixed length.

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.

If you're going to be confident, don't be confidently wrong. Best of luck.

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

Dan- The main concern I have with your post, and the reason I have been so vocal in these messages , centers around the following : Or you might consider just going back to using inline passwords and

consider Cisco’s ssh implementation a failure at launch — at least the “secret” hashing algorithms are salted, but on older kit, it’s also still md5.

It's absolutely fair to criticize their implementation in its current form. I could see it making sense 20 years ago, but they've had time to iterate and improve on it, and should have. However, Cisco's implementation is not vulnerable to any currently known exploits, and no theoretical attack vectors don't seem to apply either. The fact that you make a recommendation for readers to *stop using public key SSH auth* because of that is , respectfully, absolutely irresponsible. Someone, somewhere is going to read this, and follow this advice, making their device LESS secure, and for no good reason. We don't tell people that current cryptography might eventually someday be vulnerable to quantum computers , so stop using cryptography completely. You are doing that here, by saying "This might be exploitable some day, so don't use it." Everything MIGHT be exploitable some day, that's how it goes. On Thu, Sep 4, 2025 at 6:01 AM Dan Mahoney via NANOG <nanog@lists.nanog.org> wrote:

...

On Sep 4, 2025, at 00:51, Saku Ytti via NANOG <nanog@lists.nanog.org> wrote:

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.

I had composed a long response here, but I think the tone of what I wrote in my blog speaks for itself, or I would have used different words, but at this point I don’t know if people have read the post, so I’ll rehash a bit.

The tone of my article was not “Holy crap, patch everything now”, it was “wow, that’s funny, they’re doing a thing that literally nobody else is doing that *theoretically* (regardless of what hash algo is used) increases the attack surface quite a lot, but it’s especially bad if yet another flaw is discovered in an algorithm that’s already had many flaws discovered (and those flaws were known as of the most recent releases of the OS for these devices). Why is nobody else doing what they’re doing? I wonder."

Good thing they give me the option of using another algorithm. Good thing that if I actually go to upload my full key, they keep it around, but give me the option of a hash for convenience. Good thing I’m not trusting my entire network to these devices. Good thing they make it easy to get patched software for without a service entitlement, and they also make it easy to get a service contract for a device I bought on the secondary market. (These are all false statements).

It’s not just about md5, it’s about many other corners that were cut by the same vendor, including the one that bit Randy, with their p0wn-by-default “smart install” feature.

-Dan _______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/RHX4K7NX...

Dan- I fully stand by my statements that you have : - Presented evidence of a poor design decision - Presented no evidence of a practical method of exploitation as a result of that design decision. - Provided a soft recommendation that people stop using public key SSH auth. The phrasing "you might consider" is absolutely a recommendation. It is a softer recommendation than "you must" or "you should" , but it is absolutely verbiage making a suggestion/recommendation that someone do or consider doing something. Even suggesting that people should "consider" removing publickey auth based on your post is irresponsible. This is especially true in the context of the back half of your posting , where you accurately call out that this isn't exploitable, then sow FUD about about the ways it MIGHT be. For the avoidance of doubt ,between the equals signs, quotation marks will only be used to signify a direct copy paste from your post. ========== After you explain your findings , you correctly start out with this : "It’s entirely possible I’m being alarmist: I’ve spoken to a few people knowledgeable in cryptography, and they tell me that this kind of preimage attack is still not feasible. While MD5 is showing weaknesses against large volumes of texts being able to be produced with the same hash (collision attacks — for example, changing a few characters in the text of a document the size of a novel and getting the same sum) we haven’t yet seen a feasible ability to generate text matching a very short known hash (especially when that hash needs to be of some very specifically-formatted prime numbers that happen to be a valid ssh pubkey)." Everything you said here is absolutely fair and correct. You correctly state that people knowledgeable on the subject have said that this isn't exploitable. However, everything you follow this up is maybe, could be, still might be a problem. "But, if I’m being alarmist, let me just say two words that bring it back. “Jia Tan”. Jia was the anonymous, generally-assumed-to-be-state-sponsored open-source contributor who slipped an exploit into the XZ compression utilities that would have ultimately allowed a master public-key into OpenSSH. It was a sophisticated attack." There is a universe of difference between someone social engineering an exploit into a codebase , and someone finding an algorithm/method to perform a mathematical computation that to date is considered not possible. Bringing this up in this way is very much a coded way of saying well this could happen, look here. "Again, I’m not a cryptanalyst, nor do I have IOS-XE source code to look over. I haven’t loaded this all in a debugger, or in Ghidra or whatever it is the reverse engineers do. I’ve typed some basic commands into my routers, and thrown some basic ssh commands against them, and I’m not liking what I see. At the end of the day, I’m just a simple country SysAdmin who’s seen people upload sloppy php code to their websites for 25 years, and I don’t like the way this makes my “gut” feel. I’ve seen things you people wouldn’t believe." Not liking what you see is understandable and a fair thing to say. But again this is coded language that to the reader implies there is a concern. "Even if Cisco had put out newer releases, they hide their IOS software behind a paywall, and their process for getting code for devices that are not under warranty is obnoxiously complex, but most of the devices on the secondary market are EOL or close to it, so there’s no fix coming for any of this." You again use fix here, implying this is MUSTFIX, when in reality it is SHOULDFIX. Again , after multiple paragraphs of maybe, might be, could still be a problem, you close with : "Or you might consider just going back to using inline passwords and consider Cisco’s ssh implementation a failure at launch — at least the “secret” hashing algorithms are salted, but on older kit, it’s also still md5. (Note: the NSA has a reasonable document about Cisco Password .ssh/config Algorithms) Heck, after discovering this, I am contemplating, strongly, just using a USB- to-serial-port concentrator with a unix box running rtty or conserver, and disabling all network configuration on my routers, and limiting any configuration to the console ports (but this does make using tools like RANCID way harder)."" Again I take the position that "you might consider" is a soft recommendation, but still a recommendation. Followed up with you are "contemplating, strongly" about doing that yourself is just reinforcing that. Elsewhere in your post, you make a demonstrably false comment. "Of course, what’s more scary here is, if you ssh to a lot of places (like, say, public looking glasses?), you’ve also uploaded that public key to lots of other places. Because chances are, uploading your public key is the default behavior. Even if you keep your private key encrypted. Imagine a darker world, where places with a modified sshd could have stored, and hashed it. With md5. 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." The bedrock principle of public key cryptography is that it is impossible to re-create a private key while only having the public key. This is not "mathematically hard" ; it is currently considered mathematically IMPOSSIBLE. And until such a time as a quantum computer can do it, it remains impossible. =========== On Thu, Sep 4, 2025 at 12:16 PM Dan Mahoney <danm@prime.gushi.org> wrote:

...

On Sep 4, 2025, at 05:21, Tom Beecher <beecher@beecher.cc> wrote:

Dan-

The main concern I have with your post, and the reason I have been so vocal in these messages , centers around the following :

Or you might consider just going back to using inline passwords and consider Cisco’s ssh implementation a failure at launch — at least the “secret” hashing algorithms are salted, but on older kit, it’s also still md5.

It's absolutely fair to criticize their implementation in its current form. I could see it making sense 20 years ago, but they've had time to iterate and improve on it, and should have.

However, Cisco's implementation is not vulnerable to any currently known exploits, and no theoretical attack vectors don't seem to apply either.

The fact that you make a recommendation for readers to *stop using public key SSH auth* because of that is , respectfully, absolutely irresponsible. Someone, somewhere is going to read this, and follow this advice, making their device LESS secure, and for no good reason. We don't tell people that current cryptography might eventually someday be vulnerable to quantum computers , so stop using cryptography completely. You are doing that here, by saying "This might be exploitable some day, so don't use it." Everything MIGHT be exploitable some day, that's how it goes.

Tom,

You see those things on either sides of the words “stop using public key SSH auth” ? Those are called quotation marks, and they mean, in this context, that you are directly citing my words, to the larger group.

Except that those words, in that order, appear nowhere in my article, which hasn’t changed at all, except for one typo which I’ve since corrected.

I make no such recommendation. My usage of the word “you might” is not a recommendation, it’s a statement that people may do their own research and carefully consider how they put an older device online, if at all. Where you’ve cited me bashing md5, I am referring to its crypt() implementation, also used in Cisco type 5 secrets, matching my recommendations with that of the NSA. If anything, I’ll happily suggest that the best answer for an EOL or near-EOL devices is “just use a serial cable”.

But back to your quote.

I believe that you’re seeing words that literally aren’t on the page, and are citing them to a public mailing list, claiming they’re mine.

This is not ok.

-Dan

On Sep 4, 2025, at 13:15, Gary Sparkes via NANOG <nanog@lists.nanog.org> wrote:

<snip?

4096 is still in the realm of geological or universe-scale timeframes for classical computing, however.

I still occasionally run into the misconception that, a, say, 2048-bit key is only twice to crack than a 1024-bit one, as opposed to 2^1024 times as hard. Exponents still escape the understanding of some people. (See also: IPv6 addressing) -Chris

===========

On Thu, Sep 4, 2025 at 12:16 PM Dan Mahoney <danm@prime.gushi.org <mailto:danm@prime.gushi.org>> wrote:

...

...

On Sep 4, 2025, at 05:21, Tom Beecher <beecher@beecher.cc> wrote:

Dan-

The main concern I have with your post, and the reason I have been so vocal in these messages , centers around the following :

Or you might consider just going back to using inline passwords and consider Cisco’s ssh implementation a failure at launch — at least the “secret” hashing algorithms are salted, but on older kit, it’s also still md5.

It's absolutely fair to criticize their implementation in its current form. I could see it making sense 20 years ago, but they've had time to iterate and improve on it, and should have.

However, Cisco's implementation is not vulnerable to any currently known exploits, and no theoretical attack vectors don't seem to apply either.

The fact that you make a recommendation for readers to *stop using public key SSH auth* because of that is , respectfully, absolutely irresponsible. Someone, somewhere is going to read this, and follow this advice, making their device LESS secure, and for no good reason. We don't tell people that current cryptography might eventually someday be vulnerable to quantum computers , so stop using cryptography completely. You are doing that here, by saying "This might be exploitable some day, so don't use it." Everything MIGHT be exploitable some day, that's how it goes.

Tom,

You see those things on either sides of the words “stop using public key SSH auth” ? Those are called quotation marks, and they mean, in this context, that you are directly citing my words, to the larger group.

Except that those words, in that order, appear nowhere in my article, which hasn’t changed at all, except for one typo which I’ve since corrected.

I make no such recommendation. My usage of the word “you might” is not a recommendation, it’s a statement that people may do their own research and carefully consider how they put an older device online, if at all. Where you’ve cited me bashing md5, I am referring to its crypt() implementation, also used in Cisco type 5 secrets, matching my recommendations with that of the NSA. If anything, I’ll happily suggest that the best answer for an EOL or near-EOL devices is “just use a serial cable”.

But back to your quote.

I believe that you’re seeing words that literally aren’t on the page, and are citing them to a public mailing list, claiming they’re mine.

This is not ok.

-Dan

_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/FRQXA3TF... _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/NCPG47PS...

I still moved to RSA-8192 bit keys over five years ago, and would have gone further but that's the largest some things support. For internal things where I can decide what to support, mostly 65536 and a few 131072 bit keys, because even quantum computers are going to have a rough ride with those :) Ginormous RSA keys are kind of even their own inherent proof-of-work if you want to have identities that are costly to make, without having to have any actual infrastructure to support them, it's not hard to choose a key size that represently at least a CPU-month or even a year worth of work. On Thu, Sep 4, 2025 at 5:15 PM Tom Beecher via NANOG <nanog@lists.nanog.org> wrote:

...

RSA-768 was successfully factored / private key derived from public key

in

...

2009. The highest successful one before RSA shut down the RSA factoring challenge.

Yes, impractical was the right word there, not impossible.

On Thu, Sep 4, 2025 at 4:15 PM Gary Sparkes <gary@kisaracorporation.com> wrote:

...

<snip>

...

The bedrock principle of public key cryptography is that it is impossible to re-create a private key while only having the public key. This is not "mathematically hard" ; it is currently considered mathematically IMPOSSIBLE. And until such a time as a quantum computer can do it, it remains impossible.

One issue here - It's possible, but computationally expensive. Exponentially more so as key size increases.

RSA-768 was successfully factored / private key derived from public key in 2009. The highest successful one before RSA shut down the RSA factoring challenge.

It's a matter of time/computer resources, not outright impossible. That was almost 16 years ago.

https://eprint.iacr.org/2010/006 &

https://arstechnica.com/information-technology/2010/01/768-bit-rsa-cracked-1...

...

Whereas time estimates scale up exponentially as key length increases, with classical computers it is a "solved" problem for this algorithm,

but a

...

computationally expensive one.

1024 should be feasible these days in a "reasonable" timeframe - the 2009 RSA-768 took approximately 2 years months of real-time processing across a sizable cluster (80 processors). We can obviously scale much further now.

4096 is still in the realm of geological or universe-scale timeframes for classical computing, however.

===========

On Thu, Sep 4, 2025 at 12:16 PM Dan Mahoney <danm@prime.gushi.org> wrote:

...

...

On Sep 4, 2025, at 05:21, Tom Beecher <beecher@beecher.cc> wrote:

Dan-

The main concern I have with your post, and the reason I have been so vocal in these messages , centers around the following :

Or you might consider just going back to using inline passwords and consider Cisco’s ssh implementation a failure at launch — at least the “secret” hashing algorithms are salted, but on older kit, it’s also still md5.

It's absolutely fair to criticize their implementation in its current form. I could see it making sense 20 years ago, but they've had time to iterate and improve on it, and should have.

However, Cisco's implementation is not vulnerable to any currently known exploits, and no theoretical attack vectors don't seem to apply either.

The fact that you make a recommendation for readers to *stop using public key SSH auth* because of that is , respectfully, absolutely irresponsible. Someone, somewhere is going to read this, and follow this advice, making their device LESS secure, and for no good reason. We don't tell people that current cryptography might eventually someday be vulnerable to quantum computers , so stop using cryptography

completely.

...

You are doing that here, by saying "This might be exploitable some day, so don't use it." Everything MIGHT be exploitable some day, that's how it goes.

Tom,

You see those things on either sides of the words “stop using public key SSH auth” ? Those are called quotation marks, and they mean, in this context, that you are directly citing my words, to the larger group.

Except that those words, in that order, appear nowhere in my article, which hasn’t changed at all, except for one typo which I’ve since corrected.

I make no such recommendation. My usage of the word “you might” is not a recommendation, it’s a statement that people may do their own research and carefully consider how they put an older device online, if at all. Where you’ve cited me bashing md5, I am referring to its crypt() implementation, also used in Cisco type 5 secrets, matching my recommendations with that of the NSA. If anything, I’ll happily suggest that the best answer for an EOL or near-EOL devices is “just use a serial cable”.

But back to your quote.

I believe that you’re seeing words that literally aren’t on the page, and are citing them to a public mailing list, claiming they’re mine.

This is not ok.

-Dan

_______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/FRQXA3TF...

...

_______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/7OVT6D7E...

https://crackstation.net/ - 190GB MD5 password hash rainbow table with 1.5 billion entries. If that's easily findable by Google, imagine what some of the APT groups might have.... On Sun, Aug 31, 2025 at 1:16 PM nanog--- via NANOG <nanog@lists.nanog.org> wrote:

There is currently no known way to generate a private key that would match your private key hash, faster than brute force, and MD5 still provides adequate protection against brute-force attacks.

While nobody should be designing new protocols using MD5 just because there is no reason to use a hash algorithm that has *any* known weaknesses, its known weaknesses are not relevant to this application.

A method is known to generate two pieces of data with the same MD5 hash. This isn't the same thing as saying that a method is known to generate a piece of data with any given MD5 hash, or the same MD5 hash as another piece of data.

...

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

On 31 August 2025 11:40:12 CEST, Dan Mahoney via NANOG < nanog@lists.nanog.org> wrote: 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... _______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/FNXYQDBG...

-- Thanks, Jimi

On Thu, Sep 4, 2025, 20:51 Jay Acuna via NANOG <nanog@lists.nanog.org> wrote:

On Thu, Sep 4, 2025 at 7:21 AM Tom Beecher via NANOG <nanog@lists.nanog.org> wrote:

...

However, Cisco's implementation is not vulnerable to any currently known exploits, and no theoretical attack vectors don't seem to apply either.

You mean not vulnerable to an exploit whose details are currently available to you. It is highly probable that known exploits to MD5 hashing exist which have much greater value to the finders not sharing the details than the practically nonexistent renumeration you'd get publishing.

This is precisely why I still avoid NIST curves where possible (favoring Edwards curves).

The MD5 hash has a history of being broken for a long period of time, and no longer used on modern systems requiring security, and is in a state where you could reasonably presume viable preimage attack methods have been worked out and are available to nefarious actors, but are also not going to be disclosed to the public and not going to be taken up as matters for academic research.

RFC 1186 (MD4) was published Oct. 1990. By 1991, severe weaknesses were published and several collisions found. By 1995, near-collisions could be generated in a flash. Later that year, a full revision attack had been found and published. In 2004, significant collision efficiencies were published (along with other algos in the family, including MD5). By 2007, complete collisions can be generated in 2 or less hash ops. In 2008, a 2^128 →2^102 preimage for MD4 was published. In 2010, a 2^128 →2^99.7 preimage for MD4 was published. In 1991, MD5 was designed. It was published as RFC 1321 in 1992. In 1993, pseudo-collisions were found. In 1996, the compression routine in MD5 was considered broken. It's about this time that recommendations to switch to SHA(-1) are made. 2004, MD5CRK demonstrates a working birthday attack accomplished within an hour on a p690 cluster. 2005, two x.509 certificates sharing the same hash with different public keys are published. (Improved collision construction methodology is released days after this that reduces it to a few hours on a laptop.) (A 2005 laptop, keep in mind.) 2006, collision finding can now be done within a minute on a laptop. 2010, a single-block (512B) MD5 collision is announced (but not published). 2012, the Flame malware uses a forged Microsoft code-signing certificate with MD5 collision against a valid one. 2013, colliding is down to 1/8th block (64B). As of today and public knowledge, collision finding is at 2^24.1 and with chosen-prefix, this is reduced to 2^39. 12 years is an awfully long time of silence, given MD5's much wider adoption (and still-current usage) over MD4. Humans often set weak passwords, or don't like using multiple passwords, and

Single sign-on solutions systemize the security hole. With password-based auth - your password is sent in plaintext to a SSH daemon. SSH defenses against adversary in the middle are weaker with password-based auth.

A small explicit clarification in case people are freaking out, password-based auth for SSH doesn't send the password in plaintext *over the wire*, KEX happens before auth and a shared secret key is used to encrypt the transport for the session before auth occurs. The *daemon*, however, does indeed receive the sent password, correct.

A reused password only has to be captured a single time by one rogue SSH daemon or one device on the network.

And for an extra fun time it has a username associated with it. This is daunting for those that use centralized auth in their org.

One of the best things you can do for authentication security is to eliminate passwords and use a crypto-based system. Passwords for SSH should have been deprecated and had support for them completely removed from all hardware a long time ago.

It's a hard line, but one I can stand behind. I also cannot stress the benefit of physical-token/FIDO2 MFA as well. It's easier than ever with OpenSSH 8.2p/8.3p (8.3p adds verify-required). Though net kit may be a fair bit away from this, and from my understanding IOS doesn't use OpenSSH (or a fork thereof) whatsoever - they have a 100% in-house-developed sshd.

On first login when setting up a new piece of hardware -- The hardware can be designed to only permit a password that one time, then generate and display an admin keypair to be imported into the SSH client, then require the admin of new equipment to log back in using that keypair before the keypair can be saved, and before it is made possible to finalize or save an initial device configuration and activate any services.

This is precisely what I set up for my org's jumpboxes/bastions. I'm sysops, not netops, though - so I have a significantly higher amount of flexibility in this particular context.