Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why does SSH send 100 packets per keystroke?

eieio.games

Post reply on HN
Print view View original

191–200 of 375 posts

Re: Why does SSH send 100 packets per keystroke?

#191

Post by OhMeadhbh »

nomel wrote: post #180
geocar wrote: post #118

Earlier quoted context omitted.

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?

Because TCP interprets packet loss as congestion and slows down. If you're already on a slow, lossy wireless link, bandwidth can rapidly fall below the usability threshold. After decades of DARPA attending IETF meetings to find solutions for this exact problem [turns out there were a lot of V4 connections over microwave links in Iraq] there are somewhat standard ways of setting options on sockets to tell the OS to consider packet loss as packet loss and to avoid slowing down as quickly. But you have to know what these options are, and I'm pretty sure the OP's requirement of having `ssh foo.com` just work be complicated by TCP implementations defaulting to the "packet loss means congestion" behavior. Hmm... now that I think about it, I'm not even sure if the control plane options were integrated into the Linux kernel (or Mac or Wintel)

Life is difficult sometimes.

Re: Why does SSH send 100 packets per keystroke?

#192

Post by reincarnate0x14 »

CaptainNegative wrote: post #186
reincarnate0x14 wrote: post #157

Earlier quoted context omitted.

It sort of already is. This behavior is only applied to sessions with a TTY and then the client can disable it, which is a sensible default. This specific use case is tripping it up obviously since the server knows ahead of time that the connection is not important enough to obfuscate and this isn't a typical terminal session, but in almost any other scenario there is no way to make that determination and the client…

What's a concrete threat model here? If you're sending data to an ssh server, you already need to trust that it's handling your input responsibly. What's the scenario where it's fine that the client doesn't know if the server is using pastebin for backing up session dumps, but it's problematic that the server tells the client that it's not accepting a certain timing obfuscation technique?

The behavior exists to prevent a 3rd party from inferring keystrokes from active terminal sessions, which is surprisingly easy, particularly with knowledge about the user's typing speed, keyboard type, etc. The old CIA TEMPEST stuff used to make good guesses at keystrokes from the timing of AC power circuit draws for typewriters and real terminals. Someone with a laser and a nearby window can measure the vibrations in the glass from the sound of a keyboard. The problem is real and has been an OPSEC sort of consideration for a long time.

The client and server themselves obviously know the contents of the communications anyway, but the client option (and default behavior) expects this protection against someone that can capture network traffic in between. If there was some server side option they'd probably also want to include some sort of warning message that the option was requested but not honored, etc.

Re: Why does SSH send 100 packets per keystroke?

#193

Post by jabwd »

eieio wrote: post #20
snowmobile wrote: post #2

> That 20ms is a smoking gun - it lines up perfectly with the mysterious pattern we saw earlier! Speaking of smoking guns, anybody else reckon Claude overuses that term a lot? Seems anytime I give it some debugging question, it'll claim some random thing like a version number or whatever, is a "smoking gun"

Yes! While this post was written entirely by me, I wouldn't be surprised if I had "smoking gun" ready to go because I spent so much time debugging with Claude last night.

Serious question though, since AI seems to be so all capable and intelligent. Why wouldn't it be able to tell you the exact reason that I could tell you just by reading the title of this post on HN? It is failing even at the one thing it could probably do decently, is being a search engine.

Re: Why does SSH send 100 packets per keystroke?

#194

Post by Jedd »

drzaiusx11 wrote: post #188
gerdesj wrote: post #178

Earlier quoted context omitted.

"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…

Fellow old here, I had several 56k baud modems but even my USR (the best of the bunch) never got more than half way to 56k throughput. Took forever to download shit over BBS...

> several 56k baud modems

These were almost definitely 8k baud.

Re: Why does SSH send 100 packets per keystroke?

#195

Post by quesera »

gerdesj wrote: post #178
swiftcoder wrote: post #11

> 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…

> I've used links with modems rocking 1200 bps

Yo, 300 baud, checking in.

Do I hear 110?

+++ATH0

Re: Why does SSH send 100 packets per keystroke?

#196

Post by direwolf20 »

nomel wrote: post #180
geocar wrote: post #118

Earlier quoted context omitted.

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?

It will time out before your packet gets through, or it will retransmit faster than the link can send packets.

Re: Why does SSH send 100 packets per keystroke?

#197

Post by OhMeadhbh »

Or you could use anycasting to terminate SSH sessions on the moral equivalent of one of a number of geography based reverse proxies and then forward the packet over an internal network to the app server over a link tuned for low latency. The big guys already do something similar with HTTP over TLS for DDoS protection and to limit end to end latency on TLS.

Granted... it would increase the cost (since you're adding reverse proxies) but it would be a quick way to get acceptable latency, rudimentary DDoS protection, and you could try different connection options independent of the main app's logic.

It would be hard to estimate how much latency you're adding with a SSH2 reverse proxy in this case, but it's probably lower than one might think.

The idea of letting Claude loose on my crypto[graphy] implementation is about the most frightening thing I've heard of in a while [though libnss is so craptastic, I can't see how it would hurt in that case.] But I loved this write-up. It was readable and explained the problem the OP was encountering and proposed solutions well.

Re: Why does SSH send 100 packets per keystroke?

#198

Post by fwip »

otabdeveloper4 wrote: post #128
mystraline wrote: post #109

Earlier quoted context omitted.

[flagged]

Those same security guys also think that "just hope that no bad guy ever gets root access, lol" is a valid threat model analysis, so whatever.

When the question is "how do I communicate securely with a third party," there's nothing you can do if the third party in question gets possessed by a demon and turns evil. (Which is what happens if an attacker has root.)

Re: Why does SSH send 100 packets per keystroke?

#199

Post by bitwize »

flumpcakes wrote: post #114

I don't see how Claude helped the debugging at all. It seemed like the author knew what to do and it was more telling Claude to think about that. I've used Claude a bit and it never speaks to me like that either, "Holy Cow!" etc. It sounds more annoying than interacting with real people. Perhaps AIs are good at sensing personalities from input text and doesn't act this way with my terse prompts..

It's like I keep saying, it probably wasn't a good idea to give our development tools Genuine People Personalities...

Re: Why does SSH send 100 packets per keystroke?

#200

Post by quesera »

stephenr wrote: post #185
supern0va wrote: post #156

Earlier quoted context omitted.

I assure you that if you rubber duck at another engineer that doesn't understand what you're doing, you will also be pummeled with information that may or may not be relevant. ;)

That isn't rubber duck debugging. It's just talking to someone about the problem. The entire point of rubber duck debugging is that the other side literally cannot respond - it's an inanimate object, or even a literal duck/animal.

Oh it can definitely be a person. I've worked with a few!
Post reply on HN