Live data from Hacker News

Why does SSH send 100 packets per keystroke?

eieio.games

321–330 of 375 posts

Re: Why does SSH send 100 packets per keystroke?

#321
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…

I guess if your org usually gives the keys to the castle to random idiots, then yeah, I can see why you'd wish the master key didn't exist.

Re: Why does SSH send 100 packets per keystroke?

#322

Earlier quoted context omitted.

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 y…

I guess I can see where others are coming from (the LLM is different than a literal rubber duck) but I feel like the "can't reply" part was never more than an incidental consequence. To me the "why" of it was always that I need to solve my problem and I don't want to disturb my colleagues (or am unable to contact anyone in the first place for some reason).

So where others see "rubber ducking" as explaining to an object that is incapable of response, I've always seen it as explaining something without turning to others who are steeped in the problem. For example I would consider explaining something to a nontechnical friend to qualify as rubber ducking. The "WTF" interjections definitely make it more effective (the rubber duck consistently fails to notify me if I leave out key details).

Re: Why does SSH send 100 packets per keystroke?

#323

Earlier quoted context omitted.

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.

In reality vim is my usual approach. But I think LLMs are better in a lot of regards.

Re: Why does SSH send 100 packets per keystroke?

#324

The 2023 timing obfuscation is a nice case study in security defaults vs edge cases. Most SSH users won't notice 100 packets per keystroke - it's noise in the bandwidth budget. But for high-frequency terminal apps, it becomes the dominant cost. At 2000 concurrent players updating 80x60 chars at 10fps, a custom protocol might be the right answer regardless of obfuscation settings.

Just think of the trees burnt in the name of security!

I can think of a few things that burn more energy per second that I'll burn in my entire lifetime via the use of encryption.

Coincidentally, they're all, somehow, insanely useless.

Re: Why does SSH send 100 packets per keystroke?

#325

Earlier quoted context omitted.

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 prete…

Even then, it required specialized hardware on the ISP side to connect above 33.6kbps at all, and almost never reliably so. I remember telling most of my friends just to get/stick with the 33.6k options. Especially considering the overhead a lot of those higher modems took, most of which were "winmodems" that used a fair amount of CPU overhead insstead of an actual COM/Serial port. It was kind of wild.

Re: Why does SSH send 100 packets per keystroke?

#326

Earlier quoted context omitted.

Yeah 28k sounds more closer to what I got when things were going well. I also forget if they were tracking in lower case 'k' (x1000) or upper case 'K' (x1024) units/s which obviously has an effect as well.

The lower case "k" vs upper case "K" is an abomination. The official notation is lower case "k" for 1000 and lower case "ki" for 1024. It's an abomination too, but it's the correct abomination.

That's a newer representation, mostly because storage companies always (mis)represented their storage... I don't think any ISPs really misrepresent k/K in kilo bits/bytes

Re: Why does SSH send 100 packets per keystroke?

#327

Earlier quoted context omitted.

There's a good chance you have other options. Regardless of how you feel about the company's head, Starlink would probably be one of them, with likely better performance than you're dealing with on ADSL. But you cannot just sue a company because their network connected software doesn't work well on slow networks. Let alone a project like OpenSSH. It would be like me suing a game studio because my PC doesn't meet thei…

Hey, it is one thing to buy a new computer, it is another thing to ask people to move. A better analogy is a bank redlining neighborhoods. The cost to run fiber to difficult rural locations pays itself easily if you look at a 25-year time span and is an order of magnitude less than building a new housing unit on the West Coast.

> another thing to ask people to move.

One half of my comment was actually about how you most likely have a better performing alternative option right where you already live. And even if you didn't, they're not asking you to move. You could argue they're not even asking you to use their software, you're electing to.

Re: Why does SSH send 100 packets per keystroke?

#328

> 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's not just the pointless chaff, the SSH protocol is inherently very chatty, and SFTP even more so. The solution, for a high-performance game, is don't use SSH . Either run it over Wireguard or grab some standard crypto library and encrypt the packets yourself. You'll probably make a few minor mistakes but unless the other player is the NSA it'll be good enough. For that matter, why does it need to be encrypted at…

Serious question, why not just use websockets? AFAIK, it's effectively a TLS socket with a little bit of handshake overhead when starting.

I'm literally working on a web interface I want to use for classic BBS door play... currently working on a DOS era EGA interface, and intend to do similar for PETSCII/Comodore64/128 play as well. I've got a couple rendering bugs to explore for ansis submitted that messed up in the viewer test mode.

https://github.com/bbs-land/webterm-dos-ansi

It's been an opportunity to play with AI dev as well... spent as much time getting the scrollback working how I want as it took on the general rendering.

Re: Why does SSH send 100 packets per keystroke?

#329

Earlier quoted context omitted.

Just think of the trees burnt in the name of security!

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…

> In a perfect world, we could send all traffic completely unencrypted and never scan for a malicious payload, saving all that energy and hardware.

In a world with such social cohesion, we'd be defeated by an alien species being able to quickly interpret and exploit our technology like in the hit film Independence Day(note, we're the defeating alien species in this example). https://www.youtube.com/watch?v=9DIjBGierkA

Re: Why does SSH send 100 packets per keystroke?

#330

Very interesting, I hadn't heard of this obfuscation before so it was well worth clicking. Another good trick for debugging ssh's exact behavior is patching in "None" cipher support for your test environment. It's about the same work as trying to set up a proxy but lets you see the raw content of the packets like it was telnet. For terminal games where security does not matter but performance and scale does, just off…

Sadly, much fewer computer systems have telnet nowadays. Also, port 21 is often blocked.

23 (21 is ftp)
Post reply on HN