openssh bugs - Sep 2014 - [Bug 2282] New: When group member count exceeds 126, config reliant fails

https://bugzilla.mindrot.org/show_bug.cgi?id=2282

            Bug ID: 2282
           Summary: When group member count exceeds 126, config reliant
                    fails
           Product: Portable OpenSSH
           Version: 5.3p1
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: sftp-server
          Assignee: unassigned-bugs at mindrot.org
          Reporter: rake74 at gmail.com

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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2282

--- Comment #1 from rake74 at gmail.com ---
It occurs to me the 'bug' may be in the Match logic. Everything else
that didn't rely on the Match directives functioned normally.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2282

rake74 at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|When group member count     |When group member count
                   |exceeds 126, config reliant |exceeds 126, Match
                   |fails                       |directives fail

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2282

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #2 from Damien Miller <djm at mindrot.org> ---
please provide a debug log from the server, e.g. by running "sshd
-ddd"
and capturing the output of a failing session.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2282

--- Comment #3 from rake74 at gmail.com ---
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.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2282

--- Comment #4 from rake74 at gmail.com ---
Created attachment 2485
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2485&action=edit
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

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2282

--- Comment #5 from rake74 at gmail.com ---
Created attachment 2486
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2486&action=edit
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

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2282

--- Comment #6 from rake74 at gmail.com ---
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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2282

--- Comment #7 from Damien Miller <djm at mindrot.org> ---
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.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2282

--- Comment #8 from rake74 at gmail.com ---
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.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2282

rake74 at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #9 from rake74 at gmail.com ---
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.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2282

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #10 from Damien Miller <djm at mindrot.org> ---
Set all RESOLVED bugs to CLOSED with release of OpenSSH 7.1

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.