161–170 of 375 posts
The reliance on LLMs is unfortunate. I bet this mystery could gave been solved much quicker by simply looking at the packet capture in Wireshark. The Wireshark dissectors are quite mature, SSH is covered fairly well.
Way to gatekeep. God forbid people use tools to help them investigate instead of knowing the exact approach to take.
Earlier quoted context omitted.
> Telnet nowadays typically isn’t available by default for security reasons And with good reason. This CVE is from yesterday : https://nvd.nist.gov/vuln/detail/CVE-2026-24061 > telnetd in GNU Inetutils through 2.7 allows remote authentication bypass via a "-f root" value for the USER environment variable.
Telnetd is the server though, and OP wouldn’t be using that.
In 2023, ssh added keystroke timing obfuscation. The idea is that the speed at which you type different letters betrays some information about which letters you’re typing. So ssh sends lots of “chaff” packets along with your keystrokes to make it hard for an attacker to determine when you’re actually entering keys. Now that's solving the problem the wrong way. If you really want that, send all typed characters at 50m…
> send all typed characters at 50ms intervals Wouldn't this just change the packet interval from 20ms to 50ms? Or did you mean a constant stream of packets at 50ms intervals, nonstop? I think the idea behind the current implementation is that the keystrokes are batched in 20ms intervals, with the optimization that a sufficiently long silence stops the chaff stream, so the keystroke timing is obfucated with an increas…
So a clock doesn't solve the problem. The amount of data sent on each clock pulse also tells you something about what was sent.
The Chaff packets already fire on a timer. They inject random extra fake keystrokes so you can't tell how many keystrokes were actually made. The only other way I can think of to solve that is by using a step function: Send one larger packet (fragmented or the same number of individual packets) on each clock pulse if the actual data is less than some N where N is the maximum keystrokes ever recorded with some margin. Effectively almost every clock pulse will be one packet (or set of packets) of identical size. Of course if you do that then you'll end up consuming more data over time than sending random amounts of packets.
Well, security is the #1 consideration for SSH, but if the author doesn't need security, why use ssh? For example, "nc" (netcat) is pre-installed on all platforms where ssh is.
This is technically incorrect, because Windows now includes SSH too!
Earlier quoted context omitted.
Well, I spent a good part of my career reverse engineering network protocols for the purpose of developing exploits against closed source software, so I'm pretty sure I could do this quickly. Not that it matters unless you're going to pay me.
So you are basically overqualified to tell other people how to do it, especially with the payment part.
Earlier quoted context omitted.
I'm anti-LLM in most cases, but: > I bet this mystery could gave been solved much quicker by simply looking at the packet capture in Wireshark. For some people who are used to using Wireshark and who know what to look for, probably yes. For the vast majority of even technical people, probably not. In my case, I did a packet capture of a single keystroke using tcpdump and imported it into Wireshark and I get just over…
And thats a huge downside when people howl about "Encryption everywhere! ". Try debugging that shit. Thats right, debugging interfaces aren't safe, by some wellakshually security goon. You want a real fun one to debug, is a SAML login to a webapp, with internal Oauth passthrough between multiple servers. Sure, I can decrypt client-server stuff with tools, but server-server is damn near impossible. The tools that work…
Having to MITM a connection to snoop it is annoying, but the alternative appears to be still using unencrypted protocols from the 1970s within the limitations of a 6502 to operate life-safety equipment.
Earlier quoted context omitted.
AIs are exceptional at sensing personalities from text. Claude nailed it here, the author felt so good about the "holy cow" comments that he even included them in the blog post. I'm not just poking this, but saying that the bots are fantastic sycophants.
No they aren't. Current LLMs always have that annoying over-eager tone. The comment about Claude being pumped was a joke.
Well, security is the #1 consideration for SSH, but if the author doesn't need security, why use ssh? For example, "nc" (netcat) is pre-installed on all platforms where ssh is.
There are two issues with it:
- a primary is not a totality: if "security is the #1 consideration for SSH", that implies there's a #2, maybe even a #3 and so on consideration. So the question that follows becomes tautological: "but if the author doesn't need security, why use ssh?" -> surely for one or more of the #2, #3, etc. considerations, right?
- overabstraction (*): you ended up strawmanning the author. What they had issue with was keystroke timing obfuscation, which is a privacy feature. Timing attacks are (in part) a privacy concern, and privacy is a security concern, yes, but security is not just privacy concern, and privacy concerns are not just about timing attacks; these groups are not equal. For example, they might very well want the transmitted keypresses themselves to remain confidential, or they might very well want to retain cryptographic assurance of their integrity. These are security features they can continue to utilize by sticking with SSH.
All of this is to say, it's not even necessarily them using SSH for a hypothetical #2 or #3 (...etc...) reason, but likely because they still very much want to make use of large chunks of #1, which disabling keypress obfuscation does not actually rid SSH of, only at most weakens it in ways they clearly seem to be okay with.
(*) although if I zoom out enough, this is once again just "a primary is not a totality", just implicitly