Une empreinte pour tout le labo : sudo sur le serveur, votre coffre sur le portable

Un agent sur votre serveur a besoin de root pour une commande. Avant, il fallait ouvrir un terminal et taper un long mot de passe, dix fois par jour. Maintenant une notification apparaît sur le portable avec la commande exacte, vous touchez le lecteur, c'est fait. Le même doigt déverrouille votre gestionnaire de mots de passe. Rien n'est affaibli : le mot de passe marche toujours, et reste la réponse à toute panne.

Ce que vous y gagnez. Des approbations root d'un seul toucher, avec la commande affichée avant votre accord, pour vous et pour vos agents. En service ici tous les jours, avec un repli sur le mot de passe en deux secondes quand le portable est absent.

1. Le principe : demander, montrer, signer, vérifier

1. Sur le serveur, sudo déroule sa pile PAM. Une première ligne appelle un petit programme, avant la ligne habituelle du mot de passe.
2. Ce programme envoie au portable la commande et un nombre aléatoire neuf (un nonce), par votre réseau privé seulement.
3. Le portable affiche une notification avec la commande. Votre doigt sur le lecteur l'autorise à signer le nonce avec une clé dédiée.
4. Le serveur vérifie la signature avec la clé publique, la seule qu'il détient. Valide : sudo continue. Tout autre cas : la ligne du mot de passe prend le relais.

C'est le nonce qui rend le tout sûr : une réponse interceptée une fois ne vaut rien la fois suivante. Et comme le serveur ne détient qu'une clé publique, voler le serveur ne permet pas de fabriquer une approbation.

2. La ligne PAM

# /etc/pam.d/sudo — en premier, avant l'inclusion de la pile système
auth sufficient pam_exec.so quiet /usr/local/lib/remote-approve/approve
auth include system-auth

sufficient veut dire : si le programme dit oui, c'est fini ; s'il dit non ou échoue, PAM passe à la ligne suivante, le mot de passe. N'utilisez jamais required ici : un portable endormi vous fermerait la porte de root.

3. Côté portable

• Un petit service utilisateur, lancé avec la session, qui n'écoute que sur l'interface du réseau privé et n'accepte que l'adresse du serveur ; le pare-feu dit la même chose.
• Sa propre clé de signature (ed25519), créée pour cet usage, jamais copiée ailleurs.
• Le lecteur via fprintd : le service demande un doigt, et ne signe que s'il correspond.

Replis mesurés : portable absent, la demande de mot de passe apparaît en 2 secondes ; pas de doigt, au bout d'environ 20 secondes.

4. Le même doigt pour le gestionnaire de mots de passe

L'appli de bureau Bitwarden peut se déverrouiller par « authentification système », qui passe par polkit. Sur un portable sous Hyprland, il a fallu trois pièces :

• le fichier de politique polkit de Bitwarden, que le paquet de notre distribution ne livrait pas ;
• un agent polkit dans la session (hyprpolkitagent), activé en service utilisateur ;
• le manifeste de messagerie native dans le dossier du navigateur, pour que l'extension parle à l'appli.

Le déverrouillage biométrique de l'extension ne marche que si l'appli de bureau est ouverte. Notre premier essai a échoué pour cette seule raison.

Pièges

Testez le programme seul avant de le mettre dans PAM, et gardez un shell root ouvert pendant que vous modifiez /etc/pam.d. Une faute de frappe là peut vous enfermer dehors.

Une mise à jour de paquet peut déposer un sudo.pacnew (ou .rpmnew, .dpkg-dist) à côté de votre fichier. Reportez-y votre ligne, sinon elle disparaît à la prochaine fusion.

Ne laissez pas un agent modifier votre pile PAM ou votre pare-feu. Cette étape, faites-la vous-même.

Utile ? Dites-nous ce qu'il faut mesurer ensuite.