James Dennis
2003-Feb-12 20:05 UTC
((AllowUsers || AllowGroups) && !(AllowUsers && AllowGroups))
Hey everyone, After discussing the AllowGroups I think I've discovered a bug. The system is a solaris 8 system and the problem is that when I use AllowGroups with no AllowUsers args, the proper actions happen. Same with AllowUsers and no AllowGroups. When I try to combine the two, none of the Allow directives seem to take. Is it just me or maybe a bug? -James
Jim Knoble
2003-Feb-12 21:12 UTC
((AllowUsers || AllowGroups) && !(AllowUsers && AllowGroups))
Circa 2003-02-12 15:05:20 -0500 dixit James Dennis: : Hey everyone, : : After discussing the AllowGroups I think I've discovered a bug. : : The system is a solaris 8 system and the problem is that when I use : AllowGroups with no AllowUsers args, the proper actions happen. Same : with AllowUsers and no AllowGroups. When I try to combine the two, none : of the Allow directives seem to take. : : Is it just me or maybe a bug? Maybe a little of both. Testing under OpenBSD-3.2: $ ssh -V OpenSSH_3.5, SSH protocols 1.5/2.0, OpenSSL 0x00907003 with the following users: # useradd -m -G users blah # useradd -m -G users haha # egrep '(blah|haha)' /etc/passwd /etc/group /etc/passwd:blah:*:1021:1021::/home/blah:/bin/ksh /etc/passwd:haha:*:1022:1022::/home/haha:/bin/ksh /etc/group:users:*:10:,blah,haha /etc/group:blah:*:1019:blah /etc/group:haha:*:1020:haha # gives the following results: Users successfully log in: Condition blah haha root no Allow* => yes yes yes AllowUsers blah => yes no no AllowUsers haha => no yes no AllowUsers root => no no yes AllowGroups users => yes yes no AllowGroups users, AllowUsers root => no no no The last one is what's surprising. Here's what the sshd log has to say (at LogLevel VERBOSE, with timestamps removed to conserve space): ---------------- Received SIGHUP; restarting. Server listening on :: port 22. Server listening on 0.0.0.0 port 22. Connection from 127.0.0.1 port 32492 User blah not allowed because not listed in AllowUsers input_userauth_request: illegal user blah Failed none for illegal user blah from 127.0.0.1 port 32492 ssh2 Failed publickey for illegal user blah from 127.0.0.1 port 32492 ssh2 [...] Failed password for illegal user blah from 127.0.0.1 port 32492 ssh2 [...] Disconnecting: Too many authentication failures for blah Connection from 127.0.0.1 port 40621 User haha not allowed because not listed in AllowUsers input_userauth_request: illegal user haha Failed none for illegal user haha from 127.0.0.1 port 40621 ssh2 Failed publickey for illegal user haha from 127.0.0.1 port 40621 ssh2 [...] Failed password for illegal user haha from 127.0.0.1 port 40621 ssh2 [...] Disconnecting: Too many authentication failures for haha Connection from 127.0.0.1 port 35381 User root not allowed because none of user's groups are listed in AllowGroups input_userauth_request: illegal user root Failed none for illegal user root from 127.0.0.1 port 35381 ssh2 Failed publickey for illegal user root from 127.0.0.1 port 35381 ssh2 [...] Failed password for illegal user root from 127.0.0.1 port 35381 ssh2 [...] Disconnecting: Too many authentication failures for root ---------------- Seems as if sshd requires that a user be in: AllowUsers <set-intersection> AllowGroups instead of: AllowUsers <set-union> AllowGroups in order not to be an "illegal user". That's certainly not what i expected. If i need to deny certain group members, i would expect to do the following: DenyUsers blah AllowGroups users [implicit DenyUsers *] or: DenyGroups wheel AllowGroups users [implicit DenyUsers *] I would also expect that: AllowUsers root AllowGroups users [implicit DenyUsers *] would allow all three of blah, haha, and root. That is, i expect a first-match allow/deny, in the order listed in the file, and that there is exactly one implicit 'DenyUsers *' (if any Allow* directives appear) or 'AllowUsers *' (if any Deny* directives appear, and no Allow* directives appear), which appears at the very bottom of the list. That is: DenyGroups users DenyUsers root [implicit AllowUsers *] or: DenyUsers root AllowGroups wheel staff [implicit DenyUsers *] Alternatively, if sshd were to do a last-match instead of a first-match, then the implicit 'AllowUsers *' or 'DenyUsers *' rule would go at the top, and the order would be reversed, e.g.: [implicit DenyUsers *] AllowGroups wheel staff DenyUsers root Either way would work better than the current surprising behavior (although i prefer first-match ACLs rather than last-match ones). Anyone else care to comment? -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491) "I am non-refutable." --Enik the Altrusian -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 256 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030212/9ab529ce/attachment.bin
Reasonably Related Threads
- Question about AllowUsers and AllowGroups
- [Bug 1690] New: AllowUsers and DenyGroups directives are not parsed in the order specified
- AllowUsers Change
- AllowUsers "logic" and failure to indicate bad configuration
- [Bug 2292] New: sshd_config(5): DenyUsers, AllowUsers, DenyGroups, AllowGroups should actually tell how the evaluation order matters