New Subsystem criteria for Match option block in OpenSSH server

[Peter Stuge]

John Olsson M wrote:
> Don't you have the same problem with fopr instance other match statements?

None of the currently supported ones.


> What happens if you have
> 
> ...
> AllowTcpForwarding yes
> ...
> Match User foo
>   AllowTcpForwarding no
> 
> Wouldn't this cause the same behavior?

It doesn't. Please read the SSH architecture RFC 4251. It's short.

http://ftp.sunet.se/pub/Internet-documents/rfc/rfc4251.txt

TCP forwarding is implemented through an SSH channel. SSH channels
can only ever be created after authentication, so it makes sense to
be able to limit what type of channels are allowed given the
information available to sshd after authentication.


> That once user foo logs on TCP forwarding is denied?

No, TCP forwarding channels are denied in all foo's sessions.


> What is it that makes the subsystem so magical that it suddenly
> affects the whole server?

The subsystem is only one of any number of channels that may be
opened in a single SSH session. Please see RFC 4251.


John Olsson M wrote:
> Would it be sane to add additional restrictions on which keywords
> can follow a "Match Subsystem" construct? I think so and it would
> be intuitive to do so as well.

Sure, not all keywords make sense.


> I guess the following set of keywords should not be allowed when
> matching on subsystem

Matching on subsystem should only be able to change things affecting
that single subsystem. Since a subsystem per definition has no
definition; it is simply an authenticated and encrypted 8-bit-clean
bidirectional channel, it's not really possible for sshd to know what
the subsystem will do. Indeed there exists only one subsystem which
sshd even knows about, by default; sftp. For sftp it does indeed make
sense to consider a chroot, as well as the other options that
sftp-server accepts on the command line. See sftp-server(8).


> which still leavs the following keywords to be allowed
> 
> Banner

The banner is no longer relevant at the time of subsystems.


> ChrootDirectory
> ForceCommand

These two are the only ones that possibly have meaning when matching
on subsystem.


> GSSAPIAuthentication
> HostbasedAuthentication
> KbdInteractiveAuthentication
> KerberosAuthentication
> KerberosUseKuserok
> MaxAuthTries
> PubkeyAuthentication
> AuthorizedKeysCommand
> AuthorizedKeysCommandRunAs
> PasswordAuthentication
> PermitEmptyPasswords
> PermitRootLogin
> RhostsRSAAuthentication
> RSAAuthentication

The above are all about authentication which is no longer relevant
at the time of subsystems. Please read RFC 4251 so that you see how
the SSH protocol actually works and by extension how you can find
solutions that will both work for you and benefit others. Thanks!


//Peter