Ubuntu / Modifier le port SSH, encadrer l’accès root et vérifier NetworkManager

Pour modifier le port SSH (Secure Shell) ou l’authentification sous Ubuntu, commencez par identifier le service et le socket réellement utilisés, puis vérifiez chaque changement avec une nouvelle connexion avant de fermer la session actuelle. Gardez un compte d’administration ordinaire, une clé publique et un accès à la console de secours. La procédure de configuration d’OpenSSH et de vérification de l’authentification par clé publique (en anglais) complète ces notes.

Vérifier la configuration active

cat /etc/os-release
systemctl status ssh.socket ssh.service --no-pager
sudo ss -lntp
sudo sshd -T | grep -E "^(port|listenaddress|permitrootlogin|passwordauthentication|authenticationmethods) "

Conservez la connexion SSH actuelle et vérifiez que vous pouvez ouvrir une console de secours. Sauvegardez /etc/ssh/sshd_config et les fichiers qu’il inclut. OpenSSH retient généralement la première valeur obtenue pour une directive : ajouter une autre valeur à la fin du fichier ne suffit donc pas forcément. Si des blocs Match s’appliquent, utilisez sshd -T -C avec les paramètres de la connexion concernée. Changer le port ne remplace ni une authentification solide ni les restrictions d’accès réseau.

Exemple : déplacer SSH vers le port 1980

Le numéro 1980 est un exemple. Choisissez un port libre et autorisez d’abord l’adresse d’administration dans le pare-feu du serveur et dans celui du fournisseur cloud. Si vous utilisez UFW, remplacez l’adresse de documentation 192.0.2.10 ci-dessous par votre véritable adresse d’administration. Consultez également la procédure de restriction des accès avec UFW (en anglais).

sudo ufw allow from 192.0.2.10 to any port 1980 proto tcp

Modifiez la directive Port dans la configuration effectivement utilisée. Tenez compte des fichiers inclus et des règles conditionnelles, au lieu d’ajouter plusieurs valeurs concurrentes. Placez la directive du port dans la partie globale de la configuration, puis vérifiez la syntaxe avant toute application.

Port 1980

sudo sshd -t

Si ssh.socket est actif, redémarrer uniquement le service peut laisser le port d’écoute inchangé. Sur Ubuntu 24.04 et les versions ultérieures, inspectez les paramètres de socket générés sur votre installation. Si une surcharge explicite est nécessaire, ouvrez sudo systemctl edit ssh.socket et ajoutez le fragment suivant. La ligne vide ListenStream= efface la liste précédente. Préservez les éventuelles adresses d’écoute spécifiques déjà configurées : cet exemple qui indique seulement un port ne doit pas les remplacer sans examen.

[Socket]
ListenStream=
ListenStream=1980

Appliquez les commandes suivantes seulement après avoir confirmé que votre installation utilise l’activation par socket. Si seul ssh.service est utilisé, n’activez pas un nouveau socket : rechargez ou redémarrez le service existant après validation.

sudo systemctl daemon-reload
sudo systemctl restart ssh.socket ssh.service
sudo ss -lntp

Depuis un autre client, essayez ssh -p 1980 user@server en remplaçant le compte et le serveur. Gardez l’ancienne règle de pare-feu et la session actuelle jusqu’à ce que le nouveau port écoute, qu’une nouvelle connexion aboutisse et que sudo fonctionne. En cas d’échec, utilisez la console pour restaurer uniquement les paramètres SSH et la surcharge de socket modifiés, validez la configuration et rétablissez d’abord l’accès sur le port initial.

La documentation Ubuntu sur OpenSSH décrit les fichiers de configuration et leur validation.

Réserver la connexion directe de root aux cas nécessaires

Utilisez normalement un compte ordinaire avec sudo. Si une connexion directe du compte root est nécessaire, préparez une clé publique et vérifiez les règles réellement appliquées à ce compte.

PermitRootLogin prohibit-password
PubkeyAuthentication yes
AuthenticationMethods publickey

Ces directives illustrent les paramètres à examiner ; elles ne doivent pas remplacer aveuglément la politique globale d’authentification de votre organisation. Intégrez les restrictions propres à root dans les blocs Match appropriés en préservant l’accès des autres administrateurs. La valeur prohibit-password ne signifie pas à elle seule « uniquement par clé publique » : examinez aussi AuthenticationMethods. L’état du compte, les permissions des fichiers de clés et PAM, le mécanisme d’authentification du système, peuvent imposer d’autres restrictions.

PermitRootLogin yes ne garantit pas non plus qu’un mot de passe permettra la connexion : les autres règles d’authentification, le verrouillage du compte et PAM restent applicables. N’activez pas le mot de passe de root comme solution de dépannage ordinaire. Contrôlez la syntaxe avec sshd -t, la configuration effective avec sshd -T -C pour les conditions réelles, puis une nouvelle connexion par clé et l’utilisation de sudo. Rétablissez PermitRootLogin no lorsque l’accès direct n’est plus nécessaire. Le manuel officiel de sshd_config précise le rôle de ces directives.

Identifier le gestionnaire réseau avant d’utiliser nmtui

systemctl is-active NetworkManager systemd-networkd
sudo netplan get
command -v nmtui

nmtui modifie les profils de connexion de NetworkManager. Si cet outil est nécessaire, vérifiez la présence du paquet network-manager. Son installation ne migre toutefois pas automatiquement et sans risque une configuration existante fondée sur Netplan et systemd-networkd. Évitez que deux gestionnaires contrôlent la même interface : identifiez le moteur réseau choisi, appelé renderer dans Netplan, et prévoyez un retour arrière avant d’intervenir à distance. La procédure pour identifier le rôle de Netplan, NetworkManager et networkd (en anglais) explique ces vérifications.