web-dev-qa-db-fra.com

Comment utiliser le serveur ssh avec PAM mais interdire l'authentification par mot de passe?

De nombreux tutoriels vous disent de configurer votre serveur ssh comme ceci:

ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no

mais avec cette configuration, vous ne pouvez pas utiliser PAM, car je prévois d'utiliser 2 Factor Auth avec Google Authenticator (OTP Onetime Password), j'ai besoin de PAM.

Alors, comment configurer un nouveau démon debian jessie ssh, si je veux empêcher la connexion avec le mot de passe normal tout en permettant d'utiliser PAM.

peut-être que la question exacte est de savoir comment configurer pam pour interdire les mots de passe?

Détails sur l'authentification PAM

La désactivation de l'authentification par mot de passe basée sur PAM est plutôt peu intuitive. Il est nécessaire sur à peu près toutes les distributions GNU/Linux (à l'exception notable de Slackware), ainsi que FreeBSD. Si vous ne faites pas attention, vous pouvez définir PasswordAuthentication sur "non" et toujours vous connecter avec juste un mot de passe via l'authentification PAM. Il s'avère que vous devez définir "ChallengeResponseAuthentication" sur "non" afin de vraiment désactiver l'authentification PAM. Les pages de manuel de FreeBSD ont ceci à dire, ce qui peut aider à clarifier un peu la situation:

Notez que si ChallengeResponseAuthentication est "oui" et que la stratégie d'authentification PAM pour sshd inclut pam_unix (8), l'authentification par mot de passe sera autorisée via le mécanisme de défi-réponse quelle que soit la valeur de PasswordAuthentication.

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

sshdebianpam
13
c33s

peut-être que la question exacte est de savoir comment configurer pam pour interdire les mots de passe?

Correct. Vous êtes déjà tombé sur le fait que la configuration de UsePAM no est généralement un mauvais conseil. Non seulement il empêche toute forme d'authentification basée sur PAM, mais il désactive également les modules account et session. Le contrôle d'accès et la configuration de session sont de bonnes choses.

Tout d'abord, construisons une liste d'exigences:

  • OTP via pam_google_authenticator.so. Cela nécessite UsePAM yes et ChallengeResponseAuthentication yes. Vous êtes en train de leur demander des informations d'identification, après tout!
  • Aucune autre forme d'authentification par mot de passe via PAM. Cela signifie désactiver tout module auth qui pourrait éventuellement permettre la transmission d'un mot de passe via keyboard-interactive connexions. (que nous devons laisser activé pour OTP)
  • Authentification par clé. Nous devons exiger une authentification publickey, et peut-être gssapi-with-mic si Kerberos est configuré.

Normalement, l'authentification avec une clé ignore complètement l'authentification basée sur PAM. Cela nous aurait arrêtés sur nos traces avec les anciennes versions de openssh, mais Debian 8 (jessie) supporte la directive AuthenticationMethods. Cela nous permet d'exiger plusieurs méthodes d'authentification, mais ne fonctionne qu'avec les clients implémentant SSHv2.

config sshd

Voici les lignes que je suggère pour /etc/ssh/sshd_config. Assurez-vous d'avoir un moyen d'accéder à ce système sans sshd au cas où vous casseriez quelque chose!

# 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

N'oubliez pas de recharger sshd une fois ces modifications effectuées.

Configuration PAM

Nous devons encore configurer PAM. En supposant une installation propre de Debian 8 (selon votre question):

  • Commentaire @include common-auth de /etc/pam.d/sshd.
  • La revue /etc/pam.d/sshd et confirmez qu'aucune ligne commençant par auth n'est présente. Il ne devrait pas y en avoir s'il s'agit d'une installation propre, mais il vaut mieux être en sécurité.
  • Ajoutez une entrée auth pour pam_google_authenticator.so.

N'oubliez pas que les mots de passe locaux fonctionnent toujours.

Nous n'avons apporté aucune modification susceptible d'avoir un impact sur les connexions via une console locale ou d'empêcher les utilisateurs d'utiliser des mots de passe pour mettre à niveau leurs privilèges via Sudo. Cela sortait du cadre de la question. Si vous décidez d'aller plus loin, n'oubliez pas que root doit toujours être autorisé à se connecter localement via un mot de passe. Sinon, vous risquez de vous verrouiller accidentellement hors du système.

23
Andrew B

pour refuser la demande de mot de passe

commenter cette ligne

#auth       substack     password-auth

dans /etc/pam.d/sshd

et assurez-vous de ne pas avoir nullok à la fin de cette ligne, à moins qu'il ne soit bien de s'authentifier via ssh sans utiliser OTP

auth required pam_google_authenticator.so
1
JOduMonT