Live data from Hacker News

Why does SSH send 100 packets per keystroke?

eieio.games

241–250 of 375 posts

Re: Why does SSH send 100 packets per keystroke?

#241
post #213

Wow, I did not realize that SSH did that. Good to know, and it makes sense as a default, because the people who need it need to have it on by default. But I think I'm going to be turning that off, because it's a security measure that doesn't make sense for my particular environment: 1) I'm pretty much never typing secrets into an SSH tunnel; these days if there's a secret I need to transmit over SSH I'm going to be c…

> I'm pretty much never typing secrets into an SSH tunnel; these days if there's a secret I need to transmit over SSH I'm going to be copying and pasting it, which will not reveal info from keyboard timing

One common secret that goes through a tty ssh connection is a sudo password. You are probably typing sudo command so without obfuscation the attacker can find out the sudo keystrokes, the command keystrokes and then the encrypted bytes of the password. They don't have the timing data to decode them as easily as the previous parts but if they record enough traffic they might be able to decrypt the password. But maybe they won't, because the ssh session key is probably different each time. Furthermore I don't know how many times they should capture your encrypted password to be able to decrypt it. Maybe it's unfeasible.

Anyway, in case of the sudo password, if the attacker gets it what would happen? The attacker is hopefully not able to get a shell into the server. If they do they have different ways to get root privileges.

By the way, I also copy and paste secrets from either the password manager or the clipboard, because nobody remembers long random strings. The only exceptions are the passwords of a few accounts.

Re: Why does SSH send 100 packets per keystroke?

#242

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…

Same year, I tried this cool new "Mosaic" software and thought it was a cool proof of concept, but there was no way this web thing could ever displace gopher

Which was right, today gopher has more users than ever! :)

Re: Why does SSH send 100 packets per keystroke?

#243

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.

Can you explain how TCP_CORK helps here? The chaff packets are spaced 20ms apart and sent per socket, so I don’t see how TCP_CORK could help unless it coalesced across 20ms intervals? But coalescing is clearly not an option for the intended obfuscation effect of the original feature.

It is unrelated to SSH, it is a generic TCP thing.

"hello world" fits in a single TCP packet, but the kernel might end up sending one packet containing "hello" and another packet containing " world". It is completely opaque to userspace.

TCP_CORK lets userspace decide when packets are dispatched. You get to control whether "hello world" is sent across 1 packet or 11 packets.

Re: Why does SSH send 100 packets per keystroke?

#244
post #213

Wow, I did not realize that SSH did that. Good to know, and it makes sense as a default, because the people who need it need to have it on by default. But I think I'm going to be turning that off, because it's a security measure that doesn't make sense for my particular environment: 1) I'm pretty much never typing secrets into an SSH tunnel; these days if there's a secret I need to transmit over SSH I'm going to be c…

I think those all have reasonable counterarguments: (1) This sounds brittle. Are you really going to have a good mental model about what's secret when using ssh and reliably refrain from typing those things? Seems to kinda defeat the idea of securing the channel. Also, as a collection your activities might be more confidential to you than single inputs, or correlated with your other activities outside ssh, etc - it's…

Bandwidth is not the problem when you are using mobile connections (4G, weaker 5G). Videos work just fine, but ssh can be painful already without keystroke obfuscation. The problem is latency. Especially when roaming abroad it can 100s of ms.

Not sure whether the obfuscation is fully synchronous, i.e waiting for the server response before continuing. That would really kill it. Working with LTS distros I don't think I have seen it in practice yet. Need to try something modern on my next trip abroad.

Re: Why does SSH send 100 packets per keystroke?

#246
post #213

Wow, I did not realize that SSH did that. Good to know, and it makes sense as a default, because the people who need it need to have it on by default. But I think I'm going to be turning that off, because it's a security measure that doesn't make sense for my particular environment: 1) I'm pretty much never typing secrets into an SSH tunnel; these days if there's a secret I need to transmit over SSH I'm going to be c…

> I'm pretty much never typing secrets into an SSH tunnel; these days if there's a secret I need to transmit over SSH I'm going to be copying and pasting it, which will not reveal info from keyboard timing One common secret that goes through a tty ssh connection is a sudo password. You are probably typing sudo command so without obfuscation the attacker can find out the sudo keystrokes, the command keystrokes and the…

sudo passwords are one of the things I'm copying and pasting from the password manager, because my shell account password is different on every system. But yes, if you type your sudo password without thinking about it, the timing attack might be feasible. (Though if you're laboriously copying a random password from a different screen, as I've had to do once or twice in situations where copy-and-paste was infeasible, the timing data will be useless as it's about 500 ms between keystrokes no matter what the previous keystroke is. Which is an interesting way to accidentally defeat this attack.)

Re: Why does SSH send 100 packets per keystroke?

#248

Earlier quoted context omitted.

PoiZoN BBS Sysop chiming in. I ran the BBS on a free phone line I found in my childhood bedroom. I alerted the phone company and a tech spent a day trying to untangle it, but gave up at the end of his shift. He even stopped by to tell me it wouldn’t be fixed. I didn’t know the phone number, so I bought a Caller ID box, hooked it to my home line, and phoned home. It wasn’t long before every BBS in town had a listing f…

Man that tech was cool and did you a solid.

Many techs went to work for the phone companies for a reason.

Re: Why does SSH send 100 packets per keystroke?

#249

Earlier quoted context omitted.

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…

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

Re: Why does SSH send 100 packets per keystroke?

#250
post #198

Earlier quoted context omitted.

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

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 services on that machine.

Post reply on HN