Guide des technologies

Sécuriser SSH sur CentOS 7 avec l'authentification à deux facteurs WiKID

8 min read Sécurité Linux Mis à jour 03 Oct 2025
SSH sécurisé sur CentOS 7 avec WiKID 2FA
SSH sécurisé sur CentOS 7 avec WiKID 2FA

Important : effectuez ces étapes depuis une console locale ou avec une autre session root ouverte. Ne fermez pas votre session SSH de secours tant que vous n’avez pas confirmé que l’authentification Radius fonctionne correctement.

Objectif et variantes de recherche

Objectif principal : configurer l’authentification à deux facteurs (2FA) pour SSH sur CentOS 7 en utilisant WiKID et pam_radius.

Variantes liées : 2FA SSH CentOS, pam_radius CentOS 7, WiKID SSH, authentification forte Linux, intégrer Radius à SSH.

Pré-requis

  • Accès root ou sudo sur le serveur CentOS 7 cible.
  • Serveur WiKID Strong Authentication opérationnel et accessible depuis la machine CentOS (IP publique/privée selon votre topologie).
  • Adresse IP ou nom d’hôte du serveur WiKID et un secret partagé pour le client réseau.
  • Connexion locale de repli (console KVM, accès physique, ou session SSH supplémentaire) pour revenir en arrière si besoin.

Termes rapides :

  • WiKID : serveur d’authentification à deux facteurs (généralement fournit les OTP et gère les tokens).
  • RADIUS : protocole d’authentification réseau utilisé ici comme relais d’authentification.
  • pam_radius : module PAM qui envoie les demandes d’authentification à un serveur RADIUS.

Vue d’ensemble de la procédure

  1. Créer un domaine sur le serveur WiKID et noter le Domain Server Code.
  2. Créer un client réseau (Network Client) sur WiKID pour chaque serveur CentOS.
  3. Installer pam_radius sur la machine CentOS et copier la bibliothèque PAM.
  4. Configurer PAM pour SSH afin d’appeler pam_radius.
  5. Ajouter l’adresse du serveur WiKID et le secret partagé dans le fichier de configuration pam_radius.
  6. Tester l’authentification, vérifier les logs et valider les comptes locaux ou LDAP.

Ajouter un domaine sur le serveur WiKID

Capture d'écran du formulaire d'ajout de domaine sur le serveur WiKID

Note : le Domain Server Code doit être l’adresse IP externe de votre serveur, avec des zéros pour compléter chaque octet en format 012345678901. Exemple : pour 54.83.0.181, utilisez 054083000181.

Créer un client réseau (Network Client) sur WiKID

  • Après avoir enregistré le domaine, ouvrez l’onglet “Network Client” et cliquez sur “Create New Network Client”.
  • Donnez un nom explicite au client (ex. ssh-gateway-01) et entrez l’adresse IP du serveur SSH de destination.
  • Choisissez “Radius” comme protocole et assignez le client au domaine créé.

Formulaire de création du client réseau dans WiKID

  • Cliquez sur “Add” pour passer à la page suivante et définissez le secret partagé (shared secret) pour RADIUS.

Page d'ajout du secret partagé pour le client RADIUS

Répétez ce processus pour chaque hôte ou groupe d’hôtes que vous souhaitez gérer séparément.

Installer pam_radius sur CentOS 7

  1. Téléchargez la source pam_radius (exemple avec la version 1.3.17) :
$ wget ftp://ftp.freeradius.org/pub/radius/pam_radius-1.3.17.tar.gz
  1. Décompressez l’archive :
$ tar -xzvf pam_radius-1.3.17.tar.gz
  1. Installez les dépendances de compilation :
$ sudo yum install pam-devel make gcc
  1. Entrez dans le répertoire extrait et compilez :
$ cd pam_radius-1.3.17
$ make

Note : des avertissements peuvent apparaître. Tant que la librairie pam_radius_auth.so est générée, la compilation est correcte.

  1. Copiez la bibliothèque vers l’emplacement PAM adapté à votre architecture :
# Pour systèmes 32 bits
$ sudo cp pam_radius_auth.so /lib/security/

# Pour systèmes 64 bits
$ sudo cp pam_radius_auth.so /usr/lib64/security/

Configurer SSH pour utiliser RADIUS via PAM

  1. Sauvegardez les fichiers PAM et SSH avant toute modification :
$ sudo cp /etc/pam.d/sshd /etc/pam.d/sshd.bak
$ sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
  1. Éditez le fichier PAM pour SSH (/etc/pam.d/sshd). Ajoutez la ligne suivante au début des règles d’authentification (ou en second bloc d’auth) :
auth    sufficient    /lib/security/pam_radius_auth.so

Explication :

  • ‘sufficient’ permet de garder l’authentification locale en secours si RADIUS est indisponible.
  • Changez en ‘required’ uniquement après des tests concluants et si vous voulez forcer RADIUS pour tous.
  1. Vérifiez la configuration SSH (/etc/ssh/sshd_config) et assurez-vous que PasswordAuthentication est activé si vous prévoyez d’utiliser le mot de passe + OTP ; sinon désactivez si vous utilisez seulement challenge-response. Exemple :
# Autoriser ou non l'authentification par mot de passe
PasswordAuthentication yes
ChallengeResponseAuthentication yes
  1. Redémarrez le service sshd après tests :
$ sudo systemctl restart sshd

Configurer le client pam_radius

Créez ou éditez /etc/pam_radius_auth.conf (ou /etc/raddb/server selon votre distribution) et ajoutez une ligne pour votre serveur WiKID :

# Format:   
192.0.2.10    mon-secret-partage    1812
  • Remplacez 192.0.2.10 par l’IP ou le nom d’hôte du serveur WiKID.
  • Remplacez mon-secret-partage par le secret partagé que vous avez défini dans l’interface WiKID.
  • Le port RADIUS standard est 1812.

Tests et validation

  1. Ouvrez un terminal et suivez les logs de sécurité :
$ sudo tail -f /var/log/secure
  1. Depuis un autre poste, tentez une connexion SSH vers le serveur CentOS avec votre nom d’utilisateur. Vous devriez recevoir la demande de code OTP selon la méthode WiKID.

  2. Vérifiez dans les logs que la requête RADIUS a été envoyée et que la réponse est accepted/denied.

  3. Scénarios de test recommandés :

  • Connexion réussie avec OTP valide et PIN correct.
  • Échec avec OTP invalide.
  • Échec avec compte local désactivé.
  • Test de coupure du serveur WiKID pour valider le comportement en mode ‘sufficient’ vs ‘required’.

Procédure de retour arrière (rollback)

Si l’accès est bloqué, suivez :

  1. Rétablir le fichier PAM sauvegardé :
$ sudo cp /etc/pam.d/sshd.bak /etc/pam.d/sshd
$ sudo systemctl restart sshd
  1. Si vous ne pouvez pas vous connecter, utilisez la console de gestion (KVM/IPMI) ou la session physique pour restaurer les fichiers.

Bonnes pratiques et sécurité

  • Conservez toujours une session d’administration ouverte lors des tests.
  • Séparez les domaines WiKID pour différents groupes d’admins (ex. root-HR, root-ops) pour un contrôle granulaire.
  • Utilisez LDAP/AD en combinaison avec WiKID pour centraliser l’autorisation et faciliter les révocations d’accès.
  • Protégez le secret partagé entre le client et WiKID (ne le répandez pas en clair dans des dépôts).
  • Envisagez l’usage de TLS/SSH bastion et d’un pare-feu pour limiter les sources de connexion.

Scénarios où cette approche peut échouer

  • Latence réseau importante ou indisponibilité du serveur WiKID empêchera l’authentification en temps réel.
  • Si pam_radius est mal configuré, vous risquez des faux positifs/negatifs lors de l’authentification.
  • Certaines procédures automatisées (scripts non interactifs) qui s’appuyaient sur des clés publiques peuvent nécessiter adaptation ou exceptions.

Checklist par rôle

Administrateur système :

  • Avoir accès console physique/virtuel pour rollback.
  • Sauvegarder /etc/pam.d/sshd et /etc/ssh/sshd_config.
  • Installer pam-devel et compiler pam_radius.
  • Copier pam_radius_auth.so au bon emplacement.
  • Tester plusieurs utilisateurs et examiner /var/log/secure.

Administrateur WiKID :

  • Créer domaine avec Domain Server Code correct.
  • Créer client réseau et définir un secret fort.
  • Assurer la haute disponibilité du serveur WiKID si nécessaire.

Auditeur sécurité :

  • Vérifier la journalisation RADIUS dans WiKID et /var/log/secure.
  • Vérifier la procédure de révocation des tokens.

Critères d’acceptation

  • Les utilisateurs obtiennent une invite OTP et ne peuvent pas se connecter sans code valide.
  • Les connexions sont journalisées dans /var/log/secure et dans le serveur WiKID.
  • Les comptes peuvent être désactivés côté WiKID pour révoquer l’accès rapidement.
  • Les tests de rollback restaurent l’accès en moins de 15 minutes (ou selon SLA interne).

Dépannage courant

  • « pam_radius_auth.so not found » : vérifiez le chemin de copie (/lib/security ou /usr/lib64/security).
  • Échecs RADIUS : contrôlez le secret partagé et la connectivité réseau (ping, telnet 1812).
  • Erreurs dans /var/log/secure : activez un niveau de log plus verbeux côté WiKID pour diagnostiquer les échanges RADIUS.

Considérations de confidentialité

  • WiKID valide le PIN et gère les tokens. Évitez d’enregistrer des secrets en clair dans des dépôts.
  • Si vous conservez des logs d’authentification, appliquez la rétention conforme à votre politique interne ou au RGPD si des données personnelles liées aux identifiants sont stockées.

Exemple de flux décisionnel (Mermaid)

flowchart TD
  A[Démarrer déploiement 2FA] --> B{Sauvegardes faites ?}
  B -- Non --> C[Effectuer sauvegardes]
  B -- Oui --> D[Créer domaine WiKID]
  D --> E[Créer client réseau WiKID]
  E --> F[Installer pam_radius sur CentOS]
  F --> G[Modifier PAM pour SSH]
  G --> H[Test en session de secours]
  H -- Succès --> I[Passer en production: changer 'sufficient' en 'required' si voulu]
  H -- Échec --> J[Rollback via console]
  J --> C

Modèles et extraits utiles

Fichier /etc/pam_radius_auth.conf (exemple) :

# serveur-wikid secret partagé port
192.0.2.10    mon-secret-partage    1812

Ligne PAM recommandée à ajouter dans /etc/pam.d/sshd :

auth    sufficient    /lib/security/pam_radius_auth.so

Commande pour suivre les logs pendant un test :

$ sudo tail -f /var/log/secure

Points à retenir

  • WiKID + pam_radius apporte une couche 2FA forte à SSH sans remplacer la gestion des comptes (local ou LDAP).
  • Testez en environnement contrôlé et conservez toujours une session de secours.
  • Segmentez les domaines WiKID pour une gouvernance fine des accès.

Résumé : mettre en place WiKID avec pam_radius renforce significativement la sécurité des accès SSH sur CentOS 7, tout en permettant une gestion centralisée des tokens et des révocations. Assurez-vous d’une configuration prudente, d’une stratégie de test et d’un plan de retour arrière avant de passer en production.

Liens utiles :

Auteur
Édition

Matériaux similaires

Sécuriser Ubuntu/Debian contre Logjam
Sécurité Serveur

Sécuriser Ubuntu/Debian contre Logjam

Dark Sky : prévisions hyperlocales et alternatives
Météo

Dark Sky : prévisions hyperlocales et alternatives

SSH sécurisé sur CentOS 7 avec WiKID 2FA
Sécurité Linux

SSH sécurisé sur CentOS 7 avec WiKID 2FA

Empêcher Windows 10 d'installer des mises à jour
Windows

Empêcher Windows 10 d'installer des mises à jour

5 étapes pour engager Stay Dry Roofing Indianapolis
Rénovation toit

5 étapes pour engager Stay Dry Roofing Indianapolis

DNS non répondant sur Windows 11 — dépannage
réseau

DNS non répondant sur Windows 11 — dépannage