Match Group sftponly ChrootDirectory /cust/ftp/secure/%u X11Forwarding no AllowTcpForwarding no ForceCommand internal-sftp -l INFO Match Address *,!10.* Group *,!sftponly ForceCommand echo 'External shell access denied.' These two lines succeed at: 1) when connections are attempted by users in 'sftponly', they're limited to SFTP via internal-sftp successfully. 2) when connections are attempted from external locations, and the account is NOT in 'sftponly' group, they're blocked. Except when the number of users in the sftponly account reaches 127 users. At this point after successfully authenticating, the connection is ended with the error code 255 from the server. I have setup a local workaround, but splitting the group, duplicating match group for new group and tweaking the match address config: Match Group sftponly ChrootDirectory /cust/ftp/secure/%u X11Forwarding no AllowTcpForwarding no ForceCommand internal-sftp -l INFO Match Group sftponly2 ChrootDirectory /cust/ftp/secure/%u X11Forwarding no AllowTcpForwarding no ForceCommand internal-sftp -l INFO Match Address *,!10.* Group *,!sftponly* ForceCommand echo 'External shell access denied.' As long as no new members are added to the group that has 126 users in it already, then all is well. It would be best to not have to deal with a limit of 126 to the number of users in the group.
It occurs to me the 'bug' may be in the Match logic. Everything else that didn't rely on the Match directives functioned normally.
please provide a debug log from the server, e.g. by running "sshd -ddd" and capturing the output of a failing session.
I cannot from the system the issue was identified on as it's in production use. I'll see about setting up a test environment to test this on.
Created attachment 2485 [details] ssh -ddd of attempt to login w/ 129 members in match group I've cloned the node, edited the match line to not block based on IP, put all the users into one group (now w/ 129 users). I did mask/modify hostnames/IPs (mydesk.mydomain) (10.xx.xx.201) Verifying the user exists in the sftponly group: # getent group sftponly|grep -e ",sftptestuser$" -e ",sftptestuser,"|wc -l 1 or: # lid -g sftponly | grep sftptestuser sftptestuser(uid=1246) Verifying number of users: # lid -g sftponly | wc -l 129
Created attachment 2486 [details] ssh -ddd of attempt to login w/ 119 members in match group Connection attempt succeeded. I did mask/modify hostnames/IPs (mydesk.mydomain) (10.xx.xx.201) Verifying the user exists in the sftponly group: # getent group sftponly|grep -e ",sftptestuser$" -e ",sftptestuser,"|wc -l 1 or: # lid -g sftponly | grep sftptestuser sftptestuser(uid=1246) Verifying number of users: # lid -g sftponly | wc -l 119
Here's the testing config. Again, I have removed the Address match part to simplify things. Of course, this does mean I have edit the config and restart to enable non-sftp connection with non-sftponly users. All comments/blank lines stripped out: Protocol 2 SyslogFacility AUTHPRIV PermitRootLogin no UsePAM yes AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE AcceptEnv XMODIFIERS X11Forwarding yes TCPKeepAlive yes ClientAliveInterval 600 ClientAliveCountMax 3 MaxStartups 20 Subsystem sftp internal-sftp -l INFO AllowGroups all it nondb Match Group sftponly ChrootDirectory /cust/ftp/secure/%u X11Forwarding no AllowTcpForwarding no ForceCommand internal-sftp -l INFO Match Group *,!sftponly ForceCommand echo 'External shell access denied.' I still have this node around and can make further tests as needed/requested.
What Linux are you using? Also OpenSSH-5.3 is very old and unsupported by us, please see if you can reproduce the problem with our most recent release. Otherwise, if you are using you OS vendor packages then you should follow up with them.
Original node problem discovered on (B for bad): # uname -a | sed "s/$(hostname)/myhost.mydomain/g" ; cat /etc/redhat-release ; rpm -qa | grep openssh-server Linux myhost.mydomain 2.6.32-220.2.1.el6.x86_64 #1 SMP Fri Dec 23 02:21:33 CST 2011 x86_64 x86_64 x86_64 GNU/Linux CentOS release 6.2 (Final) openssh-server-5.3p1-70.el6.x86_64 Testing on a fresh Centos6.5 test host (G for good): Linux myhost.mydomain 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22 03:15:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux CentOS release 6.5 (Final) openssh-server-5.3p1-94.el6.x86_64 and I'm unable to replicate the problem here. These packages are originally from Redhat and CentOS-ified. It would seem this bug was fixed between 24 builds of 5.3p1. Perhaps this was actually bug with SSSD (or how openssh and SSSD 'interact' - I know that sssd has some serious issues in the first version released with RedHat 6): B: sssd-client-1.5.1-66.el6_2.1.x86_64 G: sssd-client-1.9.2-129.el6_5.4.x86_64 I find it odd this bug was never discovered or even mentioned. 127 users or so seems like a small number. Anyway, at least on Centos6.5, this bug isn't present.
Whatever the issue (might very well be SSSD) this isn't an issue in a later build of the same old version of openssh from the same distro.
Set all RESOLVED bugs to CLOSED with release of OpenSSH 7.1