openssh bugs - Sep 2009 - [Bug 1646] New: Match directive does not override default settings

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

           Summary: Match directive does not override default settings
           Product: Portable OpenSSH
           Version: 5.1p1
          Platform: ix86
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: sshd
        AssignedTo: unassigned-bugs at mindrot.org
        ReportedBy: alves at montecristogames.com


--- Comment #0 from David Alves <alves at montecristogames.com> 2009-09-03
01:55:19 EST ---
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.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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



--- Comment #1 from David Alves <alves at montecristogames.com> 2009-09-03
02:50:40 EST ---
(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

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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


Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


--- Comment #2 from Damien Miller <djm at mindrot.org> 2009-09-03 03:53:19
EST ---
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.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- 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=1646


Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at zip.com.au


--- Comment #3 from Darren Tucker <dtucker at zip.com.au> 2009-09-03
10:01:20 EST ---
(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

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- 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=1646



--- Comment #4 from David Alves <alves at montecristogames.com> 2009-09-03
19:24:13 EST ---
(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 .

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- 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=1646



--- Comment #5 from Darren Tucker <dtucker at zip.com.au> 2009-09-03
19:30:17 EST ---
(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.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- 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=1646



--- Comment #6 from Damien Miller <djm at mindrot.org> 2009-09-04 09:56:26
EST ---
(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.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- 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=1646



--- Comment #7 from Damien Miller <djm at mindrot.org> 2009-09-04 09:57:40
EST ---
(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.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- 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=1646

Damien Miller <djm at mindrot.org> changed:

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

--- Comment #8 from Damien Miller <djm at mindrot.org> 2009-10-06 15:03:12
EST ---
Mass move of RESOLVED bugs to CLOSED now that 5.3 is out.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- 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.