Rocky Linux / Autoriser root en SSH par clé et vérifier les accès

Pour autoriser un accès SSH direct à root sur Rocky Linux, préparez une clé publique puis vérifiez une politique effective qui autorise cette clé, par exemple PermitRootLogin prohibit-password avec AuthenticationMethods publickey. Pour l’administration habituelle, un compte personnel avec sudo reste préférable : conservez cet accès pendant toute l’intervention et testez une nouvelle connexion avant de fermer la session existante.

Préparer un accès administratif de secours

SSH, pour Secure Shell, fournit une connexion chiffrée à un serveur. Le compte root possède les privilèges administratifs complets ; une clé autorisée pour ce compte donne donc un accès très étendu. Pour les tâches ordinaires, utilisez un compte nominatif et le mécanisme sudo afin d’exécuter seulement les commandes nécessaires.

Ce guide suppose un serveur Rocky Linux avec le service sshd déjà installé, un administrateur pouvant utiliser sudo, une clé personnelle existante et un accès à la console de récupération. Dans un nouveau terminal client, vérifiez d’abord une connexion avec votre compte administratif habituel. Dans cette session, contrôlez :

id
sudo -v

Une connexion par clé ne crée pas de mot de passe utilisable avec sudo. Si votre politique demande le mot de passe personnel, il doit être configuré pour ce compte ; ne contournez pas un échec en accordant largement NOPASSWD. Si aucun compte de secours ne fonctionne, préparez-le avant de modifier l’accès root.

Lire la configuration réellement utilisée

Vérifiez le service et la configuration calculée par le démon :

sudo systemctl status sshd
sudo sshd -T | grep -E '^(permitrootlogin|pubkeyauthentication|passwordauthentication|authenticationmethods|authorizedkeysfile) '
sudo grep -RinE '^[[:space:]]*(Include|Match|PermitRootLogin|PasswordAuthentication|PubkeyAuthentication|AuthenticationMethods|AuthorizedKeysFile)' /etc/ssh/sshd_config /etc/ssh/sshd_config.d

Un répertoire de fragments peut être absent selon l’installation. Examinez aussi les fichiers réellement indiqués par les directives Include. Si le service lance sshd avec un fichier alternatif via -f, utilisez ce même fichier pour les vérifications ; sinon vous risqueriez de tester une configuration différente.

Le nom d’un fragment commençant par 90 ne lui donne pas automatiquement priorité. Pour de nombreuses options, OpenSSH retient la première valeur rencontrée. Les blocs conditionnels Match peuvent modifier le résultat pour un utilisateur ou une adresse ; une ligne globale isolée ne suffit donc pas.

Calculez la politique correspondant à une vraie connexion root :

sudo sshd -T -C user=root,host=client.example.test,addr=192.0.2.10,laddr=192.0.2.20,lport=22 | grep -E '^(permitrootlogin|pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|authenticationmethods|authorizedkeysfile) '

Remplacez le nom client, son adresse vue par le serveur, l’adresse locale et le port par les valeurs réelles. Les adresses 192.0.2.0/24 sont réservées à la documentation. Recommencez pour le compte administratif et pour toute autre condition de connexion pertinente. Le manuel du démon sshd explique les tests -t, -T et -C.

Enregistrer seulement la clé publique de root

Conserver les clés existantes et vérifier le chemin

Les commandes suivantes supposent que le répertoire personnel de root est /root et que la politique effective utilise .ssh/authorized_keys. Vérifiez ces conditions avec getent passwd root et sshd -T -C. Une source centralisée de clés, un autre chemin ou des certificats SSH demandent une adaptation ; ne créez pas un fichier que le serveur ne consulte pas.

Vérifiez que /root/.ssh et le fichier attendu ne sont pas des liens symboliques inattendus. Conservez les clés et leurs options déjà présentes. Préparez le répertoire, sauvegardez le fichier s’il existe, puis ouvrez-le :

sudo install -d -m 700 -o root -g root /root/.ssh
if sudo test -f /root/.ssh/authorized_keys; then
  sudo cp --backup=numbered -a /root/.ssh/authorized_keys /root/.ssh/authorized_keys.before-root
fi
sudoedit /root/.ssh/authorized_keys

Ajoutez votre clé publique réelle sur une ligne complète, sans doublon et sans écraser les lignes précédentes. Une clé publique courante commence par un type tel que ssh-ed25519, suivi de sa valeur et éventuellement d’un commentaire. Ne copiez jamais la clé privée du poste client sur le serveur. Vérifiez aussi la compatibilité du type de clé avec la politique cryptographique du serveur, notamment si un mode FIPS est imposé.

sudo chown root:root /root/.ssh/authorized_keys
sudo chmod 600 /root/.ssh/authorized_keys
sudo restorecon -Rv /root/.ssh
sudo ls -ldZ /root/.ssh /root/.ssh/authorized_keys

Contrôlez propriétaire, permissions et contexte SELinux. Si un refus subsiste, analysez les journaux et le contexte SELinux au lieu de désactiver ce contrôle. N’utilisez pas ces changements pour corriger à l’aveugle une arborescence dont le rôle est différent.

Limiter une clé dédiée à l’automatisation

Une clé de sauvegarde ou d’automatisation devrait être distincte d’une clé d’administration interactive. Les options from=, command= et restrict dans authorized_keys permettent de limiter l’origine ou les possibilités de la session. restrict n’impose pas à lui seul une commande unique : associez une commande forcée adaptée si c’est l’objectif.

Testez les restrictions avec une clé séparée et une tâche précise. Une adresse derrière un VPN ou une traduction d’adresses peut être différente de celle du poste : la restriction doit correspondre à l’adresse réellement vue par le serveur.

Définir la politique root sans casser les autres comptes

Sauvegardez chaque fichier que vous allez modifier. Pour le fichier principal :

sudo cp --backup=numbered -a /etc/ssh/sshd_config /etc/ssh/sshd_config.before-root
sudoedit /etc/ssh/sshd_config

Si un bloc effectif correspondant déjà à root existe, modifiez-le après examen de son rôle. Sinon, dans une configuration simple sans règle conditionnelle concurrente, placez ce bloc à la fin du fichier principal :

Match User root
    PermitRootLogin prohibit-password
    PubkeyAuthentication yes
    AuthenticationMethods publickey

prohibit-password refuse pour root le mot de passe et l’authentification interactive au clavier. AuthenticationMethods publickey exige explicitement une clé ; ne remplacez pas par cet exemple une politique d’authentification multifacteur requise par votre organisation.

Un bloc Match s’étend jusqu’au bloc suivant ou à la fin du fichier. Évitez de le placer dans un fragment inclus très tôt si cela modifie la lecture des directives globales qui suivent. Lorsque plusieurs blocs correspondent, la première valeur conditionnelle applicable peut l’emporter : vérifiez le résultat au lieu d’ajouter des valeurs concurrentes. Le manuel sshd_config définit ces règles et PermitRootLogin.

Valider puis tester dans de nouvelles connexions

1. Gardez la session administrative actuelle ouverte et la console de secours disponible.
2. Exécutez sudo sshd -t. Un test réussi ne produit normalement pas de message et renvoie le code 0. En cas d’erreur, corrigez le fichier et la ligne indiqués avant de continuer.
3. Refaites sshd -T -C avec les conditions réelles de root et de votre compte administratif. Vérifiez la méthode exigée, le fichier de clés et les restrictions d’utilisateurs ou de groupes.
4. Rechargez le service seulement après ces contrôles.
5. Depuis un autre terminal client, testez une connexion root par clé et une connexion avec le compte administratif, puis vérifiez encore sudo -v pour ce dernier.

sudo sshd -t
sudo systemctl reload sshd

Les deux lignes représentent deux étapes : ne lancez pas la seconde si le test de la première échoue. Un rechargement relit les réglages ; une connexion déjà ouverte ne prouve pas que les suivantes réussiront.

Sur le poste client, remplacez la clé et le serveur par vos valeurs. L’option ControlPath=none évite de réutiliser une ancienne connexion multiplexée pendant le test :

ssh -o ControlPath=none -o IdentitiesOnly=yes -o PreferredAuthentications=publickey -i ~/.ssh/id_ed25519 root@server.example.test

Ajoutez -p avec le port réel s’il diffère de 22. Vérifiez l’empreinte de la clé d’hôte par un canal fiable ; ne désactivez pas ce contrôle pour faire réussir le test. Dans la session root ouverte, id -u doit afficher 0. Le manuel du client ssh décrit la sélection des clés et les options de connexion.

Vérifiez aussi que root ne peut pas utiliser le mot de passe, avec une nouvelle connexion qui ne propose pas de clé :

ssh -o ControlPath=none -o PubkeyAuthentication=no -o KbdInteractiveAuthentication=no -o PreferredAuthentications=password root@server.example.test

Avec la politique par clé ci-dessus, l’authentification doit être refusée. Ce test isolé ne remplace pas l’examen de la politique effective : un verrouillage du compte ou une règle réseau pourrait aussi provoquer un échec. Consultez les journaux pour distinguer les causes, sans multiplier les tentatives qui déclencheraient un verrouillage.

Limiter l’exposition réseau et la durée d’accès

Le pare-feu ne distingue pas un utilisateur SSH normal de root avant l’authentification. Restreignez le service SSH à votre VPN ou réseau de gestion, puis contrôlez les comptes dans OpenSSH. L’ajout d’une autorisation plus étroite ne retire pas une autorisation générale déjà présente.

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=public --list-all
sudo firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="192.0.2.0/24" service name="ssh" accept'

Remplacez public et le sous-réseau documentaire par la zone et l’origine réelles. Cet exemple vise le service SSH défini par firewalld ; pour un port personnalisé, adaptez la règle. Testez d’abord cette autorisation temporaire avec une nouvelle connexion. Sur le serveur, rendez ensuite uniquement cette règle persistante :

sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="192.0.2.0/24" service name="ssh" accept'

Examinez séparément les autorisations générales, IPv6 et les filtres en amont. Retirez une ouverture trop large seulement après avoir validé la bonne origine et la récupération par console. Le guide firewalld explique les zones, les règles temporaires et persistantes. Si la règle ajoutée n’est plus nécessaire, retirez exactement cette règle des deux configurations avec --remove-rich-rule, sans supprimer d’autres autorisations.

Attribuez une clé différente à chaque personne, séparez les clés d’automatisation et révoquez les accès devenus inutiles. Une phrase de passe protège la clé privée au repos. Activez le transfert d’agent uniquement si le fonctionnement l’exige et surveillez les connexions administratives.

Comprendre l’exception du mot de passe root

Un ancien outil peut imposer un accès root par mot de passe. Cette exception expose directement les privilèges complets à la compromission d’un secret ; limitez-la au réseau de gestion et à la durée nécessaire, avec une récupération et une surveillance préparées.

Dans le même bloc root effectif, les valeurs ci-dessous permettent à la méthode par mot de passe d’être considérée, sous réserve des autres contrôles du compte :

Match User root
    PermitRootLogin yes
    PasswordAuthentication yes
    AuthenticationMethods any

Ce bloc remplace l’exemple précédent ; l’ajouter derrière une règle correspondante prioritaire ne garantit pas son application. Laisser AuthenticationMethods publickey exigerait toujours une clé. Les contrôles du compte, PAM, les règles AllowUsers/DenyUsers et le réseau continuent de s’appliquer. Ne débloquez pas automatiquement un compte ni une politique multifacteur pour contourner un refus. Dès la fin de l’exception, restaurez la politique initiale, rechargez-la après validation et retirez le secret temporaire selon la procédure du système.

Refermer l’accès direct et revenir aux réglages initiaux

Après avoir confirmé une nouvelle connexion du compte administratif et son fonctionnement avec sudo, définissez dans le même bloc root effectif :

PermitRootLogin no

Validez avec sshd -t et sshd -T -C, rechargez, puis confirmez qu’une nouvelle connexion root est refusée et que l’administrateur peut toujours se connecter. Cela ne ferme pas automatiquement une session root déjà ouverte.

Pour revenir exactement à la configuration précédente, restaurez les seules modifications de cette intervention à partir des sauvegardes, en conservant les changements légitimes intervenus entre-temps. Retirez seulement la clé nouvellement ajoutée si elle n’est plus autorisée ; ne remplacez pas toute la liste de clés par un fichier vide. Revalidez et testez chaque retour arrière avant de fermer l’accès de secours.

Identifier la cause d’un échec

sudo journalctl -u sshd -n 50 --no-pager

Rapprochez les messages de l’heure et de l’origine du test. Utilisez au besoin ssh -v côté client pour voir les étapes proposées ; examinez les journaux avant de les partager, car ils peuvent exposer des noms d’hôtes, des comptes ou des chemins.