To do this, we first need two CentOS machines. This is easy to achieve via a KickStart. If you need help building a KickStart server, follow my previous blog post. Then we need a working OpenLDAP server. If you don't have one, then follow my previous blog posts to set one up.
Once this is done, connect to a machine that is set to become the OpenSSH client of the OpenLDAP server.
ssh client.example.org
Install the required packages. Most likely you will already have both openssh and openssh-server, but not openssh-ldap.
sudo yum -y install openssh openssh-server openssh-ldap nss-pam-ldapd
This will provide you with the required OpenLDAP schema and special sshd_config(5) configuration to enable the OpenSSH daemon to fetch SSH public keys from the OpenLDAP server.
If we take a look at what the openssh-ldap package provides, we'll find a nice HOWTO file.
Install the required packages. Most likely you will already have both openssh and openssh-server, but not openssh-ldap.
sudo yum -y install openssh openssh-server openssh-ldap nss-pam-ldapd
This will provide you with the required OpenLDAP schema and special sshd_config(5) configuration to enable the OpenSSH daemon to fetch SSH public keys from the OpenLDAP server.
If we take a look at what the openssh-ldap package provides, we'll find a nice HOWTO file.
rpm -ql openssh-ldap
/usr/libexec/openssh/ssh-ldap-helper
/usr/libexec/openssh/ssh-ldap-wrapper
/usr/share/doc/openssh-ldap-5.3p1
/usr/share/doc/openssh-ldap-5.3p1/HOWTO.ldap-keys
/usr/share/doc/openssh-ldap-5.3p1/ldap.conf
/usr/share/doc/openssh-ldap-5.3p1/openssh-lpk-openldap.schema
/usr/share/doc/openssh-ldap-5.3p1/openssh-lpk-sun.schema
/usr/share/man/man5/ssh-ldap.conf.5.gz
/usr/share/man/man8/ssh-ldap-helper.8.gz
OpenLDAP Server Configuration
Next we need to configure OpenLDAP. To do so, we first create a temporary configuration file which includes only two schemas : the core and then the openssh-openldap one.
echo "include /etc/openldap/schema/core.schema" > ~/ldap/openssh-ldap.conf
rpm -ql openssh-ldap | grep -i schema | grep -i openldap | sed 's/^/include /g' >> ~/ldap/openssh-ldap.conf
The resulting file is very small :
slapcat -f ~/ldap/openssh-ldap.conf -F ~/ldap -n 0
We then need to clean up the resulting files before we can add them to our OpenLDAP server.
sed -re "/^(structuralObjectClass|entry[C|U]|creat[e|o]|modif[i|y])/d" cn\=config/cn\=schema/cn\=\{1\}openssh-lpk-openldap.ldif > ~/ldap/openssh-ldap.ldif
sed -i.bak -e "s/{1}openssh-lpk-openldap/openssh-openldap/g" ~/ldap/openssh-ldap.ldif
sed -i.bak -e "s/cn=openssh-openldap/cn=openssh-openldap,cn=schema,cn=config/g" ~/ldap/openssh-ldap.ldif
Which results in a very small file :
We can now add this to our OpenLDAP server.
ldapmodify -axZWD cn=admin,dc=example,dc=org -f ~/ldap/openssh-ldap.ldif
And we can make sure it's indeed in our DIT.
echo "include /etc/openldap/schema/core.schema" > ~/ldap/openssh-ldap.conf
rpm -ql openssh-ldap | grep -i schema | grep -i openldap | sed 's/^/include /g' >> ~/ldap/openssh-ldap.conf
The resulting file is very small :
rm -rf ~/ldap/cn\=config*
We then create the cn=config version of this file. This creates the ~/ldap/cn\=config directory.
slapcat -f ~/ldap/openssh-ldap.conf -F ~/ldap -n 0
We then need to clean up the resulting files before we can add them to our OpenLDAP server.
sed -re "/^(structuralObjectClass|entry[C|U]|creat[e|o]|modif[i|y])/d" cn\=config/cn\=schema/cn\=\{1\}openssh-lpk-openldap.ldif > ~/ldap/openssh-ldap.ldif
sed -i.bak -e "s/{1}openssh-lpk-openldap/openssh-openldap/g" ~/ldap/openssh-ldap.ldif
sed -i.bak -e "s/cn=openssh-openldap/cn=openssh-openldap,cn=schema,cn=config/g" ~/ldap/openssh-ldap.ldif
Which results in a very small file :
We can now add this to our OpenLDAP server.
ldapmodify -axZWD cn=admin,dc=example,dc=org -f ~/ldap/openssh-ldap.ldif
And we can make sure it's indeed in our DIT.
ldapsearch -xLLLZWD cn=admin,dcexample,dc=org -b cn=config
VERY IMPORTANT : If you have a replicated OpenLDAP setup, then MAKE SURE YOU ALSO ADD THE NEW openssh-ldap.ldif FILE TO THE REPLICATED MACHINES! If you don't do so, the replicated servers (or consumers in OpenLDAP language) will protest and fail to operate. You have been warned!
At this point we need to modify our OpenLDAP users to use the new attributes we just installed (i.e. sshPublicKey and ldapPublicKey). This task is quite easier with an LDAP Browser. I really like Apache Directory Studio. In any case, use your favorite LDAP editor and connect to the OpenLDAP server.
At this point we need to modify our OpenLDAP users to use the new attributes we just installed (i.e. sshPublicKey and ldapPublicKey). This task is quite easier with an LDAP Browser. I really like Apache Directory Studio. In any case, use your favorite LDAP editor and connect to the OpenLDAP server.
So for our users, we add the new objectClass attribute named ldapPublicKey. Once this new objectClass is installed, we can then add the new sshPublicKey attribute.
Of course, we need to add a value to the sshPublicKey. But what? Easy, just add your existing SSH Public Key usually stored in the users's ~/.ssh/id_rsa.pub file. If you don't already have one, simply generate it with this command :
Of course, we need to add a value to the sshPublicKey. But what? Easy, just add your existing SSH Public Key usually stored in the users's ~/.ssh/id_rsa.pub file. If you don't already have one, simply generate it with this command :
ssh-keygen -t rsa -b 2048
This command generates an RSA key pair. This key pair is stored in two files. One holds the private key (~/.ssh/id_rsa) while the other stores the public one (~/.ssh/id_rsa.pub). Keep the private one safe!
Now that we have configured our user, let's see how this user is seen in our OpenLDAP server? I've listed the relevant attributes in bold in the following output. I've also changed both the userPassword and sshPublicKey attributes for obvious reasons ;)
ldapsearch -xZWLLLD cn=admin,dc=example,dc=org -b ou=users,dc=example,dc=org cn=davidr
Enter LDAP Password:
dn: cn=davidr,ou=users,dc=example,dc=org
uid: davidr
gecos: David Robillard
objectClass: top
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
objectClass: ldapPublicKey
userPassword:: e1NTSEF9UnNBTXFPSTM2NDdxZzFnQVpasdasdAwc0VWZmE=
shadowLastChange: 15140
shadowMin: 0
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 2000
gidNumber: 2000
homeDirectory: /nfs/home/davidr
cn: davidr
sshPublicKey: ssh-rsa AAAAB3NzaC1yc2EAAAADAQAhygfeeDQOSbGhDjPqQSQz1BE9ogqvWHNpKfG3Hhp0uTXzzMyTmVqGDAMDl3Nc3rXjg1rf1Vcmi9+FUmh5nni7JUCvrhZoHdJuuVY3OlnXWRUREKIFrPKQ1YIl0q81iomLwJwnhwWYzfQbQyUtKprdg6pobUVSf+76D1Svjqv9PbimAD6nw== davidr@bwmdavidr
Now that we have configured our user, let's see how this user is seen in our OpenLDAP server? I've listed the relevant attributes in bold in the following output. I've also changed both the userPassword and sshPublicKey attributes for obvious reasons ;)
ldapsearch -xZWLLLD cn=admin,dc=example,dc=org -b ou=users,dc=example,dc=org cn=davidr
Enter LDAP Password:
dn: cn=davidr,ou=users,dc=example,dc=org
uid: davidr
gecos: David Robillard
objectClass: top
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
objectClass: ldapPublicKey
userPassword:: e1NTSEF9UnNBTXFPSTM2NDdxZzFnQVpasdasdAwc0VWZmE=
shadowLastChange: 15140
shadowMin: 0
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 2000
gidNumber: 2000
homeDirectory: /nfs/home/davidr
cn: davidr
sshPublicKey: ssh-rsa AAAAB3NzaC1yc2EAAAADAQAhygfeeDQOSbGhDjPqQSQz1BE9ogqvWHNpKfG3Hhp0uTXzzMyTmVqGDAMDl3Nc3rXjg1rf1Vcmi9+FUmh5nni7JUCvrhZoHdJuuVY3OlnXWRUREKIFrPKQ1YIl0q81iomLwJwnhwWYzfQbQyUtKprdg6pobUVSf+76D1Svjqv9PbimAD6nw== davidr@bwmdavidr
Configure OpenSSH
Now that OpenLDAP is ready, we must configure OpenSSH to fetch the keys from OpenLDAP. We do so by installing new configuration lines in sshd_config(5). These lines are :
AuthorizedKeysCommand /usr/libexec/openssh/ssh-ldap-wrapper
AuthorizedKeysCommandRunAs nobody
PubkeyAuthentication yes
So do it.
sudo vim /etc/ssh/sshd_config
And we make sure to restart the OpenSSH daemon so that it knows about this new configuration.
sudo /etc/init.d/sshd restart
Then we must configure the ldap.conf(5) specifically for OpenSSH. So we place the file under /etc/ssh.
sudo vim /etc/ssh/ldap.conf
We can now try the new setup. From another machine, try to connect to the server we just configured to fetch the SSH key from our OpenLDAP server.
ssh -v client.example.org
And in our /var/log/secure file, we should see these lines :
Nov 4 13:30:42 client sshd[4924]: Accepted publickey for davidr from 192.168.20.216 port 32135 ssh2
Nov 4 13:30:42 client sshd[4924]: pam_unix(sshd:session): session opened for user davidr by (uid=0)
And there you go :)
HTH,
DA+
This comment has been removed by the author.
ReplyDeleteHi David, where I can get the openssh-ldap package. I'm running Centos 5.5 and could find it in the repo
ReplyDeleteHello santhosh,
DeleteI *think* it's in the EPEL repo.
See https://fedoraproject.org/wiki/EPEL
HTH,
DA+
Under 6.x it's in the "standard" repo
ReplyDeleteThanks for this guide, David. I was able to set this up and get it working pretty easily with your instructions. But I noticed that with `AuthorizedKeysCommandRunAs nobody` set, my /etc/ssh/ldap.conf needed loose permissions. I changed that to root so that my BINDPW is protected, but I'm still not sure if that's the best solution.
ReplyDeleteHappy to know you're now up and running!
DeleteThe bind password in ldap.conf is hopefully a read only account that will fetch public SSH keys from the OpenLDAP server. And you should have ACLs in place that restrict the user to a read only access and only to the data in the LDAP server that you need / want it to access.Given that the data retrieved is already public (the public ssh keys) and the user is read only, we can safely say that it's not that sensitive. Just make sure nobody else than root can actually edit your ldap.conf file to prevent a service disruption and you should be good.
HTH,
David
Hi David,
ReplyDeleteDo we need install and configure nss_pam_ldapd module. In PAM.d/sshd config file we are referring to auth required pam_ldap.so
Hey Prem,
DeleteYes, you are right, you need to install the following RPM to have the /usr/lib64/libnss_ldap.so
file referenced in the /etc/pam.d/sshd configuration file.
nss-pam-ldapd
Thanks for pointing that out, I'll add it to the blog post.
DA+
Hi David,
DeleteThanks you for your quick response. I am trying to ssetup openssh to fetch public keys from Apache DS LDAP. Apache DS has the new schema imported and users are setup with public keys.
In case we need nss_ldap module, there are now two ldap configurations. One /etc/nslcd.conf and /etc/ssh/ldap.conf. I am not sure which one will be used. When i try to ssh LDAP bind is failing. Also i am not seeing this script running /usr/libexec/openssh/ssh-ldap-wrapper. Could you please provide some pointers.
Hey Prem,
Delete/etc/nslcd.conf is used to configure the Name Service LDAP Cache Daemon. It's only job is to cache data fetched from the LDAP directory. It's the LDAP aware equivalent to nscd. See http://linux.die.net/man/8/nscd and https://www.freebsd.org/cgi/man.cgi?query=nscd&apropos=0&sektion=8&manpath=FreeBSD+10.2-RELEASE&arch=default&format=html for info.
NSLCD needs to be configured too.
/etc/ssh/ldap.conf on the other hand is the OpenSSH daemon's own LDAP configuration. It instructs the OpenSSH deamon where and with which credentials to fetch data from which LDAP source?
If you've configured your OS to fetch data from the LDAP server via /etc/ldap.conf and / or /etc/openldap/ldap.conf file, then you can use the getent and ldapsearch commands to see if these configuration work? If they do, then simply add the same configuration (using the proper files syntax of course) to both /etc/nslcd.conf and /etc/ssh/ldap.conf. That should do it.
Good luck,
David
Hi David,
ReplyDeleteI able to ssh if the public keys is available in ~/.ssh/authorized_keys file. Since we have public keys in LDAP, the SSHD daemon is still looking for key in ~/.ssh/authorized_keys file. Even if i change the comment out AuthorizedKeysFile .ssh/authorized_keys and replace with AuthorizedKeysFile /dev/null. Still getting error authorized keys /dev/null is not a regular file. Is there any thing i am missing in sshd_config to skip looking into authorized_keys file?
Hi Prem,
DeleteDid you correctly configure the /etc/ssh/ldap.conf file and verified that it works? What do you get when you ssh -v ?
This comment has been removed by the author.
DeleteThis comment has been removed by the author.
DeleteHi Prem,
DeleteOk, from this debug info, please do the following :
a) Make sure the client (where you are using the ssh command), the server (the target of the client's ssh command) and the OpenLDAP servers (the ones that have the public keys) are all in sync via NTP. This is vital. If they're not, then make sure they all have the same /etc/ntp.conf file, stop the ntpd process, then use sudo ntpdate command to do a one time sync and restart the ntpd process. Then wait a while for the ntpd daemon to synchronise with the upstream ntp servers.
b) Once that's done, make sure you OpenSSH daemon has the correct configuration files in place and restart it. Then try again.
HTH,
David
This is my ssh - v log
ReplyDeletedebug1: Server host key: ECDSA 5f:ab:8c:38:cc:35:1a:b4:1d:02:43:a4:0f:7b:11:fd
debug1: Host '192.168.56.103' is known and matches the ECDSA host key.
debug1: Found key in /home/osboxes/.ssh/known_hosts:4
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available
debug1: Unspecified GSS failure. Minor code may provide more information
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/osboxes/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
Hi David,
ReplyDeleteThanks for your suggestions. I am taking a step back instead of using ssh command. I just testing the script /usr/libexec/openssh/ssh-ldap-wrapper username1 but SSL handskake is failing
ldap_simple_bind Can't contact the LDAP Server.
LDAP log shows. Initially i thought it was issue with certificate, but when i did ldapsearch using ldaps://host:sslport/ it worked fine without complaining about the certificate.
javax.net.ssl.SSLHandshakeException: SSL handshake failed.
INFO | jvm 1 | 2015/11/20 08:40:27 | at org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:507)
INFO | jvm 1 | 2015/11/20 08:40:27 | at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultI
INFO | jvm 1 | 2015/11/20 08:40:27 | Caused by: javax.net.ssl.SSLException: Received fatal alert: unknown_ca
INFO | jvm 1 | 2015/11/20 08:40:27 | at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
INFO | jvm 1 | 2015/11/20 08:40:27 | at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666)
Hey Prem,
DeleteThe ldapsearch command and the ssh-ldap-wrapper script might not deal the same way with unknown CA. That's appears to be the case here with this error :
Caused by: javax.net.ssl.SSLException: Received fatal alert: unknown_ca
I'd suggest that you add the CA cert that you used to sign your LDAP server's certificate with in the JVM's keystore and truststore. Or that you configure you Java application not to verify CAs.
DA+
Thanks David, Finally it worked after fixing the certificate issue. :)
ReplyDeleteGreat!
DeleteHi David, Is there a way to restrict the sftp/ssh users using Mkdir or rmdir commands?. I would really appreciate if can you provide some pointers.
ReplyDeleteHey Prem,
DeleteOnce a user has logged in via SSH, the only way to control the mkdir command is by leveraging UNIX permissions or ACL.
Check the chmod(1) and setfacl(1) commands and man pages.
I would suggest trying to solve your use cases with UNIX permissions before trying your luck with ACLs.
Good luck,
David
Thanks David
ReplyDeleteHi David,
ReplyDeleteIs there a way to get $RHOST (remote host id) and send it as parameter to ssh_ldap_wrapper, to do IP validation along with getting public key.
Thank You,
Prem
Hey Prem,
DeleteI honestly don't know? But maybe you can check if the ssh_ldap_wrapper is a script? If so, then you might be able to edit it.
But maybe it's more easy to use iptables to filter out unwanted IP addresses from reaching TCP port 22. Or just let the known ones reach it.
I'm sorry I can't help you more. Good luck!
DA+
Thanks for your suggestions.
ReplyDeleteAwesome! Thank you.
ReplyDeleteMy pleasure. Glad you liked it :)
Deleteldapmodify -axZWD cn=admin,dc=domain,dc=com -f ~/ldap/openssh-ldap.ldif
ReplyDeleteEnter LDAP Password:
adding new entry "cn=openssh-openldap,cn=schema,cn=config"
ldap_add: Insufficient access (50)
Any idea why this would happen ?
Everything is working fine as far as it goes. I am able to serve up people with my LDAP server, and i have added OU and tested, admin account can do anything (Its the rootDN). Why do I face insufficient access on this step ? (Running centos 6.6 final)
Let me know !
Hey,
DeleteThis looks like an ACL issue on the cn=config database. What do these look like? And what error message do you see in the logs when this happens?
HTH,
DA+
Hello David,
DeleteIt was indeed empty, thanks.
Although, now attempting the same thing gives me this :
ldapmodify -axZWD cn=admin,dc=domain,dc=com -f ~/ldap/openssh-ldap.ldif
Enter LDAP Password:
adding new entry "cn=openssh-openldap,cn=schema,cn=config"
ldap_add: Other (e.g., implementation specific) error (80)
Can i have a snippet of your " /etc/openldap/slapd.d/cn\=config/olcDatabase\=\{0\}config.ldif "
I think there is issue with how i can access this database, and i would like to see how you manage to do yours.
Thanks,
Kevin
Hey Kevin,
DeleteDo you have the dn: cn={14}openssh-lpk-openldap,cn=schema,cn=config shema installed? You can run an ldapsearch on « -b cn=config dn » to see if it's there. It's required for this to work of course. Just checking :)
Now, the ACL I have on the cn=config database is this :
sudo ldapsearch -LLLY EXTERNAL -H ldapi:/// -b olcDatabase={0}config,cn=config olcAccess
olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=externa
l,cn=auth" manage by dn.base="cn=admin,dc=example,dc=
com" manage by dn.regex="uid=.*/admin,cn=example.com,
cn=gssapi,cn=auth" manage by * none
Make sure you have a full backup of your environment before you start playing with ACLs as you can lock yourself out. Also, for some reason I have yet to understand, sometimes OpenLDAP will change your ACL entries from normal, readable text to what looks like the result of a hash function. That makes editing and debugging really, really hard once that's done. It sort of happens when the number of ACL lines and the size of it become big. If someone knows why this happens, kindly let me know!
Good luck!
HTH,
David
Humm, the olcAccess output in the above comment is not good. OpenLDAP ACL are very sensitive to how they are written with regards to the line breaks. Don't simply copy and paste this. Make sure you use the proper OpenLDAP tools to edit your ACLs (which is via LDIF files and, yes, it can be quite a pain).
DeleteHey David,
ReplyDeleteI was able to finally add the Pubkey parameter to the config database !
Using your Access helped me get access to upload that to my config database.
I finalized your guide. However, I am not able to log-in using Public/Private Key yet. It simply just do not ask / deny me. I only log-in using user/password and it works.. while this shouldn't.
Question :
sudo vim /etc/ssh/sshd_config
AND
sudo vim /etc/ssh/ldap.conf
Do you do these steps on the Client machine (the one that you want to authenticate users to the LDAP server), or on the LDAP server itself ?
I have applied both these on my client machine (There was no /etc/ssh/ldap.conf file yet.. ?)
I feel like something is missing to activate Public Private key.
Let me know !
Hey there,
DeleteAbout the sshd_config and ldap.conf files, both of these need to be modified on the client machine (i.e. the one you try to ssh into). The /etc/ssh/sshd_config configures the sshd daemon. In there, the line « AuthorizedKeysCommand /usr/libexec/openssh/ssh-ldap-wrapper » instructs the /usr/sbin/sshd daemon that he can use the « /usr/libexec/openssh/ssh-ldap-wrapper » command to fetch Authorized Keys from another source (here, the OpenLDAP server). In turn, the « /usr/libexec/openssh/ssh-ldap-wrapper » file is a small shell script :
#!/bin/sh
exec /usr/libexec/openssh/ssh-ldap-helper -s "$1"
# EOF
That shell script requires the proper configurations found in the /etc/ssh/ldap.conf file. Because in that one, you let the daemon know your OpenLDAP server's hostname, port, connection mechanism, credentials for the bind DN used to contact that OpenLDAP server, the search path, etc.
And yes, the /etc/ssh/ldap.conf file does not exist at first. It is installed by the openssh-ldap RPM package. Make sure you have this one installed, otherwise things won't work. See the files it contains :
[davidr@client] ~ {1005}$ rpm -ql openssh-ldap
/usr/libexec/openssh/ssh-ldap-helper
/usr/libexec/openssh/ssh-ldap-wrapper
/usr/share/doc/openssh-ldap-5.3p1
/usr/share/doc/openssh-ldap-5.3p1/HOWTO.ldap-keys
/usr/share/doc/openssh-ldap-5.3p1/ldap.conf
/usr/share/doc/openssh-ldap-5.3p1/openssh-lpk-openldap.schema
/usr/share/doc/openssh-ldap-5.3p1/openssh-lpk-sun.schema
/usr/share/man/man5/ssh-ldap.conf.5.gz
/usr/share/man/man8/ssh-ldap-helper.8.gz
To test if you can fetch OpenSSH public keys from the OpenLDAP server, connect to the client machine and simply run the wrapper manually. Like this :
[davidr@client] ~ {1006}$ /usr/libexec/openssh/ssh-ldap-wrapper davidr
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAA[...truncated...]PKQ1YIl0q81iomLwJwnhwWYzfQbQyUtKprdg6pobUVSf+76D1Svjqv9PbimAD6nw== davidr@workstation
If that doesn't work, then you have an issue somewhere. It might be in the configuration found in /etc/ssh/ldap.conf or in the OpenLDAP server itself or an ACL to fetch the public key. If we look at the OpenLDAP server to see the public key, it looks like this :
[davidr@server] ~ {1020}$ sudo ldapsearch -LLLY EXTERNAL -H ldapi:/// -b cn=davidr,ou=users,dc=example,dc=com sshPublicKey
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn: cn=davidr,ou=users,dc=example,dc=com
sshPublicKey: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAA[...truncated...]PKQ1YIl0q81iomLwJwnhwWYzfQbQyUtKprdg6pobUVSf+76D1Svjqv9PbimAD6nw== davidr@workstation
HTH,
David
So actually, looks like " sudo vim /etc/ssh/ldap.conf ", that's no longer where the file is, but more likely to be in /etc/openldap/ldap.conf
DeleteYou might want to change that, since that confused me ;)
Second thing, i am able to add that "objectClass: ldapPublicKey" to my users, but the other parameter "sshPublicKey" just never sticks. I have tried deleting the user, adding a new one with it in, but it gets deleted by the server somehow.
Question : If the user has no sshPublicKey parameter, does the LDAP falls back to only authenticate with user/password ?
Because right now that's what mine do, it's only sticked to that.
Let me know and thanks a whole lot again !
In reply to this
DeleteIf you use centOS 6.6, please add this to your SSHD.conf.
"RequiredAuthentications2 publickey,password"
Dave did not mention it, but in order to have public key auth working, you will need to either : Disable password auth, or copy paste this line up there and it will force both Password and Public key auth.
GL,
Kevin
Hello Dave,
ReplyDeleteI followed through your guide, and I am facing one simple issue.
I cannot log-in my users through the LDAP.
See output from my bitvise SSH client down here (I have replaced a few things for privacy)
20:38:41.738 Started a new SSH2 session.
20:38:41.746 Connecting to SSH2 server "hostname":22.
20:38:41.786 Connection established.
20:38:41.806 Server version: SSH-2.0-OpenSSH_5.3
20:38:41.806 First key exchange started. Cryptographic provider: Windows CNG (x86) with additions
20:38:41.953 Received host key from the server. Algorithm: RSA, size: 2048 bits, MD5 fingerprint: FINGERPRINT HERE :: :: ::, Bubble-Babble: xuzit-tibel-pumos-gekig-dyris-tipac-dasyc-puhuh-fuhyc-kyneh-coxix, SHA-256 fingerprint: "FINGERPRINT HERE".
20:38:41.984 First key exchange completed using diffie-hellman-group14-sha1. Session encryption: aes256-ctr, integrity: hmac-sha2-256, compression: none.
20:38:41.999 Attempting publickey authentication. Testing client key 'Global 1' for acceptance.
20:38:42.256 The client key 'Global 1' has been accepted.
20:38:42.256 Attempting publickey authentication. Signing with client key 'Global 1'.
20:38:42.469 Authentication succeeded. Additional authentication is required. Remaining authentication methods: 'password'.
20:38:44.360 Authentication failed. Remaining authentication methods: 'password'.
20:38:57.923 Authentication aborted on user's request.
20:38:57.941 The SSH2 session has been terminated.
It seems like it can connect, authenticate the public key, but it always fails and crash at the password authentication level.
I followed Kevin's comment and added "RequiredAuthentications2 publickey,password" to my sshd conf so that it can authenticate with both factors.
Any idea why it cant auth the password ? It's the good one, and i have changed it multiple time to ensure it was..
Help would be greatly appreciated !
Hi David,
ReplyDeleteFirst of all, these series of openldap articles are great, wish I'd found your blog sooner!
Just one problem, none of your shared files (configurations, ldifs etc) are available on Dropbox anymore, a 404 page is returned. I presume you have stored all these files in your Public folder which according to this article, https://www.dropbox.com/help/files-folders/public-folder, are no longer public.
I fully appreciate that you are busy but it would be great to somehow get these files :)
Cheers
Simon
This comment has been removed by the author.
DeleteI concur with "Anonymous06 August, 2017 08:08." The articles are great, but the fact that the ldif examples are gone. I looked up David's GitHub to see if they had moved there, but there are no Public facing repositories.
DeleteHey Bill and Unknown, you guys are totally right. I've been pushing this for too long. I thought about doing an AWS S3 share for the files, but the GitHub approach is very interesting. I'll hopefully have time to do this soon. Please don't hesitate to ping me next week if I have not yet done so during the weekend.
DeleteHey Bill,
ReplyDeleteI've placed all my files in github. The whole repo is not very organized at the moment, but the files are there. Try https://github.com/davidrobillard/blog/tree/master/openldap
Paths have not yet been updated in the blog, but the file names are the same as they were in dropbox. So one can find them in github too.
HTH,
David
Awesome, thank you!
Delete