Configurer le serveur SSH de façon sûre

Module 2: SSH et clés · Temps de lecture : 12 minutes

Objectif pédagogique : À l'issue de cette leçon, vous saurez désactiver la connexion par mot de passe et la connexion root par mot de passe, vérifier quel paramètre s'applique réellement, et le faire sans vous enfermer dehors.

Notions clés : sshd, sshd_config, sshd_config.d, la première valeur compte, PasswordAuthentication, KbdInteractiveAuthentication, PermitRootLogin, AuthenticationMethods, AllowUsers, sshd -t, sshd -T, deuxième session, cloud-init, ssh.socket

D'abord le filet de sécurité

Cette leçon ferme une porte par laquelle vous devez vous-même passer. Une faute de frappe peut vous empêcher de vous reconnecter. C'est pourquoi, avant de commencer, assurez-vous toujours des points suivants :

1. Deux clés fonctionnent (leçon 2.1), et vous avez vérifié dans une nouvelle fenêtre que la connexion par clé réussit.
2. Un snapshot de votre VPS. Chez WebOké, vous le créez dans l'écran du VPS ; chez d'autres fournisseurs, on parle aussi de snapshot ou d'image. En cas de problème, vous le restaurez.
3. La console de votre fournisseur vous est familière : elle vous permet d'entrer sans SSH.
4. Votre session SSH actuelle reste ouverte jusqu'à la fin. Une session en cours continue de fonctionner lorsque vous modifiez les paramètres ou rechargez le service. Vous testez chaque modification dans une deuxième fenêtre.

Où se trouvent les paramètres

Le serveur SSH s'appelle sshd. Ses paramètres se trouvent dans /etc/ssh/sshd_config. Sur Debian et Ubuntu, cette ligne figure en haut de ce fichier :

Include /etc/ssh/sshd_config.d/*.conf

Tous les fichiers en .conf du dossier sshd_config.d sont donc lus avant le reste du fichier principal, par ordre alphabétique. C'est pratique : vous placez vos propres paramètres dans un fichier dédié et laissez le fichier principal intact, de sorte qu'une mise à jour du paquet n'affecte pas vos modifications.

Mais cela a une conséquence qui surprend beaucoup de monde. Dans sshd_config, la règle est la suivante : pour chaque paramètre, c'est la première valeur rencontrée par sshd qui compte. Les lignes suivantes portant sur le même paramètre sont ignorées. Si vous écrivez PasswordAuthentication no en bas de sshd_config, cela ne l'emporte donc pas sur un fichier de sshd_config.d qui indique yes.

Le piège de cloud-init

De nombreuses images de VPS sont configurées au premier démarrage par cloud-init. Selon la configuration de l'image et de l'installation, cloud-init écrit un fichier tel que /etc/ssh/sshd_config.d/50-cloud-init.conf contenant par exemple :

PasswordAuthentication yes

Comme ce fichier est lu avant le fichier principal, la connexion par mot de passe reste active, quoi que vous écriviez dans sshd_config. Ne le supposez donc pas, vérifiez :

root@web1:~# grep -ri passwordauthentication /etc/ssh/sshd_config /etc/ssh/sshd_config.d/
/etc/ssh/sshd_config:#PasswordAuthentication yes
/etc/ssh/sshd_config.d/50-cloud-init.conf:PasswordAuthentication yes

Deux solutions propres : modifiez ce fichier en no, ou placez vos propres paramètres dans un fichier qui vient plus tôt dans l'ordre alphabétique, comme 00-beveiliging.conf. Un fichier 99-mijn.conf, en revanche, ne fonctionne pas, car cloud-init l'a alors déjà emporté.

Les paramètres qui comptent

Créez votre propre fichier :

root@web1:~# nano /etc/ssh/sshd_config.d/00-beveiliging.conf

avec ce contenu :

# Connexion uniquement par clé
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password

Que signifie chaque ligne ?

• PasswordAuthentication no : le serveur n'accepte plus de mot de passe. La valeur par défaut d'OpenSSH est yes.
• KbdInteractiveAuthentication no : « keyboard-interactive » est une deuxième façon de demander un mot de passe, via PAM. Si vous la laissez active, quelqu'un peut quand même essayer un mot de passe, même si PasswordAuthentication est sur no. Dans les anciens guides, ce paramètre s'appelle ChallengeResponseAuthentication ; depuis OpenSSH 8.7, c'est un autre nom, obsolète, pour la même chose. Debian le met déjà sur no par défaut, mais indiquez-le tout de même : c'est plus clair et cela reste correct sur d'autres systèmes.
• PermitRootLogin prohibit-password : root peut se connecter, mais uniquement avec une clé. C'est la valeur par défaut depuis OpenSSH 7.0. Plus strict : PermitRootLogin no, root ne peut plus du tout entrer via SSH ; vous vous connectez en tant qu'utilisateur ordinaire et utilisez sudo (leçon 3.2). Ne mettez no que lorsque vous êtes certain que la connexion avec cet utilisateur et sudo fonctionnent.

En option, pour ceux qui veulent aller plus loin :

AllowUsers anna
AuthenticationMethods publickey

AllowUsers n'autorise que les utilisateurs indiqués ; tout autre nom est refusé, même s'il possède une clé valide. Pratique, mais ne vous oubliez pas vous-même, et n'oubliez pas de compléter la liste si vous ajoutez un deuxième administrateur. AuthenticationMethods publickey indique en une seule ligne que seules les clés sont acceptées.

Tester, appliquer, vérifier

Faites d'abord vérifier le fichier par sshd. Cela ne démarre rien et ne modifie rien :

root@web1:~# sshd -t
root@web1:~#

Aucune sortie signifie : aucune erreur. En cas de faute de frappe, vous voyez la ligne et le fichier concernés. Ce n'est qu'ensuite que vous rechargez le service :

root@web1:~# systemctl reload ssh

Sur Debian et Ubuntu, le service s'appelle ssh ; sur AlmaLinux et Rocky Linux, sshd.

Vérifiez ensuite quelle valeur s'applique réellement. sshd -T affiche la configuration complète et calculée, avec tous les fichiers Include pris en compte :

root@web1:~# sshd -T | grep -Ei 'passwordauth|kbdinteractive|permitrootlogin'
permitrootlogin without-password
passwordauthentication no
kbdinteractiveauthentication no

(without-password est l'ancien nom de prohibit-password. Les versions d'OpenSSH antérieures à 10.1, comme sur Debian 13 et Ubuntu 24.04, affichent encore l'ancien nom ; les plus récentes affichent prohibit-password. Cela signifie la même chose.)

Et maintenant le plus important : testez dans une deuxième fenêtre, pendant que la première reste ouverte.

anna@laptop:~$ ssh anna@192.0.2.10
anna@web1:~$

Si cela fonctionne, essayez volontairement de vous connecter avec un mot de passe. Cela doit échouer :

anna@laptop:~$ ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no anna@192.0.2.10
anna@192.0.2.10: Permission denied (publickey).

Après Permission denied figurent entre parenthèses les méthodes de connexion que le serveur propose encore. S'il n'y a que publickey, tout est en ordre. Si password ou keyboard-interactive apparaît aussi, une autre valeur s'applique encore quelque part : vérifiez de nouveau avec sshd -T.

C'est précisément cette liste que l'exercice du cours vérifie aussi, depuis l'extérieur. À chaque connexion, votre client SSH demande d'abord quelles méthodes sont autorisées, au moyen d'une requête de type « none ». Le serveur répond avec la liste, sans qu'aucun mot de passe ni aucune clé ne soit essayé.

Ubuntu 24.04 et versions ultérieures : ssh.socket

Sur Ubuntu depuis la version 22.10, ce n'est pas sshd lui-même qui écoute sur le port 22, mais systemd, via ssh.socket. Ce n'est qu'à l'arrivée d'une connexion que systemd démarre le service SSH. Pour les paramètres de cette leçon, cela ne change rien : systemctl reload ssh ou restart ssh suffit.

Cela compte en revanche si vous modifiez le port ou l'adresse d'écoute (Port, ListenAddress). Depuis Ubuntu 24.04, systemd lit ces valeurs dans sshd_config, mais uniquement après :

root@web1:~# systemctl daemon-reload
root@web1:~# systemctl restart ssh.socket

Si vous l'oubliez, le serveur continue simplement d'écouter sur l'ancien port. Pire encore : si vous configurez d'abord votre pare-feu sur un nouveau port et que SSH reste sur l'ancien, vous vous enfermez dehors. Vérifiez toujours avec ss -tlnp | grep ssh sur quoi le serveur écoute réellement (leçon 5.1), et ouvrez le nouveau port dans votre pare-feu avant de fermer l'ancien. La leçon 2.3 explique si un autre port a un intérêt.

Si les choses tournent mal malgré tout

Si vous ne parvenez plus à entrer, ouvrez la console de votre fournisseur, connectez-vous en tant que root (avec le mot de passe, car la console est un « clavier branché sur le serveur » et non du SSH) et annulez votre fichier :

root@web1:~# mv /etc/ssh/sshd_config.d/00-beveiliging.conf /root/
root@web1:~# systemctl reload ssh

Si cela ne fonctionne pas non plus, restaurez le snapshot. Chez WebOké, vous pouvez aussi définir un nouveau mot de passe root dans l'écran du VPS ; d'autres fournisseurs proposent souvent un bouton similaire ou un mode de secours (rescue).

Sur AlmaLinux et Rocky Linux

Le service s'appelle sshd (systemctl reload sshd). Là aussi, un Include /etc/ssh/sshd_config.d/*.conf figure en haut du fichier et le système fournit ses propres fichiers dans ce dossier ; la même règle « la première valeur compte » s'applique. Si vous changez de port, SELinux doit aussi autoriser ce port (semanage port -a -t ssh_port_t -p tcp 2222) et firewalld doit l'ouvrir.

Résumé

• Dans sshd_config, la première valeur compte ; les fichiers de sshd_config.d sont lus en premier. Placez vos propres paramètres dans un fichier tel que 00-beveiliging.conf.
• Définissez PasswordAuthentication no et KbdInteractiveAuthentication no ; root uniquement avec une clé (prohibit-password) ou pas du tout (no).
• Vérifiez avec sshd -t avant de recharger, et avec sshd -T quelle valeur s'applique réellement ; attention à un 50-cloud-init.conf.
• Testez dans une deuxième fenêtre et gardez la première session ouverte. Familiarisez-vous avec la console et créez un snapshot au préalable.
• Sur Ubuntu 24.04+, un autre port nécessite systemctl daemon-reload et systemctl restart ssh.socket.

Quiz

Exercice

Exercice Z2.2 : La connexion par mot de passe est désactivée. Désactivez la connexion par mot de passe et keyboard-interactive comme dans cette leçon, puis laissez le programme vérifier depuis l'extérieur. Indiquez l'adresse IP ou le nom d'hôte de votre serveur, le port SSH (22 par défaut) et le nom d'utilisateur avec lequel vous vous connectez vous-même (par exemple anna, et non root ou un nom inventé). Le programme ne se connecte pas : il demande seulement, comme tout client SSH avant la connexion, quelles méthodes de connexion votre serveur propose pour cet utilisateur. Le bon résultat : uniquement publickey.

Pour aller plus loin

Les étapes décrites dans ces articles concernent l'écran du VPS de WebOké ; chez d'autres fournisseurs, le fonctionnement est similaire.

• Sécuriser votre VPS : les cinq premières minutes
• Plus d'accès à votre VPS : que faire ?
• Snapshots et sauvegardes de votre VPS
• Manuel de sshd_config : https://man.openbsd.org/sshd_config
• Ubuntu : SSHd now uses socket-based activation : https://discourse.ubuntu.com/t/sshd-now-uses-socket-based-activation-ubuntu-22-10-and-later/30189