Activer SSH sur Ubuntu : installer OpenSSH et le durcir

Activer SSH sur Ubuntu : installer, démarrer, ouvrir le pare-feu

SSH sur Ubuntu provient du paquet openssh-server. Ubuntu Server propose de l’installer pendant la configuration et presque toutes les images cloud ou VPS l’embarquent déjà en écoute ; Ubuntu Desktop ne l’installe pas du tout.

1. Installer openssh-server

sudo apt update
sudo apt install -y openssh-server

Si le paquet est déjà présent, apt le signale et ne change rien. L’installation enregistre aussi un profil applicatif UFW nommé OpenSSH, utilisé à l’étape 3.

2. Activer et démarrer le service

sudo systemctl enable --now ssh
systemctl status ssh

Sous Ubuntu, l’unité s’appelle ssh ; sshd en est un alias. enable --now démarre le démon immédiatement et à chaque redémarrage. Depuis Ubuntu 22.10, sshd est activé par socket : ssh.socket détient le port 22 et lance ssh.service à la première connexion entrante, si bien qu’un état inactive (dead) avec TriggeredBy: ssh.socket juste après l’installation est normal. Le port est bien ouvert. Pour une vue d’ensemble, voyez lister les services avec systemctl.

3. Autoriser SSH dans UFW

Ubuntu livre UFW désactivé. Si vous l’activez, autorisez SSH d’abord ; activer le pare-feu avant que la règle existe est la façon classique de se verrouiller hors d’une machine distante.

sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status

ufw allow OpenSSH utilise le profil applicatif et ouvre le 22/tcp. Si vous déplacez ensuite sshd, autorisez le nouveau port avec sudo ufw allow 2222/tcp et supprimez l’ancienne règle. Trouvez l’adresse du serveur avec hostname -I.

Se connecter depuis Windows, macOS ou Linux

Tous les systèmes de bureau actuels intègrent un client OpenSSH, et la syntaxe est partout identique :

ssh username@SERVER_IP
ssh -p 2222 username@SERVER_IP      # non-default port

• Windows 10 et 11 : ouvrez PowerShell ou Windows Terminal et tapez la commande ; le client OpenSSH est livré avec Windows depuis 2018 (version 1809). Si ssh n’est pas reconnu, ajoutez-le dans Paramètres > Applications > Fonctionnalités facultatives.
• macOS : Terminal, même commande.
• Linux : n’importe quel terminal ; openssh-client est installé par défaut sur Ubuntu.

À la première connexion, acceptez l’empreinte de la clé hôte du serveur avec yes ; elle est stockée dans ~/.ssh/known_hosts et vous serez averti si elle change un jour. Saisissez ensuite le mot de passe du compte. La section suivante le remplace par une clé.

Passer à l’authentification par clé

Les connexions par mot de passe sont ce que les botnets attaquent en force brute jour et nuit ; les clés rendent ces tentatives inutiles. Générez une paire de clés Ed25519 sur votre propre ordinateur, jamais sur le serveur :

ssh-keygen -t ed25519 -C "laptop-2026"

Acceptez le chemin par défaut (~/.ssh/id_ed25519) et définissez une phrase secrète ; elle chiffre la clé privée sur le disque, et un agent SSH permet de ne la saisir qu’une fois par session. Seul le fichier .pub quitte votre machine.

Copier la clé publique sur le serveur

Sur macOS et Linux, ssh-copy-id le fait en une étape, en utilisant votre mot de passe une dernière fois :

ssh-copy-id -i ~/.ssh/id_ed25519.pub username@SERVER_IP

La version Windows d’OpenSSH n’inclut pas ssh-copy-id ; envoyez plutôt la clé via un tube depuis PowerShell :

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh username@SERVER_IP "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Les deux méthodes ajoutent la clé au fichier ~/.ssh/authorized_keys de l’utilisateur. Les permissions comptent : sshd ignore silencieusement le fichier si ~/.ssh n’est pas en mode 700 ou si authorized_keys est modifiable par quelqu’un d’autre que son propriétaire. Depuis un nouveau terminal, ssh username@SERVER_IP doit maintenant vous connecter sans le mot de passe du compte. Ne touchez pas à la section suivante tant que ce n’est pas le cas.

Durcir sshd_config : pas de mot de passe, pas de root, utilisateurs autorisés

Gardez votre session en cours ouverte pendant l’édition ; si la nouvelle configuration casse quelque chose, c’est votre porte de retour. /etc/ssh/sshd_config commence par Include /etc/ssh/sshd_config.d/*.conf, et sshd conserve la première valeur lue pour chaque mot-clé : un drop-in l’emporte donc sur tout ce qui suit dans le fichier principal. Or les images cloud livrent souvent /etc/ssh/sshd_config.d/50-cloud-init.conf avec PasswordAuthentication yes, ce qui explique pourquoi modifier le fichier principal semble si souvent sans effet. La solution : un drop-in dont le nom est trié en premier.

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

Collez ce qui suit, en remplaçant username par votre propre identifiant :

PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
AllowUsers username
MaxAuthTries 3
LoginGraceTime 30
X11Forwarding no
ClientAliveInterval 300
ClientAliveCountMax 2

PermitRootLogin no suppose que vous disposez d’un compte non privilégié avec les droits sudo. Si vous avez travaillé en root jusqu’ici, créez un utilisateur sudo sous Linux et copiez-y votre clé avant d’appliquer le fichier. Validez ensuite la syntaxe, rechargez, et vérifiez les valeurs réellement utilisées par sshd une fois tous les includes fusionnés, ce qu’affiche sshd -T :

sudo sshd -t
sudo systemctl reload ssh
sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin|allowusers|port'

Ouvrez un second terminal et connectez-vous avec votre clé avant de fermer le premier. Ce que fait chaque directive :

Le keepalive a aussi un côté client : ServerAliveInterval 60 dans ~/.ssh/config sur votre machine empêche les routeurs NAT de couper les sessions inactives.

Changer le port SSH n’est pas une sécurité

Déplacer sshd hors du port 22 est un conseil répandu. Ce que ça vous apporte, c’est moins de lignes de journal. Les scanners de masse balaient les 65 535 ports et trouvent sshd sur 2222 en quelques heures ; quelqu’un qui vous vise le trouve en quelques secondes avec nmap. Les clés, l’interdiction du login root, une liste d’autorisation et fail2ban sont la sécurité ; le port est cosmétique. Cela reste utile sur un serveur très sollicité pour garder le journal d’authentification lisible, mais ne le comptez jamais comme une couche de défense.

Si vous le changez quand même, respectez cet ordre : ouvrez le nouveau port dans UFW, changez le port, redémarrez, testez depuis un second terminal, puis supprimez l’ancienne règle. Décommentez #Port 22 dans /etc/ssh/sshd_config, indiquez le nouveau port, puis :

sudo ufw allow 2222/tcp
sudo sshd -t
sudo systemctl daemon-reload
sudo systemctl restart ssh.socket    # Ubuntu 22.10 and later
sudo systemctl restart ssh           # Ubuntu 22.04 and earlier

Sur les versions à activation par socket, c’est l’unité socket, et non sshd, qui décide du port écouté ; Ubuntu fournit un générateur systemd qui lit Port dans la configuration sshd pendant le daemon-reload et met à jour ssh.socket. Vérifiez avec sudo ss -tlnp | grep sshd. Le guide sur la vérification des ports ouverts sous Linux explique la sortie. Si sshd reste obstinément sur le 22, désactivez l’activation par socket et laissez le service ouvrir le port lui-même : sudo systemctl disable --now ssh.socket && sudo systemctl enable --now ssh.service. Une fois que ssh -p 2222 fonctionne depuis un terminal neuf, lancez sudo ufw delete allow OpenSSH.

Ajouter fail2ban, et envisager l’authentification à deux facteurs

Avec les mots de passe désactivés, la force brute ne peut pas aboutir, mais chaque tentative coûte encore un fork et une ligne de journal. fail2ban surveille le journal d’authentification et bannit les adresses qui échouent à répétition :

sudo apt install -y fail2ban
sudo nano /etc/fail2ban/jail.local

Mettez ceci dans le fichier :

[sshd]
enabled = true
port = ssh
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Ne modifiez jamais jail.conf ; il est remplacé lors des mises à jour et jail.local le surcharge. port = ssh est résolu via /etc/services, donc écrivez port = 2222 si vous avez déplacé le démon. backend = systemd lit directement le journal et fonctionne que votre image écrive ou non /var/log/auth.log. fail2ban-client status sshd liste les adresses bannies ; sudo fail2ban-client set sshd unbanip 203.0.113.7 en libère une. Par défaut, les règles de fail2ban sont évaluées avant celles d’UFW, les deux coexistent donc.

Authentification à deux facteurs

Quand une clé avec phrase secrète ne suffit pas, libpam-google-authenticator ajoute un code temporel par-dessus la clé : installez-le, exécutez google-authenticator avec le compte de connexion, ajoutez auth required pam_google_authenticator.so à /etc/pam.d/sshd (et commentez sa ligne @include common-auth), puis définissez KbdInteractiveAuthentication yes et AuthenticationMethods publickey,keyboard-interactive dans sshd. Un vrai gain face à un ordinateur portable volé, et une chose de plus à perdre : gardez les codes de secours hors du serveur.

Dépannage : connexion refusée, expirée, permission refusée

Connection refused

Le serveur a répondu mais rien n’écoute sur ce port : sshd est arrêté, écoute ailleurs, ou vous avez tapé le mauvais port. Depuis la console du fournisseur, lancez systemctl status ssh et sudo ss -tlnp | grep ssh. Une erreur de syntaxe empêche sshd de démarrer ; sudo sshd -t affiche la ligne fautive et journalctl -u ssh -n 50 montre le dernier démarrage.

Connection timed out

Les paquets sont jetés, pas refusés, ce qui signale presque toujours un pare-feu : UFW sans la règle d’autorisation (sudo ufw status verbose), un groupe de sécurité dans le panneau du fournisseur, ou votre propre réseau qui bloque le 22 sortant (un partage de connexion mobile permet de l’exclure). ssh -v username@SERVER_IP montre où la négociation s’arrête.

Permission denied (publickey)

Le serveur est joignable et vous rejette. Vérifiez, dans l’ordre : le nom d’utilisateur, la présence dans le authorized_keys de cet utilisateur de la clé que vous présentez (ssh -i ~/.ssh/id_ed25519 -v force une clé précise), les permissions de ~/.ssh, et l’absence éventuelle de l’identifiant dans AllowUsers. Sur le serveur, journalctl -u ssh -n 30 donne la raison ; Authentication refused: bad ownership or modes correspond au problème de permissions décrit plus haut.

Avertissement de clé hôte

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED après une réinstallation est attendu : lancez ssh-keygen -R SERVER_IP et reconnectez-vous. Si vous n’avez rien réinstallé, cherchez pourquoi avant de taper un mot de passe où que ce soit. Totalement bloqué dehors ? La console du fournisseur est la porte de retour.

Tout ce qui précède suppose une machine dont vous êtes root et sur laquelle vous pouvez vous permettre de casser sshd puis de le réparer depuis une console. Un VPS Linux chez rdp.monster est exactement cette machine : accès root complet, CPU et RAM dédiés, bande passante illimitée (fair-use), sans KYC, paiement en crypto ou en monnaie classique, à partir de $8.99 par mois, et le serveur est en ligne environ 10 secondes après confirmation du paiement, largement de quoi mettre vos clés en place avant que le premier scanner ne trouve le port 22.

Foire aux questions

Ubuntu est-il livré avec SSH activé par défaut ?

Non pour Ubuntu Desktop ; oui pour Ubuntu Server et la plupart des images cloud.

Ubuntu Desktop n’installe que le client SSH : rien n’écoute sur le port 22 tant que vous ne lancez pas sudo apt install openssh-server. Ubuntu Server demande pendant l’installation s’il faut installer le serveur OpenSSH et peut importer au passage vos clés GitHub ou Launchpad. Les images cloud et VPS livrent presque toujours openssh-server installé, activé et acceptant les connexions, car c’est la seule façon pour le fournisseur de vous remettre la machine. Vérifiez avec systemctl status ssh.

Comment vérifier que SSH tourne sur Ubuntu ?

Lancez systemctl status ssh, puis confirmez avec ss que le port 22 est en écoute.

systemctl status ssh indique si le service est actif ou activé au démarrage. Comme Ubuntu 22.10 et supérieur utilisent l’activation par socket, le service peut légitimement afficher inactive (dead) avec TriggeredBy: ssh.socket quand personne n’est connecté ; le test le plus fiable est donc sudo ss -tlnp | grep ssh : une ligne montrant 0.0.0.0:22 ou [::]:22 signifie que SSH écoute. Depuis une autre machine, ssh -v username@SERVER_IP le confirme de bout en bout.

Est-il sûr de laisser SSH sur le port 22 ?

Oui, à condition de désactiver les mots de passe et d’utiliser des clés ; le numéro de port n’apporte aucune protection.

Le port 22 attire des tentatives de connexion automatisées en permanence, mais elles ne peuvent pas aboutir sur un serveur configuré avec PasswordAuthentication no et une paire de clés, et fail2ban supprime l’essentiel du bruit. Déplacer sshd sur 2222 ou 22222 ne le cache qu’aux scanners les plus paresseux ; des scanners de ports comme nmap et masscan le trouvent en quelques minutes, et les index à l’échelle d’Internet le répertorient de toute façon. Considérez un port non standard comme une mesure d’hygiène des journaux, pas comme un contrôle de sécurité, et ne faites jamais l’impasse sur les clés sous prétexte d’avoir changé le port.

Quelle est la différence entre ssh et sshd sous Ubuntu ?

ssh est le programme client ; sshd est le démon serveur, dont l’unité Ubuntu se nomme ssh avec sshd comme alias.

ssh est le client que vous lancez sur votre ordinateur pour ouvrir une connexion ; il provient du paquet openssh-client. sshd est le démon qui répond sur le serveur, issu d’openssh-server, configuré dans /etc/ssh/sshd_config (le client lit ssh_config). Ubuntu et Debian nomment l’unité systemd ssh.service et déclarent sshd.service comme alias, si bien que systemctl restart ssh et systemctl restart sshd font la même chose ; sur Fedora, RHEL et Arch, l’unité s’appelle simplement sshd.