New Subsystem criteria for Match option block in OpenSSH server

[John Olsson M]

> Setup a ControlMaster,  start a shell connection to the server,
> then start a sftp connection reusing that control.  If you set
> anything like "don't allow forward, etc"  now forward is disabled
> for the shell and for sftp.   This isn't logical behavior that
> someone would expect unless they understood the ssh protocol. 

I agree. :(

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.

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

AllowAgentForwarding
AllowTcpForwarding 
GatewayPorts
MaxSessions
PermitOpen
X11DisplayOffset
X11Forwarding
X11UseLocalHost

which still leavs the following keywords to be allowed

Banner
ChrootDirectory
ForceCommand
GSSAPIAuthentication
HostbasedAuthentication
KbdInteractiveAuthentication
KerberosAuthentication
KerberosUseKuserok
MaxAuthTries
PubkeyAuthentication
AuthorizedKeysCommand
AuthorizedKeysCommandRunAs
PasswordAuthentication
PermitEmptyPasswords
PermitRootLogin
RhostsRSAAuthentication
RSAAuthentication


Any more that are not sane to allow when matching on subsystem?


/John

-----Original Message-----
From: openssh-unix-dev-bounces+john.m.olsson=ericsson.com at mindrot.org [mailto:openssh-unix-dev-bounces+john.m.olsson=ericsson.com at mindrot.org] On Behalf Of Ben Lindstrom
Sent: den 23 maj 2012 17:06
To: Nicola Muto
Cc: openssh-unix-dev at mindrot.org openssh
Subject: Re: New Subsystem criteria for Match option block in OpenSSH server


On May 23, 2012, at 8:31 AM, Nicola Muto wrote:

> Ok Darren, you confirmed my doubts about adding Match-Subsystem option 
> to sshd, most of all for the ChrootDirectory+PrivilegeSeparation
> problem.
> 
> Now I have a question. What's that sounds bad, the implementation of 
> the patch or the Match-Subsystem idea itself?
> In other words. Is it possible to solve all of these issues providing 
> another implementation? Am I doing something wrong or forgetting something?
> 
> If so, a new implementation should be not so simple and have heavy 
> impacts on the source. Moreover, I think that the Peter's issue can't 
> be solved by whatever implementation is proposed. Am I right?

I'm not sure any patch would be acceptable.  The heart of the issue is simple:

Setup a ControlMaster,  start a shell connection to the server,  then start a sftp connection reusing that control.  If you set anything like "don't allow
forward, etc"  now forward is disabled for the shell and for sftp.   This isn't
logical behavior that someone would expect unless they understood the ssh protocol.

So unless you limit the protocol so you can only setup a single session type (subsystem, shell, etc) per connection then I can't see how this is a sane feature for admins to wrap their heads around.

- Ben
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev