AllowUsers and AllowGroup not working together
 

Hi,

AllowUsers user or AllowGroup group in sshd config file is working fine.

But they are not working together. Is it possible to use both of them together ?

I am using RHEL 6.4.

'man sshd_config' says: "The allow/deny directives are processed in the following order: DenyUsers, AllowUsers, DenyGroups, and finally AllowGroups." so it kind of depends on how you set things up. Post what you're actually trying to accomplish?

Hi,

Requirement :

AllowUsers user-a user-b

AllowGroup group-1

user-c and user-d are member of group-1.

So how would
DenyUsers user-c user-d
AllowUsers user-a user-b
work then?
*BTW if the sshd service uses PAM there's also pam_access, pam_group and pam_listfile which may allow for more fine-grained access controls.

Also ... in a real-world corporate setting, it doesn't take too long to see the virtue of a centrally-managed arrangement such as one built on Kerberos or LDAP (nee OpenDirectory). You see, right now you're setting up one-of-a-kind rules in a one-of-a-kind place, probably with the intent of matching rules that exist somewhere-else for the same group of people, and the fundamental problem here can only get worse; more unmanageable.

If you have any sort of "substantial" number of rules to deal with here, and especially if you need to match "the settings that exist for the same people in other contexts," seriously consider centralizing that process. Linux, thanks to PAM, is perfectly capable of it.

There's actually a rather serious sort of vulnerability that comes from finding "the exception to the rule," and one of the classic places to do that is by seeking-out what is difficult-to-manage. "Perhaps it would be possible to worm into the Linux system and, from there, maybe be accepted by the rest of the system as actually being that person ..." If the Linux system, instead, conforms to the corporate-world by virtue of respecting the same authority that everyone else does, it will no longer present that vulnerability to the enterprise. This is an absolutely pure-human consideration, but, as such, it is maybe more-real than bits and bytes alone would suggest.