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
> 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.Would it be difficult to implement? I guess it's the only clean way then to restrict compression to certain users (if killing the connection isn't an option). And the slowness would probably not really matter, since it's only necessary to work like that, when being used in a Match section, which most people will never do. Shall I open a wishlist ticket about that? Thanks, Philippe
On Sun, 30 Nov 2014, Philippe Cerfon wrote:> > 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. > > Would it be difficult to implement? I guess it's the only clean way > then to restrict compression to certain users (if killing the > connection isn't an option). > And the slowness would probably not really matter, since it's only > necessary to work like that, when being used in a Match section, which > most people will never do. > > Shall I open a wishlist ticket about that?Sure, if you like. As I said though, I don't plan on working on it but someone else might think it worthwhile. -d