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

31–40 of 375 posts

Re: Why does SSH send 100 packets per keystroke?

#31

Post by jcynix »

lloydatkinson wrote: post #5
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"

smoking gun, you're absolutely right, good question, em dash, "it isn't just foo, it's also bar", real honest truth, brutal truth, underscores the issue, delves into, more em dashes, . It's nauseating.

It's what they read on The Internets when training, so don't expect them to generate new phrases, other than what they learned from it?

Re: Why does SSH send 100 packets per keystroke?

#33

Post by ycombinatrix »

svnt wrote: post #25

> I am working on a high-performance game that runs over ssh. Found your problem. But it is an interesting world where you can casually burrow into a crypto library and disable important security features more easily than selecting the right network layer solution.

Yea UDP is technically more performant, but then you need a crypto layer + reliable message delivery layer + bespoke client. Using a plain old SSH client is cool.

However, there are existing libraries for exactly this use case - see https://github.com/ValveSoftware/GameNetworkingSockets

I guess QUIC libraries would also work.

Re: Why does SSH send 100 packets per keystroke?

#34

Post by eieio »

svnt wrote: post #25

> I am working on a high-performance game that runs over ssh. Found your problem. But it is an interesting world where you can casually burrow into a crypto library and disable important security features more easily than selecting the right network layer solution.

the obtuseness is the point! This is true of a lot of my work[1][2][3].

The problems you run into when doing things you shouldn't do are often really fun.

[1] https://news.ycombinator.com/item?id=42342382

[2] https://news.ycombinator.com/item?id=37810144

[3] https://news.ycombinator.com/item?id=42674116

Re: Why does SSH send 100 packets per keystroke?

#36

Post by convolvatron »

ycombinatrix wrote: post #33
svnt wrote: post #25

> I am working on a high-performance game that runs over ssh. Found your problem. But it is an interesting world where you can casually burrow into a crypto library and disable important security features more easily than selecting the right network layer solution.

Yea UDP is technically more performant, but then you need a crypto layer + reliable message delivery layer + bespoke client. Using a plain old SSH client is cool. However, there are existing libraries for exactly this use case - see https://github.com/ValveSoftware/GameNetworkingSockets I guess QUIC libraries would also work.

its not really a question of 'udp performs better'. in tcp we have to live to head-of-line blocking on losses and congestion control. if you don't care about receiving every packet, but only the most recent, then udp is a good choice.

running without congestion control means that you avoid slowstart. but at a certain rate you run into poorly defined 'fairness' issues where you can easily negatively impact other flows. past that point, you can actually self-interfere and cause excessive losses for yourself.

quic uses congestion control, but uses latency estimates and variance as a signal to back off. it still imposes an ordering on a per-stream basis. so it might not be ideal either.

sctp has a mode which supports reliable and unordered, which might be something to consider

so really - if you care about latency and have a different reliability model, its worth unpacking all these considerations and using them to select your transport layer or even consider writing a minimal one yourself

Re: Why does SSH send 100 packets per keystroke?

#37

Post by PaulHoule »

I find it disturbing.

One thing you notice if you have ADSL is that some services are built as if slower connections matter and others are not. Like Google's voice and audio chat services work poorly but most of the others work well. Uploading images to Mastodon, Bluesky, Facebook, LinkedIn, Instagram and Nextdoor is reliable, but for Tumblr you have to try it twice. I don't what they are doing wrong but they are doing something wrong and not finding out what they're doing wrong because they're not testing and they're not listening to users.

Nobody consulted me about their decision not to run fiber by my house. If some committee decides to make ssh bloated they are, together with the others, conspiring to steal my livelihood and I think it would be fair for me to sue them for the $50k it would take to run that fiber myself.

It's OK if you work for Google where there is limitless dark fiber but what about people in African countries?

It's the typical corporate attitude where latency never matters: Adobe thinks it is totally normal that it takes 1-5s for a keystroke to appear when you are typing into Dreamweaver.

Re: Why does SSH send 100 packets per keystroke?

#38

Post by grim_io »

gf000 wrote: post #30
eieio wrote: post #20

Earlier quoted context omitted.

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.

Reminds me of ethimology nerd's videos. He has some content about how LLMs will influence human language.

The "maybe" of yesterday is the "you're absolutely right!" of tomorrow.

Re: Why does SSH send 100 packets per keystroke?

#39

Post by ycombinatrix »

convolvatron wrote: post #36
ycombinatrix wrote: post #33

Earlier quoted context omitted.

Yea UDP is technically more performant, but then you need a crypto layer + reliable message delivery layer + bespoke client. Using a plain old SSH client is cool. However, there are existing libraries for exactly this use case - see https://github.com/ValveSoftware/GameNetworkingSockets I guess QUIC libraries would also work.

its not really a question of 'udp performs better'. in tcp we have to live to head-of-line blocking on losses and congestion control. if you don't care about receiving every packet, but only the most recent, then udp is a good choice. running without congestion control means that you avoid slowstart. but at a certain rate you run into poorly defined 'fairness' issues where you can easily negatively impact other flows…

>in tcp we have to live to head-of-line blocking on losses and congestion control.

Is this not a performance consideration?

Either way, using plain old SSH means a metric bajillion computers have a client for your game built in.

Re: Why does SSH send 100 packets per keystroke?

#40

Post by advisedwang »

dathinab wrote: post #10

> Keystroke obfuscation can be disabled client-side. please never do that (in production) if anyone half way serious tries they _will_ be able to break you encryption end find what you typed this isn't a hypothetical niche case obfuscation mechanism, it's a people broke SSH then a fix was found case. I don't even know why you can disable it tbh.

That doesn't sound right to me. This obfuscation isn't about a side-channel on a crypto implementation, this is about literally when your keystrokes happen. In the right circumstances, keystroke timing can reduce the search space for bruteforcing a password [1] but it's overstating to describe that as broken encryption.

[1] https://people.eecs.berkeley.edu/~daw/papers/ssh-use01.pdf

Post reply on HN