Bug 627057 - SSH_Filter usage undocumented, not intuitive
Summary: SSH_Filter usage undocumented, not intuitive
Alias: None
Product: Fedora
Classification: Fedora
Component: openssh
Version: 13
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jan F. Chadima
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-08-25 00:01 UTC by Brian LaMere
Modified: 2010-08-26 07:36 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-08-25 17:31:27 UTC

Attachments (Terms of Use)

Description Brian LaMere 2010-08-25 00:01:49 UTC
Description of problem:

openssh-ldap group filter is undocumented

Version-Release number of selected component (if applicable):


How reproducible:

Steps to Reproduce:
1. setting SSH_Filter to the group dn, the group cn, and just the naked group name itself does not seem to work
Actual results:

/usr/libexec/openssh/ssh-ldap-helper -f /etc/openldap/ldap.conf -s %u

produces no results.

Expected results:

members of the SSH_Filter group should function

Additional info:

I know this isn't a bug, but it isn't documented at all that I can see and I can't determine the "correct" thing to put there.

Note that the ldap server is 389 Directory Server, and the nss info is being served by sssd.  The user mapping works fine, and ssh-ldap-helper gets keys if I remove the filter completely.  If necessary, I can simply add the following line to pam.d/system-auth, to have the desired result - would just like to do it with the way you seem to be intending.

auth        requisite     pam_succeed_if.so user ingroup (groupname) quiet_success

Comment 1 Jan F. Chadima 2010-08-25 11:31:41 UTC
The filter syntax is a plain LDAP filter syntax, this string is pasted as is at the end of the search string.

Comment 2 Brian LaMere 2010-08-25 17:31:27 UTC
running "ssh-ldap-helper -vvv" I see where I was confused; like you said, it's just being added to the filter.

debug3: LDAP search scope = 2 (&(objectclass=posixAccount)(objectclass=ldapPublicKey)(uid=testuser)(&(cn=testgroup)(objectClass=posixgroup)))

Obviously ldap doesn't do joins, so there's nothing that can be added to the filter to search for secondary groups; the posixAccount objectclass doesn't even have a "secondarygroups" attribute.

This can be closed; SSH_Filter is used for something different than what I thought.  I can just use AllowGroups in sshd_config instead, or the pam_succeed_if add to system-auth

Comment 3 Jan F. Chadima 2010-08-26 07:36:37 UTC
If you have an idea how make the documentation better, send it, please.

Note You need to log in before you can comment on or make changes to this bug.