web-dev-qa-db-fra.com

Essayer d'obtenir SSH avec une clé publique (pas de mot de passe) + authentificateur Google travaillant sur Ubuntu 14.04.1

J'utilise Ubuntu 14.04.1 (avec OpenSSH 6.6 et libpam-google-authentator 20130529-2).

J'essaie de configurer des connexions SSH où la clé publique s'authentifie (sans mot de passe) et un utilisateur est invité à entrer un code de l'authentificateur de Google.

En suivant/adaptant ces instructions, j'ai obtenu une invite de mot de passe ainsi qu'une invite d'authentification Google:

J'ai installé le package, modifié mon /etc/ssh/sshd_config et /etc/pam.d/ssh des dossiers

Dans /etc/ssh/sshd_config:

ChallengeResponseAuthentication yes
AuthenticationMethods  publickey,keyboard-interactive
UsePAM yes

et au bas de /etc/pam.d/ssh:

auth required pam_google_authenticator.so nullok # (I want to give everyone a chance to set up their 2FA before removing "nullok")

Je sais que PAM dépend de l'ordre, mais est sshd_config aussi?

Qu'est-ce que je fais mal? Toute aide serait appréciée.

ubuntusshtwo-factorgoogle-authenticator
21
JT.

Je l'ai bien fait, d'abord:

apt-get install libpam-google-authenticator

Dans /etc/pam.d/sshd J'ai changé/ajouté les lignes suivantes (en haut):

# @include common-auth
auth required pam_google_authenticator.so

Et en /etc/ssh/sshd_config:

ChallengeResponseAuthentication yes
UsePAM yes
AuthenticationMethods publickey,keyboard-interactive
PasswordAuthentication no

Fonctionne bien et je reçois maintenant une invite "Code de vérification" après l'authentification avec la clé publique. Je ne sais pas comment j'autoriserais l'authentification avec mot de passe + jeton OR clé + jeton, car j'ai maintenant effectivement supprimé la méthode d'authentification par mot de passe de PAM.

Utilisation d'Ubuntu 14.04.1 LTS (GNU/Linux 3.8.0-19-x86_64 générique) avec ssh -v: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2, OpenSSL 1.0.1f 6 janvier 2014

28
Linus Kendall

J'ai finalement réussi à faire fonctionner cela en plaçant auth [success=done new_authtok_reqd=done default=die] pam_google_authenticator.so nullok Au sommet de /etc/pam.d/sshd.

Selon la page de manuel pam.d :

  • success=done signifie que si Google Authenticator se déconnecte, aucune autre authentification ne sera effectuée, ce qui signifie qu'il n'y aura pas d'invite de mot de passe supplémentaire.
  • default=die signifie que si Google Authenticator rejette la tentative de connexion, l'authentification échouera immédiatement, ignorant l'invite de mot de passe.

Donc [success=done new_authtok_reqd=done default=die] est en quelque sorte un mélange entre les valeurs de contrôle sufficient et requisite, car nous voulons un comportement des deux: en cas de succès, se termine immédiatement (suffisant), et en cas d'échec, se termine également immédiatement (requis ).

Notez que l'argument nullok de pam_google_authenticator.so signifie que si un ~/.google_authenticator le fichier est introuvable pour un utilisateur, l'authentification par clé publique se déroule normalement. Ceci est utile si je souhaite verrouiller uniquement un sous-ensemble de mes comptes avec 2FA.

7
bluegate010

La réponse de Linus Kendall devrait fonctionner sur les anciens systèmes, mais sur les machines Linux plus récentes, elle est problématique; sur mon serveur Web basé sur Arch Linux, cette configuration a pour conséquence que pam demande mon code d'authentification et mon mot de passe après avoir reçu ma clé ssh (c'est-à-dire que j'ai besoin des 3).

Une solution plus simple qui empêche ce problème et qui devrait fonctionner sur tous les systèmes consiste à modifier l'entrée dans /etc/pam.d/sshd à:

auth sufficient pam_google_authenticator.so

Et puis pour apporter les mêmes modifications à ``/etc/ssh/sshd` que Linus a mentionné:

ChallengeResponseAuthentication yes
UsePAM yes
AuthenticationMethods publickey,keyboard-interactive
PasswordAuthentication no

Cela devrait vous demander votre jeton d'authentification après que le serveur a accepté votre clé publique. Il ne devrait pas vous demander votre mot de passe.

En remarque, si vous souhaitez avoir un compte utilisateur sftp, vous devrez probablement contourner l'authentificateur google pour le faire fonctionner. Voici une suggestion sur la façon de le faire en toute sécurité en utilisant une prison sftp. Dans etc/ssh/sshd_config:

Subsystem sftp internal-sftp
Match User ftp-user
  PasswordAuthentication yes
  AuthenticationMethods password
  ChrootDirectory /path/to/ftp/dir
  ForceCommand internal-sftp

Vous devrez créer les autorisations sur/path/to/ftp/dir en écriture seule (par exemple chown root:root /path/to/ftp/dir, chmod 755 /path/to/ftp/dir. Tous les parents au-dessus de ce répertoire ont également besoin d'autorisations sécurisées. La façon dont je le fais habituellement est de créer le répertoire chroot /home/shared/user, en créant un répertoire là-dedans (par exemple 'data') puis en montant le répertoire que je veux partager comme ceci: Sudo mount -o bind /path/to/ftp/dir /home/shared/user/data

Si vous suivez toutes ces étapes, vous aurez une clé publique + un identifiant google authentifiant pour vos utilisateurs ssh et un compte sftp protégé par mot de passe pour le transfert de données.

6
Mike Dacre