3

What I did:

  • Installed libpam-ldapd

  • Set up /etc/ldap/ldap.conf

  • Set up /etc/ssh/ldap-keys.sh as root:root 0755, confirmed it works (/etc/ssh/ldap_keys.sh amadan returns my public keys from LDAP).

  • Set up /etc/nsswitch.conf: passwd, sudo and shadow now say compat ldap, and new line sudoers has ldap.

  • Set up /etc/ssh/sshd_config: AuthorizedKeysCommand points to the file above, AuthorizedKeysCommandUser to a newly created dedicated user

  • Set up /usr/share/pam-configs/mkhomedir; ran pam-auth-update.

Current situation is that when I try to log in, AuthorizedKeysCommand (/etc/ssh/ldap-keys.sh) is never run. I also do not know whether or not the rest of my configuration is correct or not, but I can't tell yet on account of sshd always reporting "invalid user":

Oct 17 17:22:59 xxx sshd[86244]: Invalid user amadan from yyy
Oct 17 17:22:59 xxx sshd[86244]: input_userauth_request: invalid user amadan [preauth]
Oct 17 17:23:01 xxx sshd[86244]: Connection closed by yyy [preauth]

I know I'm doing something wrong... but what?

EDIT: relevant PAM settings:

# auth
auth    [success=2 default=ignore]  pam_unix.so nullok_secure debug
auth    [success=1 default=ignore]  pam_ldap.so minimum_uid=1000 use_first_pass debug
auth    requisite           pam_deny.so
auth    required            pam_permit.so
auth    optional            pam_cap.so 

# account
account [success=2 new_authtok_reqd=done default=ignore]    pam_unix.so 
account [success=ok new_authtok_reqd=done ignore=ignore user_unknown=ignore authinfo_unavail=ignore default=bad]    pam_ldap.so minimum_uid=1000
account requisite           pam_deny.so
account required            pam_permit.so

EDIT: strace excerpt on this sshd:

open("/lib/x86_64-linux-gnu/security/pam_ldap.so", O_RDONLY|O_CLOEXEC) = 8
read(8, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240\20\0\0\0\0\0\0"..., 832) = 832
fstat(8, {st_mode=S_IFREG|0644, st_size=26544, ...}) = 0
mmap(NULL, 2121744, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 8, 0) = 0x7f58df52b000
mprotect(0x7f58df531000, 2093056, PROT_NONE) = 0
mmap(0x7f58df730000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 8, 0x5000) = 0x7f58df730000
close(8)                                = 0
mprotect(0x7f58df730000, 4096, PROT_READ) = 0
open("/lib/x86_64-linux-gnu/security/pam_deny.so", O_RDONLY|O_CLOEXEC) = 8

Strace excerpt from a working sshd (on another server):

open("/lib/x86_64-linux-gnu/security/pam_ldap.so", O_RDONLY|O_CLOEXEC) = 8
read(8, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\37\0\0\0\0\0\0"..., 832) = 832
fstat(8, {st_mode=S_IFREG|0644, st_size=47792, ...}) = 0
mmap(NULL, 2142888, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 8, 0) = 0x7f8ef8a3c000
mprotect(0x7f8ef8a46000, 2097152, PROT_NONE) = 0
mmap(0x7f8ef8c46000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 8, 0xa000) = 0x
close(8)                                = 0
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 8
fstat(8, {st_mode=S_IFREG|0644, st_size=152262, ...}) = 0
mmap(NULL, 152262, PROT_READ, MAP_PRIVATE, 8, 0) = 0x7f8efcee1000
close(8)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2", O_RDONLY|O_CLOEXEC) = 8

In the working sshd, pam_ldap.so invokes libldap_r-2.4.so.2; in this one, it does not; it exits without doing much, and immediately proceeds to the next PAM module. I do not know why.

Amadan
  • 159
  • 1
  • 14
  • on SUSE using the `pam-config` tool to set the PAM configurations properly normally takes care of things. `pam-config --add --ldap` Have you checked the PAM common user and auth settings in `/etc/pam.d/common-{account, auth,password}`, also have you verified that the system is connected to the LDAP by connecting to the server using `ldapsearch` or `ldapwhoami`? – Matt Oct 21 '16 at 01:34
  • @Matt: `pam-config` is not a thing in Ubuntu (if I understand what it does, I believe `pam-auth-update` should be close). As I said, the command configured to `AuthorizedKeysCommand` (which uses `ldapsearch`) works: `/etc/ssh/ldap-keys.sh amadan` successfully returns my keys from LDAP. The core of the question right now is really why `AuthorizedKeysCommand` is never invoked when a user connects. EDIT: Also, `/etc/pam.d/common-*` seem to be correct by eyeball, but I'm no PAM expert. – Amadan Oct 21 '16 at 01:40
  • well it can't find a user by that name so technically a user never connects unless I am reading your logs incorrectly. To me that would indicate that `sshd` is having trouble connecting to the LDAP server. Is `sssd` running? what is the output of `id amadan`? – Matt Oct 21 '16 at 01:44
  • and also have you made sure that /etc/pam.d/sshd is setup correctly? – Matt Oct 21 '16 at 01:55
  • @Matt: No tutorials I ever saw mentioned `sssd`, another server that does work doesn't have it installed. `/etc/pam.d/sshd` is identical. `id amadan` also reports "no such user". However, you might have put me on a right track: I (apparently mistakenly) believed that the only interaction with LDAP is in `AuthorizedKeysCommand`; if `sshd` is looking up things before that, how does it know how to connect? (my LDAP server refuses anonymous, and needs binddn and password for lookup.) I cannot find any such settings on the working server. – Amadan Oct 21 '16 at 02:09
  • does sshd_config contain the line `UsePAM yes` and/or did you only modify the `AuthorizedKeysCommand` settings? for LDAP to work at some point a list of users needs to be loaded from the LDAP server, since you get "no such user" when testing a user that you know to be in the LDAP database it seems safe to assume that the systems connection to the LDAP server is not setup correctly, which is preventing the users from being loaded. If NSCD is running flushing the cache might also help `sudo /etc/init.d/nscd restart` – Matt Oct 21 '16 at 02:16
  • Yeah, that's a valid conclusion. `UsePAM yes` is present (by default). But I still don't know how sshd should know how to authenticate a connection to the LDAP server (except by explicit `ldapsearch` command present in my `ldap-keys.sh`). – Amadan Oct 21 '16 at 02:20
  • @Matt: I think I solved it, following the trail of your hints. I managed to miss `/etc/nslcd.conf` (this being the answer to my question "how does sshd know how to contact my LDAP). I can log in now. Even though you haven't answered it directly, you were instrumental in my finding the solution; if you submit an answer, the bounty is yours. – Amadan Oct 21 '16 at 08:43

1 Answers1

1

It would appear that the cache maintained by the Name Service Caching Daemon has grown stale/was not updated to reflect the new LDAP settings.

sudo /etc/init.d/nscd restart

should restart the service and update the cache.

Matt
  • 2,711
  • 1
  • 13
  • 20