/etc/pam.d/sshd nullok not functioning in RHEL7.4

[rpayneavue]

OS: RHEL 7.4 Expectation: /etc/pam.d/sshd: "auth required pam_google_authenticator.so nullok" - This should mean that users who don’t run the Google Authenticator initialization won’t be asked for a second authentication. Problem: Users who don’t run the Google Authenticator initialization cannot login and receive the following connection error: "no supported authentication methods available (server sent keyboard-interactive)". Steps to reproduce: Configure RHEL7.4 per AWS' guidance here: https://aws.amazon.com/blogs/startups/securing-ssh-to-amazon-ec2-linux-hosts/. Try to SSH to the instance for users who have not run Google Authenticator initialization. This will generate the following connection error: "no supported authentication methods available (server sent keyboard-interactive)". Note: This was testing using public key auth.

Working with AWS, they claim this functions as intended on Amazon Linux "As mentioned before the default configuration works on Amazon Linux where configured users will authenticate with both public key and TOTP and unconfigured users will authenticate with only public key and nullok argument is working as expected and ignoring TOTP if unconfigured."

Please let me know if you need additional details.

[akerl]

Can you run your ssh command w/ -vv added and paste the command? And paste your full /etc/ssh/sshd_config from the server?

[rpayneavue]

We're configuring another test server and will complete your request shortly. In the mean time, here's some testing notes that have isolated it to the google-authenticator-1.04-1.el7.x86_64.rpm version:

1. confirmed PAM versions are the same on Amazon and RHEL7
2. installing the Amazon google-authenticator versions on RHEL7 allows the nullok parameter to function as intended. google-authenticator-1.0-1.2.amzn1.x86_64.rpm
3. ssh -v on rhel7 instance with v1.0-1.2amzn1 "debug1: Offering RSA public key: MYKEY.pem debug1: Server accepts key: pkalg ssh-rsa blen 279 Authenticated with partial success. debug1: Authentications that can continue: keyboard-interactive debug1: Next authentication method: keyboard-interactive debug1: Authentication succeeded (keyboard-interactive). Authenticated to ([]:22)."
4. The nullok failure is then reproduced on the Amazon instance with google-authenticator-1.04-1.el7.x86_64.rpm.

[rpayneavue]

@akerl Please see the attached. Let us know if we can provide any additional info.

Thank you!

sshvv_output.txt sshd_config.txt

[ThomasHabets]

And in your PAM config you have auth required pam_google_authenticator.so nullok?

Ah, I think I know what this is. Same as https://github.com/google/google-authenticator-libpam/issues/75.

Could you try that same solution?

(the behaviour was changed back in January but probably took a while to get to RHEL)

[rpayneavue]

Correct. Please see below configuration checks. Confirming the solution in #75 was to:

1. append auth required pam_permit.so to /etc/ssh/sshd_config
2. restart sshd

Thanks for the help!

nullok is configured to allow service account exceptions as the guidance suggests. [rpayne@wikiqatc-i-0d6999babf6fb7258 ~]$ sudo grep google /etc/pam.d/sshd auth required pam_google_authenticator.so nullok

Confirming additional article configurations: [rpayne@wikiqatc-i-0d6999babf6fb7258 ~]$ sudo grep interactive /etc/ssh/sshd_config AuthenticationMethods publickey,keyboard-interactive [rpayne@wikiqatc-i-0d6999babf6fb7258 ~]$ sudo grep ChallengeR /etc/ssh/sshd_config

ChallengeResponseAuthentication yes

ChallengeResponseAuthentication yes [rpayne@wikiqatc-i-0d6999babf6fb7258 ~]$ sudo grep substack /etc/pam.d/sshd

auth substack password-auth

[ThomasHabets]

So all sorted? Great!

[jmiahman]

Just to correct, if future readers don't catch it (in CentOS):

1. append auth required pam_permit.so to /etc/pam.d/sshd
2. restart sshd

Hope this helps. Thanks for your feedback helped me :) in 2019

[stephdl]

are you (really really) sure ????

https://linux.die.net/man/8/pam_permit

pam_permit is a PAM module that always permit access. It does nothing else.

In the case of authentication, the user's name will be set to nobody if the application didn't set one. Many applications and PAM modules become confused if this name is unknown.

This module is very dangerous. It should be used with extreme caution.

[ThomasHabets]

Yes (if done right). In short PAM requires at least one "yes" to permit login, and requires no "no".

The described config intends that if GA is not configured, then the user should be let through. But if it's not configured then GA says neither yes nor no, it says "ignore me".

If there is any other module (e.g. pam_unix) that says "no", then the pam_permit does nothing.

And at least in #75 the config was publickey, then GA as second factor.

It's Friday evening, so I may not be communicating clearly, but yeah this should be right. Just don't do auth sufficient pam_permit.

[stephdl]

like you said, test your configuration with bad login, in my pam file for openvpn, it always granted access

[ThomasHabets]

Yeah I wouldn't recommend having only a module that can say "maybe" (PAM_IGNORE) followed by pam_accept. That's not likely to ever be what you want. This only make sense with a first factor enforced (like in #75 which as first factor has SSH pubkey).