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