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

111–120 of 375 posts

Re: Why does SSH send 100 packets per keystroke?

#111

Post by mystraline »

omoikane wrote: post #107
Animats wrote: post #84

In 2023, ssh added keystroke timing obfuscation. The idea is that the speed at which you type different letters betrays some information about which letters you’re typing. So ssh sends lots of “chaff” packets along with your keystrokes to make it hard for an attacker to determine when you’re actually entering keys. Now that's solving the problem the wrong way. If you really want that, send all typed characters at 50m…

> send all typed characters at 50ms intervals Wouldn't this just change the packet interval from 20ms to 50ms? Or did you mean a constant stream of packets at 50ms intervals, nonstop? I think the idea behind the current implementation is that the keystrokes are batched in 20ms intervals, with the optimization that a sufficiently long silence stops the chaff stream, so the keystroke timing is obfucated with an increas…

[flagged]

Re: Why does SSH send 100 packets per keystroke?

#112

Post by danudey »

JohnLeitch wrote: post #93

The reliance on LLMs is unfortunate. I bet this mystery could gave been solved much quicker by simply looking at the packet capture in Wireshark. The Wireshark dissectors are quite mature, SSH is covered fairly well.

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 200 'Client: encrypted packet' and 'Server: encrypted packet' entries. Nothing useful there at all. If I tcpdump the entire SSH connection setup from scratch I get just as much useful information - nothing - but, oddly, fewer packets than my one keystroke triggered.

So yeah, I dislike LLMs entirely and dislike the reliance on LLMs that we see today, but in this case the author learned a lot of interesting stuff and shared it with us, whereas without LLMs he might have just shrugged and moved on.

Re: Why does SSH send 100 packets per keystroke?

#113

Post by MaxBarraclough »

jcynix wrote: post #31
lloydatkinson wrote: post #5

Earlier quoted context omitted.

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?

That's the point though, it doesn't reflect human usage of the word. If delve were so commonly used by humans too, we wouldn't be discussing how it's overused by LLMs.

Re: Why does SSH send 100 packets per keystroke?

#114

Post by flumpcakes »

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

Re: Why does SSH send 100 packets per keystroke?

#115

Post by shadowgovt »

benlivengood wrote: post #79
shadowgovt wrote: post #28

Earlier quoted context omitted.

But they'd have to be on the same network as me to do that attack, right?

Yep, like ECHELON and friends are. The metadata recorded about your (all of our) traffic is probably enough to perform the timing attack.

Hey, if ECHELON snuck a listener into my house, where six devices hang out on a local router... Good for them, they're welcome to my TODO lists and vast collection of public-domain 1950s informational videos.

(I wouldn't recommend switching the option off for anything that could transit the Internet or be on a LAN with untrusted devices. I am one of those old sods who doesn't believe in the max-paranoia setting for things like "my own house," especially since if I dial that knob all the way up the point is moot; they've already compromised every individual device at the max-knob setting, so a timing attack on my SSH packet speed is a waste of effort).

Re: Why does SSH send 100 packets per keystroke?

#116

Post by danudey »

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.

Haven't heard of TCP_CORK, very interesting.

For people who don't feel like googling it:

1. You TCP_CORK a socket

2. You put data into it and the kernel buffers it

3. If you uncork the socket, or if the buffer hits MSS, the kernel sends the packet

Basically, the kernel waits until it has a full packet worth of data, or until you say you don't have any more data to send, and then it sends. Sort of an extreme TCP_YESDELAY.

See https://catonmat.net/tcp-cork for where I learned it all from.

Re: Why does SSH send 100 packets per keystroke?

#117

Post by mystraline »

danudey wrote: post #112
JohnLeitch wrote: post #93

The reliance on LLMs is unfortunate. I bet this mystery could gave been solved much quicker by simply looking at the packet capture in Wireshark. The Wireshark dissectors are quite mature, SSH is covered fairly well.

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 break SSL, and invalidate validation of the ssl.

Yes, Esri products suck. Bad.

Re: Why does SSH send 100 packets per keystroke?

#118

Post by geocar »

jacquesm wrote: post #74
eikenberry wrote: post #41

Earlier quoted context omitted.

+1... Given how much SSH is used for computer-to-computer communication it seems like there really should be a way to disable this when it isn't necessary.

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.

Re: Why does SSH send 100 packets per keystroke?

#119

Post by frotaur »

mystraline wrote: post #111
omoikane wrote: post #107

Earlier quoted context omitted.

> send all typed characters at 50ms intervals Wouldn't this just change the packet interval from 20ms to 50ms? Or did you mean a constant stream of packets at 50ms intervals, nonstop? I think the idea behind the current implementation is that the keystrokes are batched in 20ms intervals, with the optimization that a sufficiently long silence stops the chaff stream, so the keystroke timing is obfucated with an increas…

[flagged]

The problem is not knowing whether someone is typing, as far as I understand. But that you may extract some information about what keys are being typed, based on the small differences in timings between them.

Re: Why does SSH send 100 packets per keystroke?

#120

Post by davidhyde »

WesolyKubeczek wrote: post #100
davidhyde wrote: post #92

I wonder if this is the same reason why Microsoft's Remote SSH plugin on VS Code is so flaky even with a decent internet connection. Every couple of months I try to give it another go and give up due to the poor keyboard latency I inevitably experience. And the slow reconnects whenever I glance away from my computer monitor briefly. This is on a fiber connection with a 20ms ping to the remote machine.

You surely mean the latency in its embedded terminal and not the code editor, right? I use VSCode’s remote SSH specifically so that code editing doesn’t suck. It really does not.

You're right, the latency is in the embedded terminal. Perhaps it is trying to run SSH inside SSH. Still, the disconnects are a pain too.
Post reply on HN