Linux d'authentification des utilisateurs à distance SKZ. CryptoPro JCP sous Linux
Nous étions récemment en train de modifier un mot de passe utilisateur sous Linux lorsque nous avons rencontré une erreur : erreur de manipulation du jeton d'authentification.
Nous avons utilisé la commande passwd normale pour changer le mot de passe et cela nous a donné cette erreur et le mot de passe n'a pas été modifié.
Sudo passwd my_user_name Modification du mot de passe de l'utilisateur my_user_name Modification du mot de passe pour tecmint (actuel) Mot de passe UNIX : passwd : erreur de manipulation du jeton d'authentification passwd : mot de passe inchangé
Correction de l'erreur de manipulation du jeton d'authentification dans Ubuntu
« Erreur de manipulation du jeton d'authentification » signifie que, pour une raison quelconque, la modification du mot de passe a échoué.
Il peut y avoir plusieurs raisons à cela. DANS cas simples vous verrez la cause première du problème dans la sortie elle-même. Par exemple, si vous n'avez pas fourni de mot de passe, vous devriez le voir dans une erreur :
Aucun mot de passe fourni mot de passe : erreur de manipulation du jeton d'authentification mot de passe : mot de passe inchangé
De même, si la nouvelle saisie du mot de passe ne correspond pas, cette information s'affichera également :
Désolé, les mots de passe ne correspondent pas. passwd : erreur de manipulation du jeton d'authentification passwd : mot de passe inchangé
C'est facile car vous savez ce qui a causé le problème et pouvez prendre des mesures correctives en fonction de cela. Mais vous n'aurez peut-être pas toujours de la chance, car dans certains cas, vous n'en verrez aucun. informations utiles, seulement une erreur.
Examinons certains de ces cas et résolvons ce problème.
Méthode 1
Si vous connaissez la structure des répertoires Linux, vous savez que le répertoire /etc/shadow stocke le mot de passe dans un format crypté ainsi que d'autres informations sur les utilisateurs et leurs mots de passe.
C'est pourquoi vous devez vous assurer que vous disposez des autorisations nécessaires pour lire et écrire dans ce fichier. Puisque vous allez modifier le mot de passe en tant que superutilisateur, ce fichier doit disposer des autorisations de lecture et d'écriture pour root.
Si ce n'est pas le cas, vous devez définir la bonne résolution :
Sudo chmod 640 /etc/shadow
Méthode 2
La méthode 1 fonctionnera dans la plupart des cas. Mais dans notre cas, nous avons dû remonter la partition racine avec les autorisations de lecture et d'écriture. Nous avons essayé de réinitialiser le mot de passe administrateur dans Ubuntu.
Mount -rw -o remonter /
Dans de rares cas, votre disque peut être si plein que vous ne pourrez apporter aucune modification au fichier /etc/shadow. Mais si tel est le cas, vous serez alors confronté à de nombreux autres problèmes.
Est-ce que cela a fonctionné pour vous ?
Nous avons partagé ce qui a fonctionné pour nous et nous ne pouvons qu'espérer que cela fonctionnera pour vous aussi. L'avez-vous fait ? Quelle méthode a fonctionné pour vous ? Mentionnez-le dans les commentaires.
À partir de 2020, l'utilisation du cryptage conformément à GOST R 34.10-2001 sera interdite, ce qui signifie que toutes les organisations qui interagissent avec les agences gouvernementales seront obligées de mettre en œuvre de toute urgence la prochaine norme - 2012. Si vous travaillez dans l'un d'entre eux, ne passez pas à côté : dans cet article, nous expliquerons comment résoudre le problème en utilisant un serveur sur CentOS 7 et le package CryptoPro JCP.
Si c’est la première fois que vous entendez parler de tout cela, voici un petit rappel historique.
En 1994, le FSB a élaboré un certain nombre de normes et de mesures destinées à protéger l'échange de documents entre les organisations et les autres participants à ce processus. L'une de ces mesures de sécurité était la signature numérique électronique des documents, et l'une des normes était GOST R 34.10-94, qui décrit l'algorithme de génération et de vérification électronique. signature numérique. Adopté et mis en vigueur par le décret de la Norme d'État de Russie du 23 mai 1994, numéro 154, il a fonctionné jusqu'en 2001.
Il a été remplacé par le célèbre GOST R 34.10-2001 - une norme améliorée conçue pour assurer une plus grande stabilité de l'algorithme. Mais le temps ne s'arrête pas, les algorithmes et les méthodes de protection cryptographique changent, et onze ans plus tard, GOST R 34.10-2001 est remplacé par GOST R 34.10-2012.
Dans la nouvelle norme, la première version des exigences relatives aux paramètres reste la même. La longueur de la clé secrète est d'environ 256 bits, et il est possible d'utiliser une fonction de hachage avec une longueur de code de hachage de 256 ou 512 bits. La principale différence entre la nouvelle norme réside dans les options avec paramètres supplémentaires et des schémas, y compris le hachage selon la norme GOST R 34.11-2012 « Stribog ».
INFOS
Stribog est le dieu des anciens Slaves, qui protège les vents, la météo et tout ce qui concerne l'espace aérien. Peut-être technologies cloud Même. En savoir plus sur ce chiffre dans les articles « » et « ».
En février 2014, le FSB a annoncé le début de la transition vers l'utilisation de la nouvelle norme nationale GOST R 34.10-2012 dans les moyens signature électronique pour les informations qui ne contiennent pas d'informations constituant un secret d'État. Le document numéro 149/7/1/3-58 du 31 janvier 2014 « Sur la procédure de transition vers l'utilisation de nouvelles normes de signature numérique et fonctions de hachage » a été publié, il a établi les exigences suivantes ;
- Après le 31 décembre 2013, cesser de certifier la conformité des outils de signature électronique aux exigences relatives aux outils de signature électronique approuvées par l'arrêté n° 796 du FSB de Russie du 27 décembre 2011, si ces outils ne prévoient pas la mise en œuvre de fonctions conformément avec GOST R 34.10-2012.
- Après le 31 décembre 2018, interdire l'utilisation de GOST R 34.10-2001 pour générer une signature électronique.
Le ministère des Communications a même créé un plan pour la transition vers la norme (PDF). Cependant, dans la pratique, il s'est avéré que tout n'est pas si simple et la transition a dû être reportée au 31 décembre 2019. Les raisons sont les suivantes.
- De nombreuses autorités étatiques et municipales ne sont pas prêtes à passer à la nouvelle norme de signature électronique GOST-2012 en raison du manque de support au niveau logiciel.
- Pour émettre des certificats d'un nouveau type, vous avez besoin d'un équipement prenant en charge le nouveau GOST et d'un certificat de l'autorité de certification principale généré à l'aide de GOST-2012. Les centres de certification ne l'ont reçu qu'à l'été 2018. Un délai supplémentaire est nécessaire pour délivrer des certificats à tous les utilisateurs.
Il existe désormais deux normes de protection cryptographique utilisées pour le fonctionnement des signatures numériques, mais ceux qui utilisent GOST-2001 doivent agir de toute urgence. L'hiver, comme on dit, arrive, ce qui signifie qu'une série de tests nous attendent lors de la mise en œuvre du support GOST-2012.
Je vais vous expliquer comment déployer un outil CIPF certifié FSB (CryptoPro JCP) sur Serveur Linux exécutant Java JDK. D'ailleurs, si vous utilisez toujours GOST-2001, il y en a un merveilleux sur le site CryptoPro, je vous conseille de le lire, ce ne sera pas superflu.
Tous les flux de documents entre les participants à l'échange s'effectuent selon le principe SMEV (système d'interaction électronique interministérielle). Une application peut participer à un tel système, mais elle peut ne pas y participer du tout ; cela ne change rien au principe de l'échange de documents. Pour faciliter la compréhension, j'ai dessiné un petit schéma.
Tarifs
Comme toujours, la question des licences se pose solution logicielle. CryptoPro JCP n'est pas bon marché, et si un poste de travail coûte 1 200 roubles, les licences de serveur sont beaucoup plus chères - environ 30 000 pour chaque cœur (ou deux cœurs Processeur Intel avec Hyper Threading désactivé).
Installation et configuration d'un fournisseur de cryptomonnaie
Dans les exemples, j'utiliserai machine virtuelle avec CentOS 7, mais votre choix n'est pas limité matériel et distribution Linux. Toutes les actions et commandes seront les mêmes.
Tout d'abord, créons utilisateur local, sous lequel fonctionnera le logiciel qui utilise la signature de documents.
$ sudo useradd -d /opt/user -p<Тут указываем пароль>-s /bin/bash utilisateur ; sudo grep utilisateur /etc/passwd
Installons correctement le JDK Java. Téléchargez la distribution requise.
$ wget --header "Cookie : oraclelicense=a" --content-disposition http://download.oracle.com/otn-pub/java/jdk/8u191-b12/2787e4a523244c269598db4e85c51e0c/jdk-8u191-linux-x64.tar .gz -O jdk-8u191-linux-x64.tar.gz
Décompressez l'archive et vérifiez si le dossier Java est prêt à être copié.
$tar zxvf jdk-8u191-linux-x64.tar.gz; ls -al;
Copiez le dossier dans la section du logiciel d'application. J'utilise habituellement /opt .
$ sudo cp -rf jdk1.8.0_191 /opt/
Nous vérifions qu'il a été copié correctement. Si nécessaire, remplacez le propriétaire du dossier par root.
$ ls -al /opt/jdk1.8.0_191/ $ sudo chown -R root:root /opt/jdk1.8.0_191/; cd /opt/jdk1.8.0_191/; ls -al;
Nous nous inscrivons variables d'environnement pour Java JDK pour tous les utilisateurs par défaut.
$ sudo vi /etc/profile.d/oracle.sh
Nous écrivons ce qui suit dans le fichier :
Exporter JAVA_HOME=/opt/jdk1.8.0_191 exporter JRE_HOME=/opt/jdk1.8.0_191/jre exporter PATH=$PATH:/opt/jdk1.8.0_191/bin:/opt/jdk1.8.0_191/jre/bin
Si le serveur dispose de plusieurs versions du JDK Java, il est alors nécessaire d'enregistrer des alternatives pour nouvelle version.
$ alternatives sudo --install /usr/bin/java java /opt/jdk1.8.0_191/bin/java 2 $ alternatives sudo --install /usr/bin/jar jar /opt/jdk1.8.0_191/bin/jar 2 $ alternatives sudo --install /usr/bin/javac javac /opt/jdk1.8.0_191/bin/javac 2 $ alternatives sudo --set jar /opt/jdk1.8.0_181/bin/jar $ alternatives sudo --set jar /opt/jdk1.8.0_191/bin/jar $ alternatives sudo --set javac /opt/jdk1.8.0_191/bin/javac $ alternatives sudo --config java
Dans le menu, sélectionnez l'option 2 (ou celle qui conduira à l'utilisation d'une version plus récente de Java). N'oubliez pas de corriger les droits sur JRE systemPrefs.
$ sudo chmod 777 -R /opt/jdk1.8.0_191/jre/.systemPrefs
Vérification version installée Java.
$java-version
version java "1.8.0_191"
Environnement d'exécution Java(TM) SE (build 1.8.0_191-b12)
Machine virtuelle de serveur Java HotSpot(TM) 64 bits (build 25.191-b12, mode mixte)
Copiez le dossier contenant le kit de distribution CryptoPro JCP dans la section du logiciel d'application.
$ sudo cp -rf jcp-2.0.40035 /opt/
Nous vérifions que tout a été copié correctement.
$ ls -al /opt/jcp-2.0.40035/
Nous accordons le droit d'exécuter des scripts.
$ sudo chmod +x /opt/jcp-2.0.40035/*.sh
Nous vérifions le propriétaire et les droits sur le dossier, il doit être root. Allons-y.
$ ls -al /opt/jcp-2.0.40035/; cd /opt/jcp-2.0.40035/;
Pour éviter les problèmes d'installation, vérifiez le nombre de cœurs sur le processeur et vérifiez la licence. Vous pouvez connaître le nombre de cœurs avec la commande nproc.
Passons à l'installation du fournisseur de crypto JCP. Lors de l'installation, vous devrez répondre à un certain nombre de questions.
La suite est disponible uniquement pour les membres
Option 1. Rejoignez la communauté « site » pour lire tous les documents sur le site
L'adhésion à la communauté dans la période spécifiée vous donnera accès à TOUS les documents Hacker, augmentera votre remise cumulée personnelle et vous permettra d'accumuler une note professionnelle Xakep Score !
- Système ROSA Enterprise Linux installé Version du serveur pas inférieur à 6,8 dans la configuration « ROSA Standard Server »
- Accès aux référentiels
- Appareil Rutoken EDS/Rutoken EDS Flash/Rutoken EDS SC avec un lecteur. Un certificat doit être écrit sur l'appareil
Pour accéder aux référentiels, obtenez une clé auprès du service d'assistance et exécutez la commande suivante avec les droits d'administrateur :
Écho<ключ>> /etc/rosa-support-id-server
Applicabilité
Les instructions décrivent l'installation et la configuration des utilitaires ROSA Enterprise Linux Server requis pour l'authentification à l'aide de la signature numérique Rutoken. L'exemple utilise l'architecture AMD64 ; pour un système 32 bits, toutes les actions seront similaires, jusqu'aux noms de dossiers.
Après avoir terminé la procédure ci-dessous, l'authentification à l'aide de Rutoken EDS deviendra possible, mais ne sera pas obligatoire.
Installation des composants
Installez les utilitaires requis et supprimez les utilitaires en conflit (droits d'administrateur requis) :
Su miam installer ccid opensc pam_pkcs11 gdm-plugin-smartcard miam supprimer coolkey
Installez la bibliothèque PKCS#11 pour Rutoken EDS (il est important d'installer la bibliothèque après avoir installé les utilitaires) :
- Accédez au site Web de Rutoken : https://www.rutoken.ru/support/download/pkcs/.
- Ouvrez l'onglet « Utilisateurs GNU/Linux » et cliquez sur le lien « Bibliothèque rtPKCS11ecp pour GNU/Linux RPM 64 bits (x64) ».
- Téléchargez et installez le package (mot de passe administrateur requis).
Paramètres
Vérification de l'affichage de l'appareil dans le système et de la présence des informations nécessaires sur celui-ci
- Courir PCCD(droits d'administrateur requis) :
- Terminer un processus existant PCCD, s'il y en avait un :
A partir de ce moment, le token doit être inséré dans l'emplacement approprié.
- Courir:
- Ouvrez un onglet ou une fenêtre de terminal distinct et exécutez-y la commande suivante :
La sortie doit afficher les paramètres et le nom de l'appareil. Un exemple de sortie est présenté ci-dessous.
- Vérifiez que le jeton contient les informations requises à l'aide de la commande suivante (le mot de passe du jeton est requis) :
La sortie doit contenir un objet de certificat . Les paramètres tels que l'ID et l'étiquette peuvent différer de ceux indiqués ci-dessous.
Ajout d'un certificat à Trusted
- Créez une base de données de certificats de confiance (droits d'administrateur requis) :
- Copiez le certificat du jeton (le mot de passe du jeton est requis. Le paramètre ID peut être extrait de la sortie de la commande pkcs11-tool --module /usr/lib64/librtpkcs11ecp.so -O -l) :
- Ajoutez le certificat à ceux de confiance (droits d'administrateur requis) :
Modification des fichiers de configuration
Vous aurez besoin des droits d'administrateur pour modifier les fichiers de configuration.
pam_pkcs11.conf
- Créez (par exemple, sur votre bureau) un fichier texte pam_pkcs11.conf avec le contenu suivant :
- Placez le fichier dans le répertoire /etc/pam_pkcs11/ :
authentification système
- Connectez le module au système d'autorisation PAM :
- Ouvrez le fichier d'authentification système dans un éditeur nano ou mcédit:
- Ajoutez la ligne suivante en haut :
- Enregistrez le fichier (
subject_mapping
- Exécutez les commandes :
- Copiez le résultat de la commande précédente dans /etc/pam_pkcs11/subject_mapping et spécifiez à quel utilisateur appartient le certificat.
La ligne de configuration ressemble à :
Sortie de la commande pkcs11_inspect -><имя_пользователя>
Vérification de l'authentification via la console
- Ouvrez une nouvelle fenêtre ou un nouvel onglet de console.
- Exécutez la commande su<имя_пользователя>(le nom d'utilisateur est répertorié dans subject_mapping).
Exemple de sortie :
Après avoir vérifié l'opération d'authentification via la console, vous pouvez supprimer le mode débogage. Pour ce faire, dans le fichier /etc/pam.d/sysauth dans la ligne ajoutée supprimez le mot debug , et dans le fichier /etc/pam_pkcs11/pam_pkcs11.conf mettez debug false au lieu de true .
Configurer un verrouillage d'écran
- Ouvrez le fichier pkcs11_eventmgr pour le modifier (droits d'administrateur requis) :
Après édition, le fichier de configuration devrait ressembler à ceci :
Pkcs11_eventmgr ( # Exécuter en arrière-plan ? Implique debug=false si vrai démon = true ; # afficher les messages de débogage ? debug = false ; # temps d'interrogation en secondes polling_time = 1 ; # temps d'expiration en secondes # par défaut = 0 (pas d'expiration) expire_time = 0; # module pkcs11 à utiliser pkcs11_module = /usr/lib64/librtpkcs11ecp.so; # # liste des événements et des actions # Événement de carte inséré card_insert ( # que faire si une action échoue ? # ignorer : passer à l'action suivante # return : fin de la séquence d'action # quit : fin du programme on_error = ignorer ) # La carte a été supprimée, événement card_remove ( on_error = ignorer; action = "gdmflexiserver"; ) # Trop de temps, la carte a été supprimée event expire_time ( on_error = ignorer; action = "/bin / FAUX"; ) )
- Ajouter un utilitaire pkcs11_eventmgr au démarrage. Pour cela, éditez le fichier .bash_profile de l'utilisateur authentifié :
- Ajouter une ligne à la fin du fichier qui s'exécute pkcs11_eventmgr.
Exemple de fichier .bash_profile après édition :
Lorsque vous sélectionnez l'authentification par jeton, l'écran ressemblera à ceci.
L'authentification à deux facteurs (2FA) est une méthode d'authentification qui vous permet de vous connecter compte soit l'appareil nécessite plusieurs informations. En plus de la combinaison nom d'utilisateur et mot de passe, 2FA nécessite que l'utilisateur saisisse Informations Complémentaires, tel qu'un mot de passe à usage unique (OTP, tel qu'un code de vérification à six chiffres).
En général, la 2FA demande à l’utilisateur de saisir différents types d’informations :
- Quelque chose que l'utilisateur connaît (comme un mot de passe)
- Quelque chose que possède l'utilisateur (par exemple, un code de vérification généré par une application spéciale - un authentificateur).
2FA est un sous-ensemble de l'authentification multifacteur (MFA). La méthode MFA, en plus de ce que l’utilisateur sait et de ce qu’il possède, requiert quelque chose qu’il est. Il s’agit de données biométriques : empreinte digitale ou reconnaissance vocale, etc.
2FA aide à protéger le processus d'authentification pour un service ou un appareil spécifique : même si le mot de passe est compromis, l'attaquant aura également besoin du code de sécurité, et cela nécessite l'accès à l'appareil de l'utilisateur sur lequel se trouve l'application d'authentification. Pour cette raison, de nombreux services en ligne offrent la possibilité d'activer 2FA pour les comptes d'utilisateurs afin d'augmenter la sécurité des comptes au niveau de l'authentification.
Dans ce didacticiel, vous apprendrez comment configurer 2FA à l'aide du module Google PAM pour un utilisateur non root dans Ubuntu 18.04. Puisque vous configurez 2FA pour un utilisateur non root, si vous êtes bloqué, vous pourrez toujours accéder à l'ordinateur à partir de votre compte root. Les instructions contenues dans le manuel sont assez générales, elles peuvent donc être appliquées à la fois aux serveurs et aux installations de bureau, locales et distantes.
Exigences
- Serveur Ubuntu 18.04 ou ordinateur de bureau environnement de travail. Le serveur Ubuntu 18.04 doit être configuré avec .
- Un authentificateur installé sur l'appareil mobile (par exemple, Google Authenticator ou Authy). Avec lui, vous scannerez les codes de sécurité QR.
1 : Installation du module Google PAM
Pour configurer 2FA sur Ubuntu 18.04, vous devez installer le module Google PAM pour Linux. Le module d'authentification enfichable (PAM) est un mécanisme d'authentification utilisé par Linux. Le module Google PAM permettra à votre utilisateur de compléter l'authentification 2FA à l'aide des codes OTP générés par Google.
Connectez-vous d'abord en tant qu'utilisateur sudo que vous avez créé lors de configuration initiale serveurs :
ssh 8host@votre_serveur_ip
Mettez à jour l'index du package Ubuntu pour obtenir dernière version authentificateur :
sudo apt-get mise à jour
Après avoir mis à jour les référentiels, installez la dernière version du module PAM :
sudo apt-get install libpam-google-authenticator
Il s'agit d'un très petit package sans dépendances, l'installation prendra donc quelques secondes. Dans la section suivante, nous configurerons 2FA pour l'utilisateur sudo.
2 : Configurer l’authentification à deux facteurs
Maintenant que vous avez installé le module PAM, exécutez-le pour générer un code QR pour l'utilisateur connecté. Cela générera le code, mais l'environnement Ubuntu ne nécessitera pas 2FA tant que vous ne l'activerez pas.
Exécutez la commande google-authenticator pour lancer et configurer le module PAM :
authentificateur Google
L'équipe vous posera quelques questions sur la configuration. Il vous demandera d’abord si vous souhaitez que les jetons soient limités dans le temps. Les jetons d'authentification à durée limitée expirent après un certain intervalle (la valeur par défaut est de 30 secondes sur la plupart des systèmes). Les jetons à durée limitée sont plus sécurisés que les jetons à durée non limitée, et la plupart des implémentations 2FA les utilisent. Vous pouvez choisir l'une ou l'autre option ici, mais nous vous recommandons de choisir Oui et d'utiliser des jetons d'authentification à durée limitée :
Voulez-vous que les jetons d'authentification soient basés sur le temps (o/n) o
En répondant y à cette question, vous verrez plusieurs lignes de sortie dans la console :
- Code QR : Il s'agit d'un code qui doit être scanné à l'aide d'une application d'authentification. Une fois que vous l'aurez scanné, l'application générera un nouvel OTP toutes les 30 secondes.
- Clé secrète : ceci manière alternative paramètres de l'application d'authentification. Si vous utilisez une application qui ne prend pas en charge la numérisation QR, vous pouvez saisir une clé secrète pour configurer l'authentificateur.
- Code de vérification : il s'agit du premier code à six chiffres généré par ce code QR particulier.
- Codes à gratter d'urgence. Ce sont des jetons à usage unique (également appelés codes de sauvegarde) et vous permettront de compléter l'authentification 2FA si vous perdez votre appareil d'authentification. Conservez ces codes dans un endroit sûr pour éviter la suspension du compte.
Une fois que vous avez configuré votre application d'authentification et enregistré votre codes de sauvegarde dans un emplacement sécurisé, le programme vous demandera si vous souhaitez mettre à jour le fichier de configuration. Si vous sélectionnez n, vous devrez réexécuter le programme d'installation. Tapez y pour enregistrer les modifications et continuer :
Voulez-vous que je mette à jour votre fichier "~/.google_authenticator" (o/n) o
Ensuite, le programme vous demandera si vous souhaitez empêcher l'utilisation des codes d'authentification plus d'une fois. Par défaut, vous ne pouvez utiliser chaque code qu'une seule fois, même si 30 secondes ne se sont pas écoulées depuis sa création. Il s’agit du choix le plus sûr car il empêche les attaques par rejeu d’un attaquant qui aurait réussi d’une manière ou d’une autre à obtenir votre code de vérification utilisé. Pour cette raison, il est préférable d’interdire l’utilisation des codes plusieurs fois. Répondez y pour éviter les utilisations multiples du même token :
Voulez-vous interdire plusieurs utilisations de la même authentification
jeton? Cela vous limite à une connexion toutes les 30 secondes environ, mais cela augmente
vos chances de remarquer ou même de prévenir les attaques de l'homme du milieu (o/n) o
Vous devez ensuite préciser si vous souhaitez que les jetons d'authentification soient acceptés quelque temps après leur date d'expiration normale. Les codes sont très sensibles au temps, ils peuvent donc ne pas fonctionner si vos appareils ne sont pas synchronisés. Cette option contourne ce problème en augmentant la période de validité par défaut des codes de vérification afin que les codes d'authentification soient acceptés dans tous les cas (même si vos appareils sont temporairement désynchronisés). Il est préférable de vous assurer que l'heure de tous vos appareils est synchronisée, car répondre oui réduira légèrement la sécurité du système. Répondez n à cette question pour éviter d'augmenter la date d'expiration du token :
Par défaut, les jetons sont valables 30 secondes et afin de compenser
décalage horaire possible entre le client et le serveur, nous autorisons un supplément
jeton avant et après l’heure actuelle. Si vous rencontrez des problèmes avec les pauvres
synchronisation de l'heure, vous pouvez agrandir la fenêtre par rapport à sa valeur par défaut
durée de 1h30 à environ 4min. Voulez-vous le faire (o/n) n
La dernière question est de savoir si vous souhaitez activer une limite sur le nombre de tentatives de connexion. Cela empêchera l'utilisateur de faire plus de trois tentatives de connexion infructueuses en 30 secondes, renforçant ainsi la sécurité du système. Activez cette restriction en répondant y :
Si l'ordinateur auquel vous vous connectez n'est pas protégé contre la force brute
tentatives de connexion, vous pouvez activer la limitation de débit pour le module d'authentification.
Par défaut, cela limite les attaquants à pas plus de 3 tentatives de connexion toutes les 30 secondes.
Voulez-vous activer la limitation de débit (o/n) o
Vous avez configuré et généré des codes 2FA à l'aide du module PAM. Vous devez maintenant activer 2FA dans votre environnement.
3 : Activer 2FA dans Ubuntu
Le module Google PAM génère désormais des codes 2FA pour votre utilisateur, mais le système Ubuntu ne sait pas encore qu'il doit utiliser les codes dans le processus d'authentification. À ce stade, vous devez mettre à jour votre configuration Ubuntu pour configurer la prise en charge des jetons 2FA en plus de l'authentification de base.
Il y a deux manières ici :
- Vous pouvez exiger une authentification à deux facteurs chaque fois qu'un utilisateur se connecte et chaque fois que l'utilisateur demande des droits sudo.
- Vous ne pouvez exiger que 2FA lors de la connexion, puis seul le mot de passe de l'utilisateur sera requis lorsque vous serez invité à indiquer les droits sudo.
La première option serait idéale pour un environnement partagé où il est souhaitable de protéger toutes les actions nécessitant les privilèges sudo. La deuxième approche est plus pratique pour un environnement de bureau local dans lequel vous êtes le seul utilisateur du système.
Note Remarque : Si vous activez 2FA sur une machine distante à laquelle vous accédez via SSH, vous devrez suivre les étapes deux et trois du manuel avant de continuer. Le reste des étapes de ce didacticiel s'applique à toutes les installations Ubuntu, mais les environnements distants nécessitent paramètres supplémentaires afin que le service SSH connaisse 2FA.
Si vous n'utilisez pas SSH pour accéder installer Ubuntu, vous pouvez passer directement au reste des étapes de ce didacticiel.
Inviter 2FA lors de la connexion et de l'élévation des privilèges sudo
Pour que le système utilise 2FA lors de la connexion et des demandes d'élévation de privilèges ultérieures, vous devez modifier le fichier /etc/pam.d/common-auth en ajoutant une ligne à la fin du fichier existant.
Le fichier d'authentification commune s'applique à tous les mécanismes d'authentification du système, quel que soit l'environnement utilisé. Cela s'applique également aux demandes d'authentification qui se produisent après la connexion de l'utilisateur, par exemple lorsqu'il est invité à fournir les droits sudo lors de l'installation d'un nouveau package à partir d'un terminal.
Ouvrez le fichier :
sudo nano /etc/pam.d/common-auth
A la fin du fichier ajoutez :
...
# et voici plus de modules par package (le bloc "Supplémentaire")
session requise pam_unix.so
Cette ligne permet à l'authentification Ubuntu de prendre en charge 2FA lors de la connexion via le module Google PAM. L'option nullok permet aux utilisateurs existants de se connecter même s'ils n'ont pas configuré l'authentification 2FA pour leur compte. En d'autres termes, les utilisateurs qui ont configuré 2FA devront saisir un code d'authentification lors de leur prochaine connexion, tandis que les utilisateurs qui n'ont pas exécuté la commande google-authenticator pourront se connecter avec leurs informations d'identification standard jusqu'à ce qu'ils aient défini jusqu'à 2FA.
Enregistrez et fermez le fichier.
Inviter 2FA uniquement lors de la connexion
Si vous souhaitez uniquement que 2FA soit demandé lors de la connexion à un environnement de bureau, vous devrez modifier le fichier de configuration du gestionnaire de bureau que vous utilisez. Le nom du fichier de configuration est généralement le même que le nom de l'environnement de bureau. Par exemple, le fichier de configuration de gdm (l'environnement Ubuntu par défaut commençant par Ubuntu 16.04) est /etc/pam.d/gdm.
Dans le cas d'un serveur sans tête (qui est serveur virtuel), vous devez plutôt modifier le fichier /etc/pam.d/common-session. Ouvrez le fichier approprié en fonction de votre environnement :
sudo nano /etc/pam.d/common-session
Ajoutez les lignes en surbrillance à la fin du fichier :
#
# /etc/pam.d/common-session - modules liés à la session communs à tous les services
#
...
# # et voici plus de modules par package (le bloc "Supplémentaire")
session requise pam_unix.so
session facultative pam_systemd.so
# fin de la configuration de pam-auth-update
authentification requise pam_google_authenticator.so nullok
Ubuntu nécessitera désormais 2FA lorsqu'un utilisateur se connecte au système via la ligne de commande (soit localement, soit à distance via SSH), mais cela ne s'appliquera pas à l'exécution de commandes avec sudo.
Vous avez configuré Ubuntu pour prendre en charge 2FA. Il est maintenant temps de tester la configuration et de vous assurer que lorsque vous vous connectez à votre système Ubuntu, un code de sécurité vous sera demandé.
4 : Test de l'authentification à deux facteurs
Auparavant, vous configuriez 2FA pour générer des codes toutes les 30 secondes. Essayez maintenant de vous connecter à votre environnement Ubuntu.
Tout d'abord, déconnectez-vous et reconnectez-vous à votre environnement Ubuntu :
ssh 8host@votre_serveur_ip
Si vous utilisez l'authentification par mot de passe, vous serez invité à saisir le mot de passe utilisateur :
Note: Si vous utilisez l'authentification par certificat sur le serveur distant, aucun mot de passe ne vous sera demandé. La clé sera envoyée et acceptée automatiquement. Il vous suffira de saisir un code de vérification.
Saisissez votre mot de passe et vous serez invité à saisir votre code 2FA :
Le code de vérification:
Après cela, vous serez connecté :
8host@votre_serveur_ip : ~#
Si 2FA a été activé uniquement à des fins de connexion, vous n'aurez plus besoin de saisir les codes de vérification 2FA jusqu'à la fin de votre session ou jusqu'à ce que vous vous déconnectiez manuellement.
Si vous avez activé 2FA via le fichier d'authentification commune, vous serez également invité à le fournir chaque fois que vous demanderez les privilèges sudo :
8host@your_server_ip : ~# sudo -s
Mot de passe sudo pour 8host :
Le code de vérification:
root@votre_serveur_ip :
Vous avez vérifié que la configuration 2FA fonctionne comme prévu. Si quelque chose s'est mal passé et que le système ne vous a pas demandé de codes de vérification, revenez à la troisième section du guide et assurez-vous d'avoir modifié fichier correct Authentification Ubuntu.
5 : Empêcher le blocage 2FA
En cas de perte ou de destruction appareil mobile il est important de fournir des méthodes sauvegarde pour restaurer l'accès à votre compte compatible 2FA. Lorsque vous configurez 2FA pour la première fois, vous disposez de plusieurs options pour restaurer l'accès après avoir été bloqué :
- Sauvegarder copie de sauvegarde vos codes de configuration secrets dans un endroit sûr. Vous pouvez le faire manuellement, mais certaines applications d'authentification comme Authy proposent des fonctionnalités de sauvegarde de code.
- Stockez vos codes de récupération dans un emplacement sécurisé en dehors de votre environnement compatible 2FA auquel vous pouvez accéder en cas de besoin.
Si, pour une raison quelconque, vous n'avez pas accès à vos options de sauvegarde, vous pouvez essayer une autre façon de restaurer l'accès à votre environnement local ou à votre serveur distant compatible 2FA.
6 : Restaurer l’accès à l’environnement local (facultatif)
Si vous avez accès physique sur la machine, vous pouvez démarrer en mode de récupération pour désactiver 2FA. Le mode de récupération est un type de cible (comme le niveau d'exécution) sous Linux utilisé pour effectuer des tâches administratives. Vous devrez modifier certains paramètres dans GRUB pour passer en mode de récupération.
Pour accéder à GRUB, redémarrez d'abord votre ordinateur :
Lorsque le menu GRUB apparaît, assurez-vous que l'entrée Ubuntu est en surbrillance. Il s'agit du nom d'installation 18.04 par défaut, mais il peut être différent si vous l'avez modifié manuellement après l'installation.
Appuyez ensuite sur la touche e de votre clavier pour modifier la configuration GRUB avant de démarrer votre système.
Allez à la fin du fichier qui apparaît et recherchez la ligne qui commence par Linux et se termine par $vt_handoff. Allez à la fin de cette ligne et ajoutez systemd.unit=rescue.target. Assurez-vous de laisser un espace entre $vt_handoff et systemd.unit=rescue.target. Cela permettra à la machine Ubuntu de démarrer en mode de récupération.
Après avoir apporté des modifications, enregistrez le fichier à l'aide de la combinaison de touches Ctrl + X. Votre machine redémarrera et vous y serez. ligne de commande. Appuyez sur Entrée pour entrer en mode de récupération.
Une fois à l'invite de commande, ouvrez le fichier de configuration de Google Authenticator, qui se trouve dans le répertoire personnel de l'utilisateur bloqué.
nano /home/8host/.google-authenticator
La première ligne de ce fichier est la clé secrète de l'utilisateur, utilisée pour configurer l'authentificateur.
Vous avez maintenant deux options :
- Vous pouvez copier la clé secrète et configurer l'authentificateur.
- Si vous souhaitez repartir sur une table rase, vous pouvez supprimer entièrement le fichier ~/.google-authenticator pour désactiver 2FA pour cet utilisateur. Après vous être reconnecté, vous pouvez à nouveau configurer 2FA et recevoir une nouvelle clé secrète.
Dans tous les cas, vous pouvez restaurer le système après avoir été bloqué par 2FA dans un environnement local à l'aide du chargeur de démarrage GRUB. Ensuite, nous vous expliquerons comment restaurer l'accès à un environnement distant bloqué.
7 : Restaurer l'accès à un environnement distant (facultatif)
Si votre compte sudoer est verrouillé dans un environnement distant, vous pouvez temporairement désactiver ou reconfigurer 2FA à l'aide de l'utilisateur root.
Connectez-vous en tant que root :
ssh root@votre_serveur_ip
Après vous être connecté, ouvrez le fichier Paramètres Google Authentificateur, qui se trouve dans le répertoire personnel de l'utilisateur bloqué :
sudo nano /home/8host/.google_authenticator
La première ligne de ce fichier est la clé secrète de l'utilisateur, dont vous avez besoin pour configurer l'authentificateur.
Vous avez maintenant deux options :
- Si vous souhaitez configurer un appareil nouveau ou effacé, vous pouvez utiliser la clé secrète pour reconfigurer l'application d'authentification.
- Si vous souhaitez repartir à zéro, vous pouvez supprimer complètement le fichier /home/8host/.google_authenticator pour désactiver 2FA pour cet utilisateur. Après vous être connecté en tant qu'utilisateur sudo, vous pouvez reconfigurer 2FA et obtenir une nouvelle clé privée.
Avec n’importe laquelle de ces options, vous pourrez récupérer d’une interdiction accidentelle de 2FA en utilisant un compte root.
Conclusion
Dans ce didacticiel, vous configurez 2FA sur une machine Ubuntu 18.04. L'authentification à deux facteurs offre une couche de protection supplémentaire pour votre compte et le système dans son ensemble. En plus de vos informations d'identification standard, vous devrez également saisir un code de vérification supplémentaire pour vous connecter. Cela empêche toute personne non autorisée d'accéder à votre compte, même si un attaquant parvient à obtenir vos informations d'identification.
Balises: ,Linux- il s'agit d'un environnement multi-utilisateurs et pour que l'utilisateur puisse commencer à travailler dans le système, il doit passer par une procédure d'authentification. PAM (Modules d'authentification enfichables) est un système (mécanisme) qui prend en charge le travail de mise en œuvre des procédures d'authentification. Avant l'apparition PAM, les développeurs de programmes liés d'une manière ou d'une autre à l'authentification ont dû adapter leur programme aux mécanismes d'authentification existants. En conséquence, si les mécanismes d'authentification changeaient, il était alors nécessaire de modifier les programmes qui les utilisaient. Un système a donc été développé PAM, qui est une « couche » entre les programmes et les mécanismes d’authentification. C'est-à-dire que maintenant les programmes d'authentification (par exemple, le programme se connecter) ne devrait pouvoir fonctionner qu'avec le système PAM. Le programme transmet PAM paramètres (par exemple, login et mot de passe) et lui (le programme) n'est plus « intéressé » par la méthode d'authentification implémentée dans le système - authentification par mot de passe ou carte à puce ou une autre méthode. Autres travaux PAM et renvoie soit le succès, soit l'échec du programme.
Regardons le système PAM plus de détails. Les principales fonctions, actions ou tâches exécutées par le système PAM- divisé en quatre groupes qui portent des noms spécifiques :
groupe authentification- ce sont des actions directement liées à l'authentification. C'est-à-dire des actions ou des fonctions qui vous permettent de déterminer que vous êtes vous-même. Il peut s'agir d'une authentification par mot de passe, d'une authentification par carte à puce, d'une authentification biométrique (empreintes digitales, etc.) et autres.
groupe compte- Il s'agit d'actions liées à la gestion du compte. Par exemple, même si vous êtes authentifié dans le système, votre compte peut être interdit de fonctionner à certaines heures de la journée. Ou autoriser la connexion en mode console, mais interdire la connexion en mode graphique. Etc.
groupe session- les actions de ce groupe allouent les ressources nécessaires au travail à l'utilisateur. L'exemple le plus simple est l'autorisation de monter des répertoires.
groupe mot de passe- les actions qui mettent en œuvre des modifications dans les données d'authentification des utilisateurs. Il s'agit le plus souvent d'actions visant à gérer les mots de passe des utilisateurs.
Toutes ces actions ou procédures (fonctions) sont implémentées sous la forme de modules distincts, qui se trouvent dans le répertoire /lib/sécurité/. Autrement dit, on peut dire qu'il existe des modules de groupe authentification, modules de groupe compte etc. En conséquence, le système PAM est modulaire et si vous devez mettre en œuvre une authentification biométrique, il vous suffit alors d'installer un module capable d'effectuer cette procédure.
Fichier de configuration du système principal PAM- c'est un fichier /etc/pam.conf. Outre le fichier /etc/pam.conf, paramètres PAM stocké dans des fichiers de répertoire /etc/pam.d/. À l'intérieur du catalogue, il y a fichiers texte qui contiennent une séquence d'actions (un certain algorithme) pour les programmes qui utilisent PAM. Par exemple, fichier /etc/pam.d/login contient l'algorithme de fonctionnement du système PAM pour le programme se connecter, et le fichier /etc/pam.d/passwd pour le programme mot de passe.
Regardons d'abord le format de fichier /etc/pam.conf. Le fichier est constitué de lignes. Le fichier peut être constitué d'une seule ligne ou de plusieurs lignes s'ajoutant à une chaîne d'actions séquentielles. Chaque ligne décrit une règle ou une étape d'une telle chaîne (algorithme). La ligne se compose de quatre champs. Le premier champ est le nom du programme auquel cette étape s'applique. Le deuxième champ est le type d'action ( authentification, compte, session, mot de passe). Le troisième champ est le champ dans lequel le comportement du système est défini PAM après avoir terminé cette étape à cette étape de l'algorithme (nous reviendrons sur cette question plus en détail ci-dessous). Le quatrième champ est le nom du fichier du module. La ligne peut également contenir certains paramètres passés au module.
Structure des fichiers situés dans le répertoire /etc/pam.d/, le même. La seule différence est l'absence du premier champ - le nom. Puisque le nom du programme est tiré du nom du fichier lui-même. Regardons un exemple d'un tel fichier. Appelons-le testpam.
authentification suffisante pam_rootok.so |
Regardons la première ligne. Champ authentification dit que la première étape est l'authentification. Le troisième champ est le module qui effectuera l'authentification et renverra le résultat de l'exécution. Dans cet exemple, le module pam_rootok.so vérifie si le compte est root ( racine). Si oui, le succès sera renvoyé (vrai), sinon, une erreur ou un échec sera renvoyé (faux). Le deuxième champ est la réaction ou l’impact du résultat sur la chaîne dans son ensemble.
La réaction peut être de quatre types : requis, requis, facultatif, suffisant. Utilisation de la ligne d'exemple authentification suffisante pam_rootok.so Voyons ce que signifient ces valeurs.
Si le deuxième champ est défini sur requis, alors cela signifie que si le module pam_rootok.so complété par une erreur, puis poursuite de l'exécution du fichier testpam le système est interrompu PAM renvoie une erreur à l'application. Si le module est retourné résultat positif, puis l'exécution de la chaîne continue.
requis semblable à requis. Si le module pam_rootok.so s'est terminé par une erreur, alors PAM renverra également une erreur, mais une fois les modules restants exécutés, c'est-à-dire que la chaîne n'est pas interrompue. Si le module renvoie un résultat positif, alors l'exécution de la chaîne continue.
suffisant- si le module pam_rootok.so a renvoyé le succès, puis le système PAM renvoie le succès à l'application et la poursuite de l'exécution de la chaîne est interrompue. En cas d'échec, la chaîne continue de s'exécuter.
facultatif- ce paramètre n'affecte en rien l'avancement de la chaîne. Indiqué pour les modules qui n'effectuent aucune action de vérification. Si le fichier ne contient que des lignes avec le paramètre facultatif, Que PAM ramènera l'application au succès.
Plus de détails sur le système PAM et le but d'une bibliothèque particulière peut être lu sur le site Web http://kernel.org/pub/linux/libs/pam/Linux-PAM-html/Linux-PAM_SAG.html. Faisons maintenant un petit exercice pratique qui nous permettra de mieux comprendre le fonctionnement du système. PAM et comment créer des fichiers de configuration.
Allez dans l'annuaire /etc/pam.d/. Copiez le fichier su dans votre répertoire personnel (afin que vous puissiez le restaurer) et supprimez le fichier dans suà partir du répertoire /etc/pam.d/. Maintenant, essayez la commande su dans le terminal pour passer en mode superutilisateur. Après avoir entré le mot de passe, le système affichera une erreur d'authentification car le fichier de configuration du programme est manquant su.
Créer un fichier /etc/pam.d/su et écrivez-y la ligne suivante :
Module pam_deny.so renvoie toujours une erreur. Quel sera le résultat ? Vérifiez-le. Et si tu remplaces requis sur requis?
Écrivons maintenant la règle suivante dans le fichier :
Module pam_wheel.so renvoie le succès si le compte utilisateur appartient au groupe roue. Si vous essayez d'exécuter la commande maintenant su, cela se terminera immédiatement par une erreur. Autrement dit, maintenant l'équipe su Seuls les utilisateurs membres du groupe pourront exécuter roue et connaître le mot de passe du compte racine. Si vous créez un groupe roue et ajoutez-y votre compte, puis la commande suça marchera.
Voici un autre exemple :
conditions d'authentification pam_wheel.so |
Essayez de répondre qui peut exécuter avec succès la commande su et que faudra-t-il faire pour cela ?
Ceci conclut l'exercice pratique (n'oubliez pas de le remettre à sa place fichier original su).
Je tiens à souligner une fois de plus que les fichiers de configuration dans le répertoire /etc/pam.d/ ne peuvent être créés que pour les fichiers qui utilisent le système. PAM. Par exemple, si vous créez un fichier /etc/pam.d/ls avec de la ficelle condition d'authentification pam_deny.so, puis la commande ls sera quand même exécuté puisqu'il n'utilise pas le système PAM. Pour vérifier si une équipe utilise le système PAM, vous pouvez utiliser la commande ldd, auquel est transmis le chemin complet du fichier de commandes en tant que paramètre. Par exemple:
Mot clé compatible il « dit » simplement que le système sera utilisé comme système d'authentification PAM.
Et encore une chose. Soyez prudent lorsque vous expérimentez PAM. Par ignorance ou négligence, vous pouvez facilement bloquer votre système. Par conséquent, avant de modifier quoi que ce soit, assurez-vous de sauvegarder les fichiers de configuration d'origine afin de pouvoir les restaurer rapidement en cas de problème.
