maybe the exact question is how to configure pam to disallow passwords?
Correct. You've already stumbled upon the fact that setting
UsePAM no is generally bad advice. Not only does it prevent any form of PAM based authentication, it also disables
session modules. Access control and session configuration are good things.
First, let's build a list of requirements:
- OTP via
pam_google_authenticator.so. This requires
UsePAM yes and
ChallengeResponseAuthentication yes. You're prompting them for a credential, after all!
- No other form of password authentication via PAM. This means disabling any
auth module that might possibly allow a password to be transmitted via
keyboard-interactive logins. (which we have to leave enabled for OTP)
- Key based authentication. We need to require
publickey authentication, and maybe
gssapi-with-mic if you have Kerberos configured.
Normally, authenticating with a key skips PAM based authentication entirely. This would have stopped us in our tracks with older versions of openssh, but Debian 8 (jessie) supports the
AuthenticationMethods directive. This allows us to require multiple authentication methods, but only works with clients implementing SSHv2.
Below are the lines I suggest for
/etc/ssh/sshd_config. Make sure you have a way to access this system without
sshd in case you break something!
# Require local root only
# Needed for OTP logins
# Not needed for OTP logins
# Change to to "yes" if you need Kerberos. If you're unsure, this is a very safe "no".
# Require an OTP be provided with key based logins
# Use this instead for Kerberos+pubkey, both with OTP
#AuthenticationMethods gssapi-with-mic,keyboard-interactive publickey,keyboard-interactive
Don't forget to reload
sshd once these changes have been made.
We still have to configure PAM. Assuming a clean install of Debian 8 (per your question):
@include common-auth from
/etc/pam.d/sshd and confirm that no lines beginning with
auth are present. There shouldn't be if this is a clean install, but it's best to be safe.
- Add an
auth entry for
Remember that local passwords still work.
We did not make any changes that would impact logins via a local console, or prevent users from using passwords to upgrade their privileges via
sudo. This was outside the scope of the question. If you decide to take things further, remember that root should be always be permitted to login locally via password. You risk locking yourself out of the system accidentally otherwise.