Ssh – How to use the ssh server with PAM but disallow password auth

debianpamssh

Many tutorials tell you to config your ssh server like this:

ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no

but with this setup you cannot use PAM, as i plan to use 2 Factor Auth with Google Authenticator (OTP Onetime Password) i need PAM.

So how to configure a fresh debian jessie ssh deamon, if i want to prevent the login with the normal password but still allow to use PAM.

maybe the exact question is how to configure pam to disallow passwords?

Details on PAM Authentication

Disabling PAM-based password authentication is rather un-intuitive. It
is needed on pretty much all GNU/Linux distributions (with the notable
exception of Slackware), along with FreeBSD. If you're not careful,
you can have PasswordAuthentication set to 'no' and still login with
just a password through PAM authentication. It turns out that you need
to set 'ChallengeResponseAuthentication' to 'no' in order to truly
disable PAM authentication. The FreeBSD man pages have this to say,
which may help to clarify the situation a bit:

Note that if ChallengeResponseAuthentication is 'yes', and the PAM authentication policy for sshd includes pam_unix(8), password
authentication will be allowed through the challenge-response
mechanism regardless of the value of PasswordAuthentication.

http://www.unixlore.net/articles/five-minutes-to-more-secure-ssh.html

Best Answer

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 account and 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.

sshd config

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
PermitRootLogin no

# Needed for OTP logins
ChallengeResponseAuthentication yes
UsePAM yes

# Not needed for OTP logins
PasswordAuthentication no

# Change to to "yes" if you need Kerberos. If you're unsure, this is a very safe "no".
GSSAPIAuthentication no


# Require an OTP be provided with key based logins
AuthenticationMethods publickey,keyboard-interactive

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

PAM config

We still have to configure PAM. Assuming a clean install of Debian 8 (per your question):

  • Comment @include common-auth from /etc/pam.d/sshd.
  • Review /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 pam_google_authenticator.so.

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.

Related Topic