18

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

c33s
  • 1,465
  • 3
  • 20
  • 39

2 Answers2

29

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.

Andrew B
  • 31,858
  • 12
  • 90
  • 128
  • havn't tested it yet but it looks logical and with 5 upvotes i think i can accept it. – c33s Nov 09 '17 at 23:27
  • I have tested myself. if you want to fully disable password, you have to also set ChallengeResponseAuthentication no. see https://blog.tankywoo.com/linux/2013/09/14/ssh-passwordauthentication-vs-challengeresponseauthentication.html – anonymous Jun 24 '19 at 00:07
  • @anonymous Refer to the OP's question and the first bullet. Disabling `ChallengeResponseAuthentication` breaks the keyboard-interactive authentication method, which is needed for PAM authentication modules that handle OTP. (desired by the OP) Disabling CRA is only safe to perform if you truly have *zero* PAM modules in the `auth` stack that need to fire. If `PasswordAuthentication` and `GSSAPIAuthentication` are disabled, a password will not be accepted unless PAM has an enabled auth module that asks for it. – Andrew B Jun 24 '19 at 02:29
  • (that said, it's still a great link) – Andrew B Jun 24 '19 at 02:40
1

to disallow the password request

comment this line

#auth       substack     password-auth

in /etc/pam.d/sshd

and be sure to not have nullok at the end of this line unless it will be fine to authenticate via ssh without using OTP

auth required pam_google_authenticator.so
JOduMonT
  • 29
  • 3