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