We are using LDAP for account information. The environment is configured as follows ...
- A CentOS 7 OpenLDAP directory server
- A CentOS 7 client configured to use the directory server
- authconfig has been used to configure the CentOS 7 client for LDAP authentication
I have noticed the following
- A local user (one whose account information is in /etc/passwd) can ssh to the client itself without using public key authentication (without a password)
- An LDAP user can ssh to the client itself using a password
- An LDAP user cannot ssh to the client itself using public key authentication. The user has a properly configured ssh keys (
id_rsa) and authorized_keys similar to the local user
The debug output when performing an ssh using the local user is
debug1: Offering RSA public key: /home/localuser/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-rsa blen 279
The debug output when performing an ssh using the LDAP user is
debug1: Offering RSA public key: /home/ldapuser/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
The log, /var/log/secure, has the following entry after the LDAP user attempts to connect using public key authentication
Mar 19 16:47:01 localhost sshd: Connection closed by x.x.x.x [preauth]
LDAP can locate the user account
$ getent passwd ldapuser ldapuser:x:5001:5000::/home/ldapuser:/bin/bash
When ssh allows PasswordAuthentication
$ ssh test ldapuser@test's password: Last failed login: Sat Mar 19 17:08:29 UTC 2016 from x.x.x.x on ssh:notty Last login: Sat Mar 19 15:55:40 2016
I realize that there are alternatives such as OpenSSH-LPK, but would like to be able to use a local authorized_keys that installed using Puppet as it doesn't require the maintenance of LDAP. I am not sure if this approach is possible and, if it is, of the configuration of sshd, PAM, or LDAP. Any pointers would be appreciated ...
Following Jakuje's suggestion of setting the log level to DEBUG for sshd, the logs contained the clue of
Mar 19 18:22:42 localhost sshd: debug1: temporarily_use_uid: 5001/5000 (e=0/0) Mar 19 18:22:42 localhost sshd: debug1: trying public key file /home/ldapuser/.ssh/authorized_keys Mar 19 18:22:42 localhost sshd: debug1: Could not open authorized keys '/home/ldapuser/.ssh/authorized_keys': Permission denied Mar 19 18:22:42 localhost sshd: debug1: restore_uid: 0/0
The / and /home directories have the following permissions
$ ll -and / /home dr-xr-xr-x. 17 0 0 4096 Feb 22 17:26 / drwxr-xr-x. 5 0 0 45 Mar 19 03:05 /home
The /home/ldapuser directory has the following permissions
$ ll -an . drwxr-xr-x. 3 5001 5000 99 Mar 19 16:46 . drwxr-xr-x. 5 0 0 45 Mar 19 03:05 .. drwx------. 2 5001 5000 76 Mar 19 02:45 .ssh
The /home/ldapuser/.ssh directory has the following permissions
$ ll -an . total 16 drwx------. 2 5001 5000 76 Mar 19 02:45 . drwxr-xr-x. 3 5001 5000 99 Mar 19 16:46 .. -rw-r--r--. 1 5001 5000 419 Mar 19 02:45 authorized_keys -rw-------. 1 5001 5000 1679 Mar 19 02:45 id_rsa -rw-r--r--. 1 5001 5000 419 Mar 19 02:45 id_rsa.pub -rw-r--r--. 1 5001 5000 177 Mar 19 02:45 known_hosts
The sshd daemon is setting the effective user to 5001/5000 and so am not sure why permission would be denied. The root user can switch to the ldapuser so the system is aware of the user.
Jakuje: Thanks so much! The SELinux was the cause of the problem and running the restorecon fixed the issue. I appreciate your help and patience!