Hello, I found this strange behaviour When setting a user in the DenyUsers directive and then Matching it on a Match directive it does not work. I read the man 5 sshd-config : "If all of the criteria on the Match line are satisfied, the keywords on the following lines override those set in the global section of the config file, until either another Match line or the end of the file" So the Match Directive have to override the global settings (or the manual is incomplete). Consider the following in sshd_config: DenyUsers test Match User test ForceCommand /home/test/test.sh This Match block, according to the docs must override the global settings, but it doesn't. Is this a normal Behaviour ? David.
(In reply to comment #0) > Hello, > > I found this strange behaviour > > When setting a user in the DenyUsers directive and then Matching it on > a Match directive it does not work. I read the man 5 sshd-config : > > "If all of the criteria on the Match line are satisfied, the keywords > on the following lines override those set in the global section of the > config file, until either another Match line or the end of the file" > > So the Match Directive have to override the global settings (or the > manual is incomplete). > > Consider the following in sshd_config: > > DenyUsers test > > Match User test > ForceCommand /home/test/test.sh > > This Match block, according to the docs must override the global > settings, but it doesn't. > > Is this a normal Behaviour ? > > David. Some more stuff in logs : debian sshd[7580]: User test from localhost not allowed because listed in DenyUsers I'm running Debian GNU/Linux squeeze/sid and OpenSSH_5.1p1 Debian-6, OpenSSL 0.9.8k 25 Mar 2009
Match doesn't override DenyUsers. The configuration directives that Match can override is listed in sshd_config(5), and DenyUsers is not among them. If you are trying to refuse all access except to some subset of users, I suggest that you disable all authentication methods on the main config and then turn them back on for your allowed users in a Match block.
(In reply to comment #2) > If you are trying to refuse all access except to some subset of users, > I suggest that you disable all authentication methods on the main > config and then turn them back on for your allowed users in a Match > block. I'd like to add something like "Allow yes" or similar that simply sets authctxt->valid at the start of the auth process. This would play nice with Match. You could do: Allow no Match User fred Allow yes
(In reply to comment #3) > (In reply to comment #2) > > If you are trying to refuse all access except to some subset of users, > > I suggest that you disable all authentication methods on the main > > config and then turn them back on for your allowed users in a Match > > block. > > I'd like to add something like "Allow yes" or similar that simply sets > authctxt->valid at the start of the auth process. This would play nice > with Match. You could do: > > Allow no > Match User fred > Allow yes Exactly, because we are managing users with ldap (pam_ldap) we can't statilly define them in sshd_config since users are changing very frequently. So it would be great if when a user is present in the deny list is matched by the Directive Match, to implicitly override DenyUsers for this particular case and then perform actions like ForceCommand. It take sense since we have a block with many conditions to be satisfied and we can retrict the Match block to a user with a host etc etc , and deny other cases .
(In reply to comment #4) > Exactly, because we are managing users with ldap (pam_ldap) we can't > statilly define them in sshd_config since users are changing very > frequently. You can stick them in appropriate groups and use AllowGroups/DenyGroups.
(In reply to comment #4) > Exactly, because we are managing users with ldap (pam_ldap) we can't > statilly define them in sshd_config since users are changing very > frequently. The Match directive supports matching by group as well.
(In reply to comment #3) > I'd like to add something like "Allow yes" or similar that simply sets > authctxt->valid at the start of the auth process. Sure, I think we discussed this before and agreed it was a good idea.
Mass move of RESOLVED bugs to CLOSED now that 5.3 is out.