Monday, November 4, 2013

HOWTO : Configure OpenSSH to Fetch Public Keys from OpenLDAP for Authentication on CentOS

Today we will configure our OpenLDAP server to store SSH public keys so that the OpenSSH daemon can fetch them and thus authenticate our users.

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.

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

This HOWTO file is basically what we're doing here. Take a look and see for yourself.

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 :

cat ~/ldap/openssh-ldap.conf

Let's make sure we don't have old artifacts lying around.

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.

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 :

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

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.


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+

39 comments:

  1. This comment has been removed by the author.

    ReplyDelete
  2. Hi David, where I can get the openssh-ldap package. I'm running Centos 5.5 and could find it in the repo

    ReplyDelete
    Replies
    1. Hello santhosh,

      I *think* it's in the EPEL repo.

      See https://fedoraproject.org/wiki/EPEL

      HTH,

      DA+

      Delete
  3. Under 6.x it's in the "standard" repo

    ReplyDelete
  4. Thanks 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.

    ReplyDelete
    Replies
    1. Happy to know you're now up and running!

      The 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

      Delete
  5. Hi David,

    Do we need install and configure nss_pam_ldapd module. In PAM.d/sshd config file we are referring to auth required pam_ldap.so

    ReplyDelete
    Replies
    1. Hey Prem,

      Yes, 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+

      Delete
    2. Hi David,

      Thanks 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.

      Delete
    3. Hey Prem,

      /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

      Delete
  6. Hi David,

    I 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?

    ReplyDelete
    Replies
    1. Hi Prem,

      Did you correctly configure the /etc/ssh/ldap.conf file and verified that it works? What do you get when you ssh -v ?

      Delete
    2. This comment has been removed by the author.

      Delete
    3. This comment has been removed by the author.

      Delete
    4. Hi Prem,

      Ok, 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

      Delete
  7. This is my ssh - v log

    debug1: 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).

    ReplyDelete
  8. Hi David,

    Thanks 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)

    ReplyDelete
    Replies
    1. Hey Prem,

      The 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+

      Delete
  9. Thanks David, Finally it worked after fixing the certificate issue. :)

    ReplyDelete
  10. Hi 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.

    ReplyDelete
    Replies
    1. Hey Prem,

      Once 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

      Delete
  11. Hi David,

    Is 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

    ReplyDelete
    Replies
    1. Hey Prem,

      I 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+

      Delete
  12. Thanks for your suggestions.

    ReplyDelete
  13. Awesome! Thank you.

    ReplyDelete
  14. 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: 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 !

    ReplyDelete
    Replies
    1. Hey,

      This 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+

      Delete
    2. Hello David,

      It 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

      Delete
    3. Hey Kevin,

      Do 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

      Delete
    4. 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).

      Delete
  15. Hey David,
    I 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 !

    ReplyDelete
    Replies
    1. Hey there,

      About 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

      Delete
    2. 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

      You 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 !

      Delete
    3. In reply to this

      If 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

      Delete
  16. Hello Dave,

    I 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 !

    ReplyDelete
  17. Hi David,

    First 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

    ReplyDelete