((AllowUsers || AllowGroups) && !(AllowUsers && AllowGroups))

[Dan Astoorian]

On Fri, 14 Feb 2003 16:48:30 EST, Ben Lindstrom writes:
> 
> I think we are making this more complex than it really is.  The only valid
> rules should be as such
> 
> If PermitRootLogin then
> 	goto Accepted # Damn it, if I state root is allowed, it damn well
> 			better be honored.

I don't think I agree with this.

I'd interpret "PermitRootLogin" in this case as being relevant to any
user with uid=0, whereas AllowUsers and DenyUsers refer to specific
entries in /etc/passwd.

"PermitRootLogin no" is presumably intended to enforce the policy "no
superuser account may ever connect via ssh," for the same reason many
systems are configured to restrict root logins to a (presumably
physically secure) console; I see no justification to infer that
"PermitRootLogin yes" should circumvent any additional constraints, such
as DenyUsers.

Do PermitRootLogin=without-password or PermitRootLogin=forced-commands-only
present any further considerations?

Currently, PermitRootLogin is handled independently anyway.

[snip remainder of algorithm, which appears to be identical to the one I
suggested :-) ]

> I can see someone going.. "But this breaks DenyUser root".  Well tought,
> if you don't want root, use the right option.

What if I want
    AllowUsers shutdown

where "shutdown" is a uid=0 account with a shell of /etc/shutdown, but I
don't want to permit root to log in via ssh?

-- 
Dan Astoorian               People shouldn't think that it's better to have
Sysadmin, CSLab             loved and lost than never loved at all.  It's
djast at cs.toronto.edu        not, it's better to have loved and won.  All
www.cs.toronto.edu/~djast/  the other options really suck.    --Dan Redican