Worth noting too, that other linux systems using 8.9, e.g. ubuntu are 8.9p1 and have the patch applied but to an older version so they're also safe. Just in case anyone was worried about that.

This seems like a reasonable solution to me, and I often stream music through my ssh sessions via port forwards so I may well already be getting the benefit in some places

This and a similar suggestion in another thread may sound nice and easy, "just add a constant stream of noise", but it assumes you can generate enough constant noise and be able to intersperse the noise with valid commands without being able to distinguish these events. The problem is not necessarily that you want to hide (to a network adversary) that you've been typing. It's that you do not want to reveal, through some side-channel, what the exact contents were.

On the openssh-unix-dev mailing list, someone recently pointed out[0] that just periodically (without jitter) sending out packets may be problematic due to subtle differences in clock timing. Aside, they also link to a presentation[1] [PDF] that shows influence of temperature on clock skew (especially page 18) and that this gives a possibility for fingerprinting.

Then there's the challenge of keeping SSH interactive enough that people do not experience too much input lag while typing. What if the user typed a character, but due to such a timing side-channel preventive measure, that character needs to be sent in the next packet, adding latency to the user experience? Surely it improves security, but it may add too much frustration for regular usage.

[0] https://marc.info/?l=openssh-unix-dev&m=169402700622936&w=2 [1] https://murdoch.is/talks/ccs06hotornot.pdf ([2006] Hot or Not: Revealing hidden services by their clock skew, see also https://doi.org/10.1145/1180405.1180410 and an HN thread from 2014: https://news.ycombinator.com/item?id=7694612)

I think it's worth asking how important the feature is in the grand scheme of things. But what about the CIA timing my keystrokes is more of a nerd forum thing than an actual attack vector you read about in intrusion post mortems.

The implementation is just wrong from what's been presented. basic jitter (20-100ms), and a dynamic payload size are what's actually missing here. The question now becomes though how interactive should your session be. Timing the connection latency might help to an extent, but this is about mitm and you don't necessarily know where your adversary is (first hop, or towards the end). Batching keystrokes would also help here.

> trying to hide a signal in random noise doesn't really work

Actually it works perfectly and it's called a one-time pad!

The advantage that OpenSSH have here is that they don't have to just hide the signal using noise, they can actually change the signal to look like the noise (or vice versa). For example they are making the signal packets some at a regular interval (since the "signal" being discussed is the timings). That alone would not hide the number of keypresses, but adding the chaff should do so.

In this case, as said above, it seems like there's an implementation issue with actually doing those obfuscations, allowing the signal to be identified.

Sounds good until (for example) you find out the SSH client library wasn't queueing up packets ahead of time, but instead building them at send time, and a chaff packet takes less time to build than a real packet... so many ways to get side-channeled.

Does nothing here.