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

151–160 of 375 posts

Re: Why does SSH send 100 packets per keystroke?

#151

Post by NewJazz »

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…

A rubber ducky demands that you think about your own questions, rather than taking a mental back seat as you get pummeled with information that may or may not be relevant.

Re: Why does SSH send 100 packets per keystroke?

#152

Post by joshstrange »

eieio wrote: post #13
ycombinatrix wrote: post #3

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.

Oh wow - I've never heard of TCP_CORK before. Without disabling pings I'd still pay the cost of receiving way more packets, but maybe that'd be tolerable if I didn't have to send so many pongs. This is super handy; excited to play around with it. I am aware of TCP_NODELAY (funny enough I recently posted about TCP_NODELAY to HN[1] when I was thinking about it for the same game that I wrote about here). But I think the…

I missed that thread originally, the post and the comments where a good read, thank you for sharing.

I got a kick out of this comment [0]. "BenjiWiebe" made a comment about the SSH packets you stumbled across in that thread. Obviously making the connection between what you were seeing in your game and this random off-hand comment would be insane (if you had seen the comment at all), but I got a smile out of it.

[0] https://news.ycombinator.com/item?id=46366291

Re: Why does SSH send 100 packets per keystroke?

#153

Post by anonymous908213 »

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.

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 you lose all utility of being able to use the things in the safe, and we already know that overburdensome security is counterproductive because if something is so secure that it becomes impossible to use, those security measures just get bypassed completely in the name of using the thing. At some level of security you have to have the freedom to use the thing you're securing. Anything that could keep a bad guy from doing anything ever would also keep the good guy, ie. you, from doing anything ever.

Re: Why does SSH send 100 packets per keystroke?

#154

Post by eieio »

joshstrange wrote: post #152
eieio wrote: post #13

Earlier quoted context omitted.

Oh wow - I've never heard of TCP_CORK before. Without disabling pings I'd still pay the cost of receiving way more packets, but maybe that'd be tolerable if I didn't have to send so many pongs. This is super handy; excited to play around with it. I am aware of TCP_NODELAY (funny enough I recently posted about TCP_NODELAY to HN[1] when I was thinking about it for the same game that I wrote about here). But I think the…

I missed that thread originally, the post and the comments where a good read, thank you for sharing. I got a kick out of this comment [0]. "BenjiWiebe" made a comment about the SSH packets you stumbled across in that thread. Obviously making the connection between what you were seeing in your game and this random off-hand comment would be insane (if you had seen the comment at all), but I got a smile out of it. [0] h…

wow, I missed that comment, that's an incredible connection. Thank you!

Re: Why does SSH send 100 packets per keystroke?

#155

Post by dsrtslnd23 »

geocar wrote: post #118
jacquesm wrote: post #74

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.

In aerial robotics, 900MHz telemetry links (like Microhard) are standard. And running SSH over them is common practice I guess.

Re: Why does SSH send 100 packets per keystroke?

#156

Post by supern0va »

NewJazz wrote: post #151
AceJohnny2 wrote: post #130

Earlier quoted context omitted.

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…

A rubber ducky demands that you think about your own questions, rather than taking a mental back seat as you get pummeled with information that may or may not be relevant.

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

Re: Why does SSH send 100 packets per keystroke?

#157

Post by reincarnate0x14 »

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

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 expects its ObscureKeystrokeTiming to be honored.

Re: Why does SSH send 100 packets per keystroke?

#158

Post by advisedwang »

Mystery-Machine wrote: post #143
advisedwang wrote: post #40

Earlier quoted context omitted.

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

THANK YOU! I'm baffled about this "security feature". Besides from this only being relevant to timing keystrokes during the SSH session, not while typing the SSH password, I really don't understand how can someone eavesdrop on this? They'd have to have access to the client or server shell (root?) in order to be able to get the keystrokes typing speed. I've also never heard of keystroke typing speed hacking/guessing k…

Anyone who can spy on the network between the client and server can see the timing. This includes basically anyone on the same LAN as you, anyone who sets up a WiFi access point with a SSID you auto-connect to, anyone at your ISP or VPN provider, the NSA and god knows who else.

And the timing is still sensitive. [1] does suggest that it can be used to significantly narrow the possible passwords you have, which could lead to a compromise. Not only that, but timing can be sensitive in other ways --- it can lead to de-anonymization by correlating with other events, it can lead to profiling of what kind of activity you are doing over ssh.

So this does solve a potentially sensitive issue, it's just nuanced and not a complete security break.

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

Re: Why does SSH send 100 packets per keystroke?

#159

Post by supern0va »

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…

It seems like a leap to suggest we shouldn't have widely deployed encryption...rather than just fix the debugging tools.

Particularly in today's political climate, encryption has only become more necessary.

Post reply on HN