It is to prevent timing attacks but there are many ssh use cases where it is 100% computer to computer communications where there is no key based timing attack possible.

▲

OneDeuxTriSeiGo 5 hours ago | parent | next [-]

There is an argument that if:

- you are listening to an SSH session between devices

- and you know what protocol is being talked over the connection (i.e. what they are talking about)

- and the protocol is reasonably predictable

then you gain enough information about the plaintext to start extracting information about the cipher and keys.

It's a non-trivial attack by all means but it's totally feasible. Especially if there's some amount of observable state about the participants being leaked by a third party source (i.e. other services hosted by the participants involved in the same protocol).

	▲	Romario77 5 hours ago \| parent \| next [-]
		this only works for manually typed text, not computer to computer communication where you can't deduce much from what is being "typed" as it's not typed but produced by a program to which every letter is the same and there is no different delay in sending some letters (as people have when typing by hand)
	▲	eikenberry 5 hours ago \| parent \| prev \| next [-]
		I agree it is more nuanced than a simple 'good for computer-to-computer' and 'bad for person-to-computer'. I'm sure there are cases where both are wrong but I don't think that necessarily changes that it makes a reasonable baseline heuristic.
	▲	Mystery-Machine 3 hours ago \| parent \| prev [-]
		I'd love to hear more about this kind of attack being exploited in the wild. I understand it's theoretically possible, but...good luck! :) You're guessing a cipher key by guessing typed characters with the only information being number of packets sent and the time they were sent at. Good luck. :)

▲

PhilipRoman 5 hours ago | parent | prev [-]

I haven't given this more than 5 seconds of thought, but wouldn't it make sense to only enable the timing attack prevention for pseudo-terminal sessions (-t)?