Whenever I login to my Centos 7.x server I always get a transparent failure in the audit.log. This is making my attempts to have a daily script for failed logins very difficult as we can't be sure what's a real failure. Here's an excerpt from aureport -au -ts today

1669. 06/02/17 08:40:03 handsm@internal ssh /usr/sbin/sshd no 1428242
1670. 06/02/17 08:40:03 handsm@internal ssh /usr/sbin/sshd no 1428243
1671. 06/02/17 08:40:06 handsm@internal server01 ssh /usr/sbin/sshd yes 1428244
1672. 06/02/17 08:40:06 handsm@internal ssh /usr/sbin/sshd yes 1428246
1673. 06/02/17 08:40:13 handsm@internal.office ? /dev/pts/3 /usr/bin/sudo yes 1428284

You can see the first 2 rows are failures then I get an immediate success. Does anyone have any clue why this may be happening?

Edit_1: Included verbose SSH log files:

Feb 6 09:59:42 wb-prod-ctl sshd[50489]: Connection from port 58847 on port 22 Feb 6 09:59:45 wb-prod-ctl sshd[50489]: Failed publickey for handsm@internal from port 58847 ssh2: RSA c4:a3:e9:ad:2f:5c:fa:b4:de:49:6a:7d:83:fa:11:d5 Feb 6 09:59:45 wb-prod-ctl sshd[50489]: Postponed gssapi-with-mic for handsm@internal from port 58847 ssh2 [preauth] Feb 6 09:59:46 wb-prod-ctl sshd[50489]: Failed gssapi-with-mic for handsm@internal from port 58847 ssh2 Feb 6 09:59:48 wb-prod-ctl sshd[50489]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=server01.internal.office user=handsm@internal Feb 6 09:59:48 wb-prod-ctl sshd[50489]: Accepted password for handsm@regsec from port 58847 ssh2 Feb 6 09:59:48 wb-prod-ctl sshd[50489]: pam_unix(sshd:session): session opened for user handsm@internal by (uid=0) Feb 6 09:59:48 wb-prod-ctl sshd[50489]: User child is on pid 50492 Feb 6 09:59:48 wb-prod-ctl sshd[50492]: Starting session: shell on pts/3 for handsm@internal.office from port 58847

Looks like a failure with gssapi-with-mic ??

Edit_2: I've disabled GSSAPIAuthentication now with no ill effect and the error in my SSH logs for gssapi-with-mic has gone......however (!), I am left with the Failed publickey error.

So my server allows both AD logins (uid + password) and passwordless logins (public/private keys). I think my issue is this very fact, and I may not be able to resolve it, i.e. SSH is expecting either method and if one isn't used then the other writes an error to the log.

Does anyone else have experience of this?

Edit_3: Problem solved - thanks to Liczyrzrepa.

So it seems that Putty's default settings are to "Attempt authentication using Pageant" (see image below). When I created a new Putty session to the server in question and disabled this setting, I no longer see the Failed publickey error.

enter image description here

  • 3
    What doessshd have to say on the matter? (If necessary turn up its debug level.) – roaima Feb 6 '17 at 9:16
  • 1
    Please, post the complete audit messages and the verbose logs from sshd in the respective time. – Jakuje Feb 6 '17 at 9:39
  • Edited post with logs. – machinist Feb 6 '17 at 10:06
  • These failures are normal. Not every error is a problem. You'll need to make your log parsing scripts less naive. – Gilles 'SO- stop being evil' Feb 6 '17 at 22:10

By default, the OpenSSH client will attempt Public Key authentication if you have previously created keys. My guess is that if you do ls ${HOME}/.ssh/ you'll see a keypair - id_rsa and id_rsa.pub. When your client connects to the server, it attempts to use this keypair to login. Because id_rsa.pub is not in ${HOME}/.ssh/authorized_keys on your server, or that file has incorrect permissions, sshd on the server correctly marks that login attempt as having failed. Try the following:

ssh -o PubkeyAuthentication=no

Setting that option will prevent the SSH client from using keys in ${HOME}/.ssh/ when trying to authenticate to the server. If that doesn't keep the log messages from showing up, add -vv to the ssh client options so we can see exactly what it's up to.

| improve this answer | |
  • Thanks for this Liczyrzrepa, your post pointed me to the problem - see my edited original post for more details. – machinist Feb 7 '17 at 8:49
  • @machinist - My pleasure :) – Liczyrzepa Feb 7 '17 at 14:42

Apologies for resurrecting an old thread, but I found it while searching for a similar issue.

There is a second potential cause of false positive SSH error messages on Linux systems which have more than one authentication source for users (e.g. LDAP and local users). The default configuration is often to check for local users first, using the "pam_unix.so" module. If the user does not exist as a local user, then this will always generate a failure log message, even if the check for a user in the other authentication source succeeds.

If (as is often the case) the LDAP users are the common case, this can be resolved for LDAP users by checking LDAP first and then trying local authentication. For example, for Debian 10, I changed two lines in /etc/pam.d/common-auth from:

# here are the per-package modules (the "Primary" block)
auth    [success=2 default=ignore]  pam_unix.so nullok_secure
auth    [success=1 default=ignore]  pam_ldap.so minimum_uid=1000 use_first_pass
# here's the fallback if no module succeeds
auth    requisite           pam_deny.so


# here are the per-package modules (the "Primary" block)
auth    [success=2 default=ignore]  pam_ldap.so minimum_uid=1000
auth    [success=1 default=ignore]  pam_unix.so nullok_secure use_first_pass
# here's the fallback if no module succeeds
auth    requisite           pam_deny.so

=> the two lines with "success=" are swapped, the numbers changed to match the new location ("success=" skips that many lines on a successful return from the module), and the "use_first_pass" flag is moved to keep it on the second line

This isn't a complete solution, as it means that LDAP is checked for local users (which may not be desirable)

There is a Redhat solution documenting a different way to resolve this for Redhat like Linux distros, which I believe doesn't have this drawback (pam_localuser.so checks if the user exists as a local user, before trying to authenticate):


It should be possible to implement the same solution for Debian like systems, but I haven't done so.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.