Ubuntu 22.04 Server / Se connecter en root en local et par SSH

Sur Ubuntu 22.04 Server, la méthode habituelle pour travailler avec les privilèges root consiste à se connecter avec un compte ordinaire puis à lancer sudo -i. Une connexion directe en root exige de vérifier séparément mot de passe et politique de connexion ; SSH dépend aussi de PermitRootLogin et des méthodes d’authentification.

Privilèges root et connexion directe

Root est le compte qui administre tout le système. Ubuntu verrouille son mot de passe par défaut et permet aux utilisateurs autorisés d’exécuter sudo avec leurs propres identifiants. Le compte root existe bien. Ce fonctionnement est décrit dans la documentation Ubuntu sur la gestion des utilisateurs.

Si vous avez seulement besoin d’un shell d’administration, utilisez les commandes suivantes. L’authentification emploie normalement le mot de passe du compte ordinaire, selon la politique sudo. Vérifiez que whoami affiche root, puis revenez au compte ordinaire avec exit. Cela n’active pas le mot de passe root et ne change pas la politique SSH.

sudo -i
whoami
exit

Ne définissez un mot de passe root que si une connexion par mot de passe à la console ou un passage par su - est nécessaire. La première demande sudo concerne votre compte ordinaire ; les deux suivantes définissent le nouveau mot de passe root. Les caractères saisis ne s’affichent pas.

sudo passwd root
su -
whoami
exit

su - utilise le mot de passe root ainsi défini. Le définir n’autorise pas automatiquement toutes les connexions : PAM (Pluggable Authentication Modules, modules d’authentification enfichables) et les politiques de console ou d’accès distant peuvent les restreindre. Consultez le manuel sudo d’Ubuntu 22.04 pour sudo -i.

Vérifier l’accès et la politique SSH existante

La procédure concerne OpenSSH sur un serveur Ubuntu 22.04 que vous administrez. Gardez ouverte la session SSH du compte ordinaire et préparez une console physique ou de récupération cloud. En production, envisagez d’abord un compte ordinaire suivi de sudo. Si l’accès root direct est nécessaire, définissez aussi l’usage des clés publiques et le réseau d’administration autorisé.

Si le serveur SSH manque, exécutez sudo apt update, puis sudo apt install openssh-server. Vérifiez le service avec sudo systemctl status ssh.service. Il faut connaître l’adresse et le port SSH réels ; le pare-feu et les règles cloud doivent autoriser cet accès d’administration.

Sauvegardez la configuration et recherchez les directives avant toute modification. Si le nom de sauvegarde existe déjà, choisissez-en un autre pour éviter l’écrasement. Conservez les copies hors des répertoires chargés par *.conf, comme ci-dessous.

sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.before-root-login
sudo cp -a /etc/ssh/sshd_config.d /etc/ssh/sshd_config.d.before-root-login
sudo grep -RnsE '^[[:space:]]*(Include|Match|PermitRootLogin|PasswordAuthentication|PubkeyAuthentication|AuthenticationMethods|AllowUsers|DenyUsers|AllowGroups|DenyGroups)' /etc/ssh/sshd_config /etc/ssh/sshd_config.d

Le fichier serveur est sshd_config, distinct du fichier client ssh_config. Ubuntu 22.04 charge normalement /etc/ssh/sshd_config.d/*.conf en premier. La plupart des directives retiennent la première valeur obtenue : une ligne ajoutée à la fin peut donc être sans effet. Examinez l’ordre Include, les conditions Match et les fichiers générés par le cloud, puis vérifiez les valeurs effectives.

Dans le manuel sshd_config d’Ubuntu 22.04, PermitRootLogin yes autorise root si les autres conditions sont remplies. prohibit-password interdit les authentifications par mot de passe et clavier interactif pour root, tout en pouvant autoriser les clés publiques. no interdit root par SSH. Une ligne de valeur par défaut commentée ne suffit pas à connaître la politique réelle.

Configurer la connexion SSH root par mot de passe

Cette méthode expose l’authentification du mot de passe root ; choisissez-la seulement si le contexte d’administration le nécessite. Définissez le mot de passe avec sudo passwd root, puis modifiez le fichier réellement prioritaire avec sudoedit /etc/ssh/sshd_config ou le fragment concerné. Voici un exemple de politique, pas des lignes à ajouter aveuglément en fin de fichier.

PermitRootLogin yes
PasswordAuthentication yes

PermitRootLogin yes ne suffit pas. L’authentification par mot de passe, AuthenticationMethods, les restrictions d’utilisateurs ou de groupes, PAM et l’état du compte doivent aussi autoriser l’accès. Un PasswordAuthentication yes global peut affecter d’autres utilisateurs : vérifiez s’il élargit la politique. Ne désactivez pas le pare-feu ni l’authentification multifacteur pour suivre ce guide.

Enregistrer le fichier ne termine pas l’application. Effectuez la validation et le rechargement décrits plus bas avant le test client. Remplacez 192.0.2.20 par l’adresse réelle. Pour un autre port que le port 22 par défaut, utilisez ssh -p PORT avec le numéro réel.

ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password root@192.0.2.20

Ce test choisit le mot de passe plutôt que la clé publique. Un mot de passe seul ne suffit pas si le serveur impose une autre authentification. Vérifiez l’empreinte de la clé d’hôte par un canal d’administration fiable ; ne désactivez pas cette vérification pour contourner une alerte de changement de clé.

Se connecter en root avec une clé publique

Le client conserve la clé privée et seule la clé publique correspondante est enregistrée sur le serveur. Activer le mot de passe root n’est pas un préalable. La clé peut être installée depuis une session d’administration existante ou une console, sans ouvrir d’abord SSH root par mot de passe.

Si le client ne possède pas de clé adaptée, générez-en une avec ssh-keygen -t ed25519. Choisissez un nouveau nom sans écraser une clé existante et protégez la clé privée par une phrase secrète. Enregistrez la ligne du fichier public ~/.ssh/id_ed25519.pub. Ne copiez jamais sur le serveur la clé privée sans suffixe .pub.

Dans la session d’administration existante du serveur, préparez les permissions comme ci-dessous et ajoutez la ligne de clé publique dans l’éditeur. Préservez les clés existantes et évitez les doublons. Si vous avez choisi un autre nom de fichier, utilisez sa clé publique correspondante.

sudo install -d -m 700 -o root -g root /root/.ssh
sudo touch /root/.ssh/authorized_keys
sudo chown root:root /root/.ssh/authorized_keys
sudo chmod 600 /root/.ssh/authorized_keys
sudoedit /root/.ssh/authorized_keys

Cet exemple emploie le chemin de clés autorisées par défaut. Si AuthorizedKeysFile indique un autre emplacement, vérifiez-le. Choisissez la politique suivante pour interdire le mot de passe root, corrigez les directives antérieures en conflit, puis validez.

PermitRootLogin prohibit-password
PubkeyAuthentication yes

Après validation et application côté serveur, connectez-vous depuis le client comme suit. Une demande de phrase secrète concerne la clé privée du client, pas le mot de passe root. Les clés publiques restent soumises aux politiques PAM, de compte et d’accès.

ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes root@192.0.2.20

Valider les paramètres et tester une nouvelle session

1. Vérifiez d’abord la syntaxe et les clés d’hôte sur le serveur. Un contrôle -t réussi ne produit normalement aucune sortie. En cas d’erreur, corrigez le fichier et la ligne indiqués avant de recharger. -T affiche la configuration effective ; avec -C, il évalue les conditions Match de la connexion indiquée.

sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T -C user=root,addr=192.0.2.10,host=admin.example | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication|authenticationmethods|authorizedkeysfile|allowusers|denyusers|allowgroups|denygroups) '

Remplacez 192.0.2.10 par l’adresse du client d’administration vue par le serveur et admin.example par le nom d’hôte client à évaluer. Avec Match LocalAddress ou LocalPort, ajoutez aussi laddr et lport à -C. Si le résultat diffère du prévu, examinez d’abord priorités et conditions. Les options sont expliquées dans le manuel sshd d’Ubuntu 22.04.

2. Une fois la syntaxe correcte et les valeurs conformes à la politique voulue, rechargez le service. Gardez la session d’administration ouverte et testez la méthode par mot de passe ou clé dans une autre fenêtre cliente.

sudo systemctl reload ssh.service
sudo systemctl is-active ssh.service

3. Un service active ne garantit pas une nouvelle authentification réussie. Dans la nouvelle session root, vérifiez que whoami affiche root et id -u affiche 0. Testez aussi une nouvelle connexion ordinaire et sudo. Les conditions de compte, clé, utilisateur ou réseau peuvent encore refuser l’accès.

Diagnostiquer les échecs et annuler l’accès root direct

Pour Permission denied, vérifiez authentification, compte et politique d’accès. Pour un délai dépassé ou une connexion refusée, examinez séparément adresse, port, service et pare-feu. Utilisez sudo journalctl -u ssh.service -n 50 --no-pager côté serveur et ssh -v root@192.0.2.20 côté client. Masquez les informations sensibles, notamment adresses et noms d’utilisateur, avant de partager les journaux.

Pour interdire de nouveau root par SSH, réglez le PermitRootLogin effectif sur no, vérifiez sshd -t et sshd -T avec les conditions de connexion, puis exécutez sudo systemctl reload ssh.service. Rétablissez aussi la politique de mot de passe modifiée temporairement. Restaurez uniquement les fichiers et paramètres changés, sans écraser tout le répertoire de fragments.

Après avoir confirmé SSH et sudo avec un autre compte ordinaire, verrouillez le mot de passe root si vous l’avez activé pour cette opération et n’en avez plus besoin. Selon le manuel passwd, -l verrouille le mot de passe et ne bloque pas tous les accès, notamment par clé publique. Vérifiez séparément l’interdiction SSH avec PermitRootLogin no.

sudo passwd -l root

Verrouiller un mot de passe ou modifier SSH ne ferme pas automatiquement les sessions root existantes. Terminez le travail et quittez les shells root ouverts avec exit. Pour récupérer l’accès, utilisez la session ordinaire conservée ou la console de secours, en vous appuyant sur les sauvegardes et le relevé des modifications.