google authenticator libpam
1.0.0
Exemple de module PAM démontrant l'authentification à deux facteurs pour se connecter aux serveurs via SSH, OpenVPN, etc…
Ce projet ne consiste pas à se connecter à Google, Facebook ou à d'autres systèmes TOTP / HOTP Second Factor, même s'ils recommandent d'utiliser les applications Google Authenticator.
Le mot de passe ponctuel (HOTP) basé sur HMAC est spécifié dans RFC 4226 et le mot de passe ponctuel basé sur le temps (TOTP) est spécifié dans RFC 6238.
./bootstrap.sh
./configure
make
sudo make installSi vous n'avez pas accès à "sudo", vous devez devenir manuellement "root" avant d'appeler "faire l'installation".
Pour une sécurité la plus élevée, assurez-vous que le mot de passe et le OTP sont demandés même si le mot de passe et / ou OTP sont incorrects. Cela requisite qu'au moins le premier de pam_unix.so (ou tout autre module required utilisé pour vérifier les mots de passe) et pam_google_authenticator.so . Cela ne peut probablement pas faire de mal d'avoir les deux required , mais cela pourrait dépendre du reste de votre configuration PAM.
Si vous utilisez HOTP (compteur basé par opposition au temps basé), ajoutez l'option no_increment_hotp pour vous assurer que le compteur n'est pas incrémenté pour les tentatives infructueuses.
Ajoutez cette ligne à votre fichier de configuration PAM:
auth required pam_google_authenticator.so no_increment_hotp
Exécutez le binaire google-authenticator pour créer une nouvelle clé secrète dans votre répertoire domestique. Ces paramètres seront stockés dans ~/.google_authenticator .
Si votre système prend en charge la bibliothèque "libqrencode", vous serez affiché un QRCODE que vous pouvez analyser à l'aide de l'application Android "Google Authenticator".
Si votre système n'a pas cette bibliothèque, vous pouvez soit suivre l'URL que google-authenticator sort, soit vous devez entrer manuellement la clé secrète alphanumérique dans l'application Android "Google Authenticator".
Dans les deux cas, après avoir ajouté la clé, cliquez et tendez jusqu'à ce que le menu contextuel affiche. Vérifiez ensuite que la valeur de vérification de la clé correspond (cette fonctionnalité peut ne pas être disponible dans toutes les versions de l'application Android).
Chaque fois que vous vous connectez à votre système, vous serez désormais invité à votre code TOTP (mot de passe à temps basé sur le temps) ou à HOTP (compteur), en fonction des options données à google-authenticator , après avoir entré votre ID utilisateur normal et le mot de passe du compte Unix normal.
Au cours du processus de déploiement initial, vous pourriez constater que tous les utilisateurs n'ont pas encore créé une clé secrète. Si vous souhaitez toujours qu'ils puissent vous connecter, vous pouvez passer l'option "Nullok" sur la ligne de commande du module:
auth required pam_google_authenticator.so nullok
Si votre système chiffre les répertoires domestiques jusqu'à ce que vos utilisateurs aient entré leur mot de passe, vous devez soit réorganiser les entrées du fichier de configuration PAM pour décrypter le répertoire domestique avant de demander le code OTP, ou que vous devez stocker le fichier secret dans Un emplacement non standard:
auth required pam_google_authenticator.so secret=/var/unencrypted-home/${USER}/.google_authenticator
serait un choix possible. Assurez-vous de définir les autorisations appropriées. Vous devez également dire à vos utilisateurs de déplacer manuellement leur fichier .google_authenticator à cet emplacement.
En plus de "$ {user}", l'option secret= reconnaît également "~" et ${HOME} en tant que courtes et courtes pour le répertoire domestique de l'utilisateur.
Lorsque vous utilisez l'option secret= , vous souhaiterez peut-être également définir l'option user= . Ce dernier oblige le module PAM à passer à un ID utilisateur codé dur dédié avant de faire des opérations de fichiers. Lorsque vous utilisez l'option user= , vous ne devez pas inclure "~" ou "$ {home}" dans le nom de fichier.
L'option user= peut également être utile si vous souhaitez authentifier les utilisateurs qui n'ont pas de comptes UNIX traditionnels sur votre système.
Voir "Répertoires de maison chiffrés", ci-dessus.
Remplace l'invite de jeton par défaut. Si vous souhaitez inclure des espaces dans l'invite, enveloppez l'ensemble de l'argument entre crochets:
auth required pam_google_authenticator.so [authtok_prompt=Your secret token: ]
Forcez le module PAM à passer à un ID utilisateur à code dur avant de faire des opérations de fichiers. Couramment utilisé avec secret= .
Option dangereuse!
Par défaut, le module PAM exige que le fichier Secrets soit détenu la connexion de l'utilisateur (ou si user= est spécifié, détenue par cet utilisateur). Cette option désactive cette vérification.
Cette option peut être utilisée pour permettre aux démons de ne pas s'exécuter en tant que root pour toujours gérer les fichiers de configuration qui ne sont pas appartenant à cet utilisateur, par exemple détenus par les utilisateurs eux-mêmes.
Option dangereuse!
Par défaut, le module PAM exige que le fichier secrets ne soit lisible que par le propriétaire du fichier (mode 0600 par défaut). Dans les situations où le module est utilisé dans une configuration non défaut, un administrateur peut avoir besoin de plus d'autorisations de fichiers clémente ou d'un paramètre spécifique pour leur cas d'utilisation.
Activez plus de messages de journal verbeux dans syslog.
Certains clients PAM ne peuvent pas inciter l'utilisateur à plus que le mot de passe. Pour contourner ce problème, ce module PAM prend en charge l'empilement. Si vous transmettez l'option forward_pass , le module pam_google_authenticator interroge l'utilisateur pour le mot de passe système et le code de vérification dans une seule invite. Il transfère ensuite le mot de passe système vers le module PAM suivant, qui devra être configuré avec l'option use_first_pass .
À son tour, le module pam_google_authenticator prend également en charge les options standard use_first_pass et try_first_pass . Mais la plupart des utilisateurs n'auraient pas besoin de définir ceux sur le pam_google_authenticator .
Si vous découvrez que votre code TOTP ne fonctionne jamais, c'est le plus souvent le résultat de l'horloge sur votre serveur différent de celui de votre appareil Android. Le module PAM tente de compenser le biais de temps. Vous pouvez l'enseigner sur la quantité de biais que vous vivez, en essayant de le enregistrer trois fois de suite. Assurez-vous d'attendre toujours les 30s (mais pas plus), afin d'obtenir trois codes TOTP distincts.
Certains administrateurs préfèrent que Time Skew n'est pas ajusté automatiquement, car cela entraîne une configuration système légèrement moins sécurisée. Si vous souhaitez le désactiver, vous pouvez le faire sur la ligne de commande du module:
auth required pam_google_authenticator.so noskewadj
N'incrémentez pas le compteur pour les tentatives de HOTP défaillantes. Normalement, vous devez définir cette tentative de mot de passe, ainsi échoué d'un attaquant sans jeton, ne verrouillez pas l'utilisateur autorisé.
Permettez aux utilisateurs de se connecter sans OTP, s'ils n'ont pas encore configuré OTP.
PAM nécessite au moins une réponse SUCCESS d'un module, et nullok fait dire ce IGNORE . Cela signifie que si cette option est utilisée au moins un autre module doit avoir dit SUCCESS . Une façon de le faire est d'ajouter auth required pam_permit.so à la fin de la configuration PAM.
Par défaut, le module PAM ne fait pas écho au code de vérification lorsqu'il est entré par l'utilisateur. Dans certaines situations, l'administrateur pourrait préférer un comportement différent. Passez l'option echo_verification_code au module afin d'activer l'écho.
Si vous souhaitez des codes de vérification basés sur un compteur au lieu de fondé dans le temps, utilisez le binaire google-authenticator pour générer une clé secrète dans votre répertoire domestique avec la bonne option. Dans ce mode, la biais d'horloge n'est pas pertinente et l'option de taille de fenêtre s'applique désormais au nombre de codes au-delà de celui qui serait accepté, pour réduire les problèmes de synchronisation.
S'il est présent et non nul, assurez-vous une période de grâce pendant laquelle un deuxième code de vérification ne sera pas demandé. Essayez de définir des secondes à 86400 pour permettre une journée complète entre les codes de demande; ou 3600 pendant une heure.
Cela fonctionne en ajoutant une paire (IP d'adresse IP, horodatage) au fichier de sécurité après une connexion réussie de mots de passe à temps; Seules les dix dernières adresses IP distinctes sont suivies.
Option dangereuse!
Avec cette option, un attaquant ayant la possibilité de remplir le système de fichiers (serveur d'inondation avec des demandes Web, ou s'ils ont un compte, remplissez simplement le disque) peut forcer une situation où des mots de passe à temps peuvent être réutilisés, battant le but de " une fois ".
Par défaut, si l'option grace_period est définie, le module PAM nécessite un espace libre pour stocker l'adresse IP et l'horodatage de la dernière connexion. Il pourrait empêcher l'accès si un serveur n'a pas d'espace libre ou en cas d'erreur de fichier de configuration de mise à jour. Avec l'option allow_readonly , vous pouvez ignorer toutes les erreurs qui pourraient se produire lors de la mise à jour du fichier de configuration.
