[Bug 2384] New: AllowUsers doesn't allow users sssd domain users with @ in

bugzilla-daemon at mindrot.org bugzilla-daemon at mindrot.org
Fri Apr 17 21:47:34 AEST 2015


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

            Bug ID: 2384
           Summary: AllowUsers doesn't allow users sssd domain users with
                    @ in
           Product: Portable OpenSSH
           Version: 6.6p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: bjoern at j3e.de

sssd users from an active directory have the syntax
accountname at domain.realm

they can also aliased to domain\accountname and optionally just to
"accountname". In any case when you run getent on any of those names
you get back the real username "accountname at domain.realm" like here:

# getent passwd bjacke
bjacke at comp.private:*:83542:100:bjacke:/home/comp.private/bjacke:/bin/bash

# getent passwd comp\\bjacke
bjacke at comp.private:*:83542:100:bjacke:/home/comp.private/bjacke:/bin/bash

I see two problems here:

1) even if users log on with the "full qualified name"
accountname at domain.realm then it is not possible to limit logons via
AllowUsers because the @ is a limiter for the hostname here and I don't
see how the @ could be quoted or so.

2) if the user logs on with an alias name then sshd should normalize
the name by asking nsswitch like in the above case, to see that bjacke
is actually bjacke at comp.private

When I log on as bjacke (who is bjacke at comp.private really) in the sshd
log I see:

Postponed keyboard-interactive for invalid user bjacke from 127.0.0.1

even though I set "AllowUsers bjacke". So maybe bjacke is normalized to
the real "bjacke at comp.private" name and just the log output is
confusing. But even then still the problem remains that there is no way
to define a user with @ in AllowUsers...

-- 
You are receiving this mail because:
You are watching the assignee of the bug.


More information about the openssh-bugs mailing list