can compression be safely used with SSH?

Damien Miller djm at mindrot.org
Mon Nov 24 09:47:23 EST 2014


On Sat, 22 Nov 2014, Philippe Cerfon wrote:

> Hello.
> 
> >Even if delayed compression is only activated after authentication,
> >the the fact that delayed compression will be used has already been
> >negotiated before authentication and can't be changed retroactively.
> 
> Couldn't the server simply abort a connection in the case that it sees
> that the negotiated compression algorithm doesn't fit, once the user
> is determined?
> Bailing out with some error message, before the client could have done anything.
> 
> This is perhaps not the cleanest way, but in practise it should do
> quite well, and the same could possibly be done to allow many others
> of directives to be used inside Match, for which this is currently
> impossible.

Killing the connection if the client suggests the wrong option is
quite hostile to the user. I don't think we'd want that.

It's theoretically possible to force a rekeying after authentication
with new options, but this is slow: several client/server round-trips
plus the potentially very slow key exchange crypto. IMO it's too slow
and confusing to be worth implementing.

> One could for example restrict certain authentication methods (or
> their options) to certain users/groups.

OpenSSH has supported this for years; see the documentation for 'Match'
in sshd_config(5).

-d


More information about the openssh-unix-dev mailing list