Live data from Hacker News

Why does SSH send 100 packets per keystroke?

eieio.games

171–180 of 375 posts

Re: Why does SSH send 100 packets per keystroke?

#171

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.

ChatGPT set to "terse and professional" personality mode is refreshingly sparse on the "you're absolutely right" bullshit

Re: Why does SSH send 100 packets per keystroke?

#172

Earlier quoted context omitted.

So you are basically overqualified to tell other people how to do it, especially with the payment part.

What are you even trying to say? I suppose I'll clarify for you: Yes, I'm confident I could have identified the cause of the mysterious packets quickly. No, I'm not going to go through the motions because I have no particular inclination toward the work outside of banter on the internet. And what's more, it would be contrived since the answer has already shared.

I think the point they're making is that "I, a seasoned network security and red-team-type person, could have done this in Wireshark without AI assistance" is neither surprising nor interesting.

That'd be like saying "I, an emergency room doctor, do not need AI assistance to interpret an EKG"

Consider that your expertise is atypical.

Re: Why does SSH send 100 packets per keystroke?

#174

You can also use TCP_CORK to reduce the number of packets without any increased latency. Disabling TCP_NODELAY would also reduce number of packets + be portable & simpler to implement - but would incur a latency penalty.

Can you explain how TCP_CORK helps here? The chaff packets are spaced 20ms apart and sent per socket, so I don’t see how TCP_CORK could help unless it coalesced across 20ms intervals? But coalescing is clearly not an option for the intended obfuscation effect of the original feature.

Re: Why does SSH send 100 packets per keystroke?

#175

Earlier quoted context omitted.

Asking an LLM about SSH (hint: the two S-es stand for security) would tell you why only having packet capture in Wireshark isn't going to reveal shit.

Not even remotely accurate. While the dissector is not as mature as I thought and there's no built-in decryption as there is for TLS, that doesn't matter much. Hint: every component of the system is attacker controlled in this scenario.

> Not even remotely accurate.

> there's no built-in decryption

Is that because wireshark can't do that just from packet captures?

Re: Why does SSH send 100 packets per keystroke?

#176

Very interesting, I hadn't heard of this obfuscation before so it was well worth clicking. Another good trick for debugging ssh's exact behavior is patching in "None" cipher support for your test environment. It's about the same work as trying to set up a proxy but lets you see the raw content of the packets like it was telnet. For terminal games where security does not matter but performance and scale does, just off…

It made the front page when it was added. https://news.ycombinator.com/item?id=37307708

Not everyone sees the HN frontpage every day, and sometimes especially-esoteric things spend a fairly short timespan on there.

Re: Why does SSH send 100 packets per keystroke?

#177

Earlier quoted context omitted.

Asking an LLM about SSH (hint: the two S-es stand for security) would tell you why only having packet capture in Wireshark isn't going to reveal shit.

Wireshark can decrypt it, so I don't understand what you mean?

Not from packet captures, it can't.

Re: Why does SSH send 100 packets per keystroke?

#178

> Obviously forking go’s crypto library is a little scary, and I’m gonna have to do some thinking about how to maintain my little patch in a safe way This should really be upstreamed as an option on the ssh library. Its good to default to sending chaff in untrusted environments, but there are plenty of places where we might as well save the bandwidth

"where we might as well save the bandwidth"

I come from a world (yesteryear) where a computer had 1KB of RAM (ZX80). I've used links with modems rocking 1200 bps (1200 bits per second). I recall US Robotics modems getting to speeds of 56K - well that was mostly a fib worse than MS doing QA these days. Ooh I could chat with some bloke from Novell on Compuserve.

In 1994ish I was asked to look into this fancy new world wide web thing on the internet. I was working at a UK military college as an IT bod, I was 24. I had a Windows 3.1 PC. I telnetted into a local VAX, then onto the X25 PAD. I used JANET to get to somewhere in the US (NIST) and from there to Switzerland to where this www thing started off. I was using telnet and WAIS and Gopher and then I was apparently using something called "www".

I described this www thing as "a bit wank", which shows what a visionary I am!

Re: Why does SSH send 100 packets per keystroke?

#179
post #118

Earlier quoted context omitted.

In practice I've never felt this was an issue. But I can see how with extremely low bandwidth devices it might be, for instance LoRa over a 40 km link into some embedded device.

Hah no. Nobody is running TCP on that link, let alone SSH.

Once upon a time I worked on a project where we SSH'd into a satellite for debugging and updates via your standard electronics hobbiest-tier 915mhz radio. Performance was not great but it worked and was cheap.

Re: Why does SSH send 100 packets per keystroke?

#180
post #118

Earlier quoted context omitted.

In practice I've never felt this was an issue. But I can see how with extremely low bandwidth devices it might be, for instance LoRa over a 40 km link into some embedded device.

Hah no. Nobody is running TCP on that link, let alone SSH.

what's wrong with tcp, on a crappy link, when guaranteed delivery is required? wasn't it invented when slow crappy links were the norm?
Post reply on HN