I have activated Google Authenticator 2FA for SSH logins on Ubuntu 16.04 but made it optional in the /etc/pam.d/sshd:

auth required pam_google_authenticator.so nullok

I have setup the 2FA for accounts which can login from the Internet but not for accounts which are restricted to access from the same subnet because there are cronjobs running which have to transfer stuff from server to server.

This works fantastic for every account except root which is of course restricted to exactly one IP address because production and standby servers have to exchange SSL keys.

Case A: When I try to login with a normal user account with SSH key but without 2FA: no problem.

Case B: When I try to login with root with SSH key but without 2FA I get this error in /var/log/auth.log:

Aug 20 23:39:59 host01 sshd[28638]: fatal: Internal error: PAM auth succeeded when it should have failed

Your help would be very appreciated.

  • I could solve the problem although I don't understand why. :) After changing PermitRootLogin without-password to yes everything works fine. I assume this is no problem because I restrict root login to one IP and also restrict password authentication completely so I would think there is no difference between "without-password" and "yes", correct?
    – Arno
    Aug 20, 2017 at 21:45
  • Why are you logging in as root?
    – Alex
    Feb 5, 2018 at 15:48

1 Answer 1


This is the expected behavior. Assuming you had PermitRootLogin without-password, the man page for the PermitRootLogin says:

If this option is set to prohibit-password or without-password, password and keyboard-interactive authentication are disabled for root.

PAM is considered keyboard-interactive. Therefore, with PermitRootLogin without-password PAM should not allow root to login, which is the behavior you observed.

There is a difference between without-password and yes for that option. You just observed it. With yes, you can login with passwords or PAM, and with without-password you cannot login with these methods. You could still login with, e.g., a public key.

Changing PermitRootLogin to yes solves your problem, but please consider that all this headache is there for a reason. Unless you really know what you are doing, PermitRootLogin should be set to no. If you need to do rooty things remotely, login as a user withsudo privileges.

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.