2FA SSH sous Linux avec pam_radius : approbation sur le téléphone pour SSH et sudo

Le même Notakey auth-proxy qui protège déjà votre VPN et l’accès d’administration à MikroTik peut aussi protéger les connexions Linux. La pile PAM de Linux fournit un module RADIUS standard : pointez-le vers le proxy et SSH, sudo et su exigeront tous une approbation sur le téléphone en plus du mot de passe.

sshd / sudo ──PAM──▶ pam_radius ──RADIUS──▶ Notakey auth-proxy ──▶ your RADIUS server
                                                    │
                                                    └──▶ push ──▶ user's phone

Ce guide s’adresse à Debian/Ubuntu (libpam-radius-auth) ; sur les distributions de la famille RHEL, le module est empaqueté sous le nom pam_radius (EPEL) et les fichiers PAM se trouvent dans la même arborescence /etc/pam.d/.

Prérequis

• Un auth-proxy opérationnel devant un serveur RADIUS, configuré exactement comme aux étapes 1 à 3 du guide VPN.
• Le même nom d’utilisateur dans le serveur RADIUS de destination, dans le service Notakey (avec un téléphone enrôlé) et en tant que compte sur la machine Linux. PAM se contente d’authentifier : l’utilisateur a toujours besoin d’un compte local (ou d’annuaire) pour ouvrir une session.
• La machine Linux doit pouvoir joindre le proxy sur le port UDP 1812. Le mot de passe circule en PAP entre les deux : maintenez donc cet échange sur un réseau d’administration, ou exécutez le proxy dockerisé directement sur l’hôte.

Étape 0 – Préparez d’abord votre issue de secours

Avant de toucher à PAM, assurez-vous qu’une connexion purement locale fonctionne : attribuez à root (ou à un compte d’administration de secours dédié) un mot de passe local robuste et vérifiez-le depuis la console. La configuration ci-dessous se rabat toujours sur les mots de passe locaux ; ce compte est donc votre porte d’entrée si le proxy, le serveur RADIUS ou le réseau venait à tomber. Faites-le dès maintenant, pas une fois que quelque chose est cassé.

Étape 1 – Installez le module

sudo apt-get install libpam-radius-auth

Étape 2 – Pointez-le vers le proxy

Modifiez /etc/pam_radius_auth.conf et ajoutez une seule ligne : l’adresse du proxy, le secret partagé (qui correspond au vpn_secret_in du proxy) et le délai d’attente en secondes :

# server[:port]    shared_secret            timeout (s)
10.0.1.20          secret_to_radius_server  60

Verrouillez ensuite le fichier, car il contient le secret :

sudo chmod 0600 /etc/pam_radius_auth.conf

Le délai d’attente est le même piège que partout ailleurs dans cette série. La valeur par défaut du module est de 3 secondes : suffisant pour vérifier un mot de passe, mais bien trop court pour une approbation humaine. Réglez-le au minimum sur le vpn_message_ttl du proxy (30 s) ; 60 offre une marge confortable.

Étape 3 – Activez-le dans PAM

Pour chaque point d’entrée à protéger, ajoutez une ligne juste au-dessus de la ligne @include common-auth. Pour SSH :

sudo nano /etc/pam.d/sshd

auth sufficient pam_radius_auth.so
@include common-auth

sufficient signifie ceci : si RADIUS renvoie Access-Accept (mot de passe validé par le serveur RADIUS de destination et notification push approuvée), la connexion réussit immédiatement. Sinon, PAM passe à la vérification classique du mot de passe local située en dessous.

Ajoutez la même ligne à l’un ou l’autre de ces fichiers, selon vos besoins :

• /etc/pam.d/login : connexions à la console
• /etc/pam.d/sudo : chaque sudo sollicite le téléphone (protection forte, mais fréquente : le cache d’identifiants de sudo la rend tolérable)
• /etc/pam.d/su : changement d’utilisateur

Enfin, modifiez /etc/pam.d/common-auth et ajoutez try_first_pass à la ligne pam_unix.so existante :

auth    [success=1 default=ignore]      pam_unix.so nullok_secure try_first_pass

(Les autres options de cette ligne varient selon la version : seul try_first_pass est ajouté.) Sans cette option, un utilisateur qui se rabat sur l’authentification locale se voit demander son mot de passe une seconde fois ; avec elle, le mot de passe déjà saisi est réutilisé silencieusement.

Étape 4 – Vérifiez que sshd utilise bien PAM

Dans /etc/ssh/sshd_config, l’authentification via PAM nécessite :

UsePAM yes
KbdInteractiveAuthentication yes

(les deux sont les valeurs par défaut sous Debian/Ubuntu). Un point à connaître : les connexions SSH par clé publique contournent entièrement la phase d’authentification de PAM : une connexion par clé ne déclenche aucune notification push. Si vous voulez exiger la clé et la push, définissez AuthenticationMethods publickey,keyboard-interactive, mais testez cette variante séparément avant de la déployer.

Étape 5 – Créez des utilisateurs « push uniquement »

Voici l’astuce qui rend la configuration propre : créez les utilisateurs sans mot de passe local.

sudo useradd -m -G sudo john

Ne lancez pas passwd ensuite : le mot de passe local du compte reste verrouillé. Cet utilisateur n’a plus qu’un seul moyen d’accès : RADIUS via le proxy, c’est-à-dire mot de passe et approbation sur le téléphone. Il n’y a rien de local à attaquer par force brute. Le compte d’administration de secours de l’étape 0 demeure le seul doté d’un mot de passe purement local.

Testez, avec prudence

Gardez votre session de travail ouverte et connectez-vous en SSH depuis un second terminal avec un nom d’utilisateur RADIUS :

• L’invite de mot de passe se comporte normalement ; une fois saisi, la session attend : c’est le proxy qui maintient l’échange ouvert.
• La notification push arrive sur le téléphone. Approuvez → accès au shell. Refusez ou ignorez → la connexion échoue à l’expiration du délai.
• Vérifiez que le compte de secours parvient toujours à se connecter avec son mot de passe local.

Ne fermez votre session d’origine qu’une fois ces deux vérifications réussies.

Dépannage

• La connexion échoue instantanément, sans push : le délai d’attente dans /etc/pam_radius_auth.conf est resté à sa valeur par défaut de 3 secondes, ou le secret ne correspond pas au vpn_secret_in du proxy.
• Pas de push, mais l’attente a lieu : le nom d’utilisateur diffère entre RADIUS et le service Notakey, ou le téléphone n’est pas enrôlé pour cette application.
• Mot de passe demandé deux fois : try_first_pass est absent de la ligne pam_unix dans common-auth.
• Les connexions SSH par clé ne reçoivent aucune push : c’est normal ; l’authentification par clé publique contourne la phase d’authentification de PAM (voir l’étape 4).

Où cela s’inscrit

Un seul proxy, un seul serveur RADIUS, et désormais le VPN, le plan d’administration du routeur et votre parc Linux exigent tous une approbation sur le téléphone. Tout ce qui parle RADIUS ou PAM peut rejoindre la même configuration.

Guides associés

• 2FA VPN avec RADIUS – la configuration complète de l’auth-proxy : la configuration du proxy sur laquelle repose ce guide
• 2FA pour la connexion au routeur MikroTik : le même schéma pour la connexion WinBox/SSH du routeur lui-même