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

311–320 of 375 posts

Re: Why does SSH send 100 packets per keystroke?

#311

Post by cestith »

mgiampapa wrote: post #262
beagle3 wrote: post #239

Earlier quoted context omitted.

The real analog copper lines were kind of limited to approx 28K - more or less the nyquist limit. However, the lines at the time were increasingly replaced with digital 64Kbit lines that sampled the analog tone. So, the 56k standard aligned itself to the actual sample times, and that allowed it to reach a 56k bps rate (some time/error tolerance still eats away at your bandwidth) If you never got more than 24-28k, you…

56k was also unidirectional, you had to have special hardware on the other side to send at 56k downstream. The upstream was 33.6kbps I think, and that was in ideal conditions.

The special hardware was actually just a DSP at the ISP end. The big difference was before 56k modems, we had multiple analog lines coming into the ISP. We had to upgrade to digital service (DS1 or ISDN PRI) and break out the 64k digital channels to separate DSPs.

The economical way to do that was integrated RAS systems like the Livingston Portmaster, Cisco 5x00 seriers, or Ascend Max. Those would take the aggregated digital line, break out the channels, hold multiple DSPs on multiple boards, and have an Ethernet (or sometimes another DS1 or DS3 for more direct uplink) with all those parts communicating inside the same chassis. In theory, though, you could break out the line in one piece of hardware and then have a bunch of firmware modems.

Re: Why does SSH send 100 packets per keystroke?

#312

Post by dspillett »

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

* 56k baud modems but even my USR (the best of the bunch) never got more than half way to 56k throughput*

56k modem standards were asymmetric, the upload rate being half that of the download. In my experience (UK based, calling UK ISPs) 42kbps was usually what I saw, though 46 or even 48k was stable¹ for a while sometimes.

But 42k down was 21k up, so if I was planning to upload anything much I'd set my modem to pretend it as a 36k6 unit: that was more stable and up to that speed things were symmetric (so I got 36k6 up as well as down, better than 24k/23k/21k). I could reliably get a 36k6 link, and it would generally stay up as long as I needed it to.

--------

[1] sometimes a 48k link would last many minutes then die randomly, forcing my modem to hold back to 42k resulted in much more stable connections

Re: Why does SSH send 100 packets per keystroke?

#313

Post by [deleted] »

otabdeveloper4 wrote: post #250
fwip wrote: post #198

Earlier quoted context omitted.

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.)

Incorrect. Random sysadmins who have access to your server have the permissions to steal whatever is communicated between third parties unrelated to this sysadmin. Just because some random outsourced nightshift dude has the permissions to do "sudo systemctl restart" shouldn't mean he gets to read all the secret credentials the service uses. As it is now, the dude has full unfettered access to all credentials of all s…

[deleted]

Re: Why does SSH send 100 packets per keystroke?

#314

Post by dspillett »

mgiampapa wrote: post #262
beagle3 wrote: post #239

Earlier quoted context omitted.

The real analog copper lines were kind of limited to approx 28K - more or less the nyquist limit. However, the lines at the time were increasingly replaced with digital 64Kbit lines that sampled the analog tone. So, the 56k standard aligned itself to the actual sample times, and that allowed it to reach a 56k bps rate (some time/error tolerance still eats away at your bandwidth) If you never got more than 24-28k, you…

56k was also unidirectional, you had to have special hardware on the other side to send at 56k downstream. The upstream was 33.6kbps I think, and that was in ideal conditions.

The asymmetry of 56k standards was 2:1, so if you got a 56k6 link (the best you could get in theory IIRC) your upload rate would be ~28k3. In my expereience the best you would get in real world use was ~48k (so 48kbpd down, 24kbps up), and 42k (so 21k up) was the most I could guarantee would be stable (baring in mind “unstable” meant the link might completely drop randomly, not that there would be a blip here-or-there and all would be well again PDQ afterwards) for a significant length of time.

To get 33k6 up (or even just 28k8 - some ISPs had banks of modems that supported one the 56k6 standards but would not support more than 28k8 symmetric) you needed to force your modem to connect using the older symmetric standards.

Re: Why does SSH send 100 packets per keystroke?

#315

Post by NewJazz »

fc417fc802 wrote: post #287
stephenr wrote: post #185

Earlier quoted context omitted.

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.

I don't think that's right. When you explain a technical problem to someone who isn't intimately familiar with it you're forced to think through the individual steps in quite a bit of detail. Of course that itself is an acquired skill but never mind that. The point or rubber duck debugging then is to realize the benefit of verbally describing the problem without needing to interrupt your colleague and waste his time…

To that end a notepad works just as well.

Re: Why does SSH send 100 packets per keystroke?

#316

Post by dspillett »

AceJohnny2 wrote: post #130
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..

Even if the chatbot served only as a Rubber Ducky [1], that's already valuable. I've used Claude for debugging system behavior, and I kind of agree with the author. While Claude isn't always directly helpful (hallucinations remain, or at least outdated information), it helps me 1) spell out my understanding of the system (see [1]) and 2) help me keep momentum by supplying tasks. [1] https://en.wikipedia.org/wiki/Rubb…

> Even if the chatbot served only as a Rubber Ducky [1], that's already valuable.

I use the Other Voices for that. I can't entirely turn them off, I might as well make use of them!

Re: Why does SSH send 100 packets per keystroke?

#317

Post by dspillett »

fc417fc802 wrote: post #287
stephenr wrote: post #185

Earlier quoted context omitted.

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.

I don't think that's right. When you explain a technical problem to someone who isn't intimately familiar with it you're forced to think through the individual steps in quite a bit of detail. Of course that itself is an acquired skill but never mind that. The point or rubber duck debugging then is to realize the benefit of verbally describing the problem without needing to interrupt your colleague and waste his time…

> When you explain a technical problem to someone who isn't intimately familiar with it you're forced to think through the individual steps in quite a bit of detail.

The point of Rubber Ducking (or talking/praying to the Wooden Indian, to use an older phrase that is steeped in somewhat racist undertones so no longer generally used) is that it is an inanimate object that doesn't talk back. You still talk to it as if you were explaining to another person, so are forcing yourself to get your thoughts in order in a way that would make that possible, but actually talking to another person who is actively listening and actually asking questions is the next level.

Re: Why does SSH send 100 packets per keystroke?

#318

Post by tgma »

Lerc wrote: post #295
Sebb767 wrote: post #290

Earlier quoted context omitted.

Each of our devices spents a lot of energy dedicated to encryption. By now, all disks you did not set up manually are most likely encrypted and hardly any unencrypted package will travel out of your network. That's not to mention the tons of load and dedicated hardware we have just to terminate https and scan traffic for suspicious activity or the hardware being replaced because it's internal security triggered/broke…

That's the judgement made with all consumption of energy. The benefits weighed against the costs. Because of the harms of environmental change, there should be pressure placed to avoid damaging ways to generate that energy. When people complain about the amount of energy being used, they are making the judgement on the benefits. This is subjective and people do not agree on the benefits. The argument you shouldn't do…

Producing cheap energy is something everyone should be able to get behind. There is a solid consensus that it would make a better world.

See what I did there? As long as you preach any ideology of yours without talking about its trade-offs you can claim everyone should get behind it. Obviously.

Re: Why does SSH send 100 packets per keystroke?

#319

Post by KAMSPioneer »

otabdeveloper4 wrote: post #249
anonymous908213 wrote: post #153

Earlier quoted context omitted.

That is a completely valid threat model analysis, though? "Just hope no bad guy ever gets into the safe" is rather the entire point of a safe. If you have a safe, in which you use the contents of the safe daily, does it make sense to lock everything inside the safe in 100 smaller safes in some kind of nesting doll scheme? Whatever marginal increase in security you might get by doing so is invalidated by the fact that…

> That is a completely valid threat model analysis, though? No it isn't. Here in 2026 timesharing accounts aren't a thing anymore and literally everyone who ever logs into your server has root access. "Just make sure all those outsourced sysadmins working for a contractor you've never met are never bad guys" is not a valid security threat model.

> literally everyone

Perhaps figuratively? I manage several servers where the majority of (LDAP) accounts have no special privileges at all. They get their data in the directories and can launch processes as their user, that's...pretty much it.

Though the upstream comment is gone and I am perhaps missing some important context here.

Re: Why does SSH send 100 packets per keystroke?

#320

Post by Nauxuron »

mystraline wrote: post #117
danudey wrote: post #112

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…

This really does not need to be that hard. For TLS, many tools support setting the SSLKEYLOGFILE environment variable to log the session keys used in connections. Wireshark can import those to decrypt everything. [1]

Unfortunately, nothing exists for SSH (yet?). [2]

I do agree that if you design a protocol that enforces encryption, you should include some debugging interface. It is much more straightforward to do this by logging the session secrets on the endpoints rather than trying to break it through a man-in-the-middle, the main thing the protocol is protecting you against.

[1]: https://wiki.wireshark.org/TLS

[2]: https://gitlab.com/wireshark/wireshark/-/issues/16054

Post reply on HN