SSH sur Debian 13 : se connecter avec une clé plutôt qu’un mot de passe

Quand on installe un serveur Debian, SSH arrive très vite dans la conversation.

C’est pratique, indispensable même, mais c’est aussi l’une des premières portes que les robots vont venir tester si le serveur est exposé sur Internet.

Par défaut, beaucoup de machines acceptent encore une connexion avec :

utilisateur + mot de passe

Ça fonctionne. Mais côté sécurité, ce n’est pas l’idéal. Un mot de passe peut être faible, réutilisé, volé, testé automatiquement, ou simplement tapé un peu trop souvent au mauvais endroit.

L’objectif ici est donc simple : passer sur une connexion SSH par clé publique / clé privée, vérifier que tout fonctionne, puis couper l’authentification par mot de passe.

Clé privée

Elle reste sur le poste client. C’est elle qui prouve votre identité au moment de la connexion.

Clé publique

Elle est déposée sur le serveur dans le fichier authorized_keys de l’utilisateur.

Mot de passe coupé

Une fois la clé validée, les tentatives de brute force sur mot de passe deviennent inutiles.

Pourquoi passer sur une clé SSH ?

Avec une connexion par mot de passe, le serveur doit accepter qu’un client tente de s’authentifier en envoyant un secret humain.

Et un secret humain, c’est rarement parfait.

Même avec un bon mot de passe, le service SSH reste une cible classique :

➡️ scan automatique du port 22 ;
➡️ test de comptes courants comme root, admin, debian, test ;
➡️ dictionnaires de mots de passe ;
➡️ tentatives lentes pour passer sous les radars.

Avec une clé SSH, on change de logique.

Le serveur ne demande pas à recevoir votre mot de passe. Il vérifie que votre client possède bien la clé privée qui correspond à une clé publique autorisée côté serveur.

La clé privée ne doit jamais être copiée sur le serveur. Elle reste sur votre poste, idéalement protégée par une passphrase.

La nuance importante

La clé n’empêche pas les robots de tenter une connexion SSH. En revanche, si on désactive ensuite PasswordAuthentication et KbdInteractiveAuthentication, les tentatives par mot de passe ne peuvent plus aboutir. Le brute force classique perd donc son intérêt.

Changer le port SSH par défaut peut aussi aider à réduire le bruit dans les logs. Ce n’est pas une vraie protection cryptographique, et ça ne remplace pas les clés, mais passer de 22 à un port moins évident évite une partie des scans automatiques les plus basiques.

Clé ou mot de passe : la vraie différence

Connexion par mot de passe

Principe

Le serveur accepte un secret tapé par l’utilisateur.

Point faible

Le secret peut être testé, réutilisé, deviné, intercepté ou retrouvé dans une fuite.

Le problème

Tant que cette méthode reste active, un robot peut continuer à tenter sa chance.

Connexion par clé SSH

Principe

Le serveur vérifie une preuve cryptographique liée à une clé publique autorisée.

Point faible

La clé privée doit rester protégée, idéalement avec une passphrase solide.

Le gain

Une fois les mots de passe coupés, le brute force classique n’a plus de prise utile.

Dans les deux cas, il faut rester propre.

Une clé privée sans passphrase, stockée n’importe où, ce n’est pas magique. Mais une clé moderne, protégée, avec l’authentification par mot de passe désactivée côté serveur, c’est déjà un énorme cran au-dessus.

Avant de commencer

Pour la partie tuto, mon environnement de lab est le suivant :

🔹une petite VM sous Debian 13 ;
🔹le service SSH est déjà installé ;
🔹l’utilisateur distant existe déjà.

Je vais utiliser ces valeurs dans les commandes, à adapter bien sûr en fonction de votre infra :

Utilisateur serveur : debian
Serveur             : srv-debian.uopslab.local
Clé côté client     : ~/.ssh/id_ed25519_srv-debian
Port SSH final      : 7122

Ne fermez pas votre session actuelle

Gardez toujours une session SSH ouverte pendant les changements. On teste une nouvelle connexion dans un deuxième terminal avant de redémarrer ou de fermer quoi que ce soit. C’est le genre de prudence qui évite une soirée console de secours.

1. Vérifier l’état SSH du serveur

Sur le serveur Debian, on commence par vérifier que le service SSH est bien présent et actif.

sudo systemctl status ssh

On peut aussi vérifier la configuration réellement prise en compte par OpenSSH :

sudo sshd -T | grep -E '^(port|pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|permitrootlogin|authorizedkeysfile)'

Sur une configuration classique, PubkeyAuthentication est déjà activé par défaut, vous devriez avoir une sortie de ce style :

port 22
permitrootlogin without-password
pubkeyauthentication yes
passwordauthentication yes
kbdinteractiveauthentication no
authorizedkeysfile .ssh/authorized_keys .ssh/authorized_keys2

2. Sauvegarder la configuration SSH

Avant de modifier quoi que ce soit, on sauvegarde le fichier principal.

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F-%H%M)

Et on garde aussi une copie de la configuration effective, très pratique pour comparer après modification :

sudo sshd -T > ~/sshd-effective-before.txt

Le fichier principal sshd_config contient normalement une ligne Include /etc/ssh/sshd_config.d/*.conf en tête. Donc si vous ajoutez un fichier de configuration spécifique avec l’extension .conf, il sera pris en compte. C’est bien plus propre pour ajouter notre configuration sans transformer le fichier d’origine.

3. Générer la clé côté client

La paire de clés se génère sur le poste client, pas sur le serveur.

Sur Linux, macOS, ou Windows avec OpenSSH disponible dans le terminal, ici je vais le faire depuis mon WSL :

ssh-keygen -t ed25519 -a 100 -C "debian@srv-debian" -f ~/.ssh/id_ed25519_srv-debian

Vous serez invité à saisir une passphrase. Je conseille vraiment d’en mettre une, ça rajoute une barrière si quelqu’un récupère votre fichier de clé privée.

Donc après tout ça, vous obtenez cette sortie et les deux fichiers :

DooSys@UopsLAB:~$ ssh-keygen -t ed25519 -a 100 -C "DooSys@UopsLAB" -f ~/.ssh/id_ed25519_srv-debian
Generating public/private ed25519 key pair.
Enter passphrase for "/home/DooSys/.ssh/id_ed25519_srv-debian" (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/DooSys/.ssh/id_ed25519_srv-debian
Your public key has been saved in /home/DooSys/.ssh/id_ed25519_srv-debian.pub
The key fingerprint is:
SHA256:qntmTehzxz7qaneDY9cNY/uRD8XzFeXHHuBKTKfn91E debian@srv-debian
The key's randomart image is:
+--[ED25519 256]--+
|           . o  .|
|          o + .o.|
|           + o oE|
|          . +  o=|
|       .S  . . +=|
|      ...   + .o*|
|     ..o o o =+ o|
|     .B B B o .+ |
|    o*.BoB.o .. .|
+----[SHA256]-----+

~/.ssh/id_ed25519_srv-debian      # clé privée, à garder secrète
~/.ssh/id_ed25519_srv-debian.pub  # clé publique, à copier sur le serveur

La clé privée ne quitte pas le client

Le fichier sans extension .pub est la clé privée. On ne l’envoie pas par mail, on ne la colle pas dans un ticket, on ne la copie pas sur le serveur. Seule la clé publique, celle qui termine par .pub, doit être déposée côté serveur.

4. Installer la clé publique sur le serveur

Donc sur le serveur, si vous n’avez pas encore de répertoire .ssh dans votre home, vous venez le créer comme ça :

sudo mkdir -p ~/.ssh
sudo chmod 700 ~/.ssh
sudo nano ~/.ssh/authorized_keys
sudo chmod 600 ~/.ssh/authorized_keys

Dans authorized_keys, on colle le contenu de la clé publique id_ed25519_srv-debian.pub, sur une seule ligne.

Puis on vérifie le propriétaire :

sudo chown -R "$USER:$USER" ~/.ssh

5. Tester la connexion par clé

Depuis le client, on force un test par clé uniquement :

ssh -i ~/.ssh/id_ed25519_srv-debian -o PreferredAuthentications=publickey -o PasswordAuthentication=no debian@srv-debian.uopslab.local

Si la connexion fonctionne, c’est bon signe. On est d’accord que vous pouvez aussi remplacer srv-debian.uopslab.local par l’IP de votre serveur.

Et côté client Windows ?

Personnellement, j’utilise MobaXterm pour gérer mes consoles SSH et RDP. On peut aussi y déclarer et générer ses clés SSH. Je pense que j’en ferai un tutoriel dédié prochainement.

6. Désactiver l’authentification par mot de passe

Une fois la connexion par clé testée, on peut verrouiller le serveur.

Sur Debian 13, je préfère créer un fichier dédié :

sudo nano /etc/ssh/sshd_config.d/99-key-only.conf

Avec ce contenu :

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password

Explication rapide :

Directive	Rôle
`PubkeyAuthentication yes`	Autorise l’authentification par clé publique
`PasswordAuthentication no`	Désactive l’authentification SSH par mot de passe
`KbdInteractiveAuthentication no`	Coupe les méthodes interactives qui peuvent encore passer par PAM
`PermitRootLogin prohibit-password`	Interdit le login root par mot de passe, tout en laissant possible la clé si vraiment configurée

Connexion root directe

Personnellement, sur un serveur classique, je préfère même éviter la connexion directe en root et passer par un utilisateur sudo.

Dans ce cas, vous pouvez mettre :

PermitRootLogin no

7. Changer le port SSH par défaut

Tant qu’on est dans la configuration SSH, on peut aussi changer le port par défaut.

Le port 22 est scanné en permanence. Mettre SSH sur un autre port ne rend pas le serveur invisible, mais ça réduit fortement le bruit automatique et les tentatives opportunistes.

Dans le même fichier :

sudo nano /etc/ssh/sshd_config.d/99-key-only.conf

On ajoute la directive Port.

Par exemple :

Port 7122
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password

Vous pouvez choisir un autre port, mais évitez les ports déjà utilisés par un autre service. Pour vérifier rapidement :

sudo ss -tulpn | grep ':7122'

Si la commande ne retourne rien, le port n’est probablement pas déjà en écoute.

Pensez au pare-feu avant le reload

Si un pare-feu filtre les connexions entrantes, ouvrez le nouveau port avant de recharger SSH. Sinon, la configuration sera correcte, mais vous ne pourrez pas entrer.

Avec UFW :

sudo ufw allow 7122/tcp
sudo ufw status

Avec nftables ou un pare-feu côté hébergeur, il faut adapter la règle pour autoriser le TCP entrant sur 7122.

8. Valider la configuration avant reload

Avant de recharger SSH, on vérifie la syntaxe :

sudo sshd -t

S’il n’y a aucun retour, c’est bon.

Ensuite seulement, on recharge le service :

sudo systemctl reload ssh

Puis on vérifie la configuration effective :

sudo sshd -T | grep -E '^(port|pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|permitrootlogin)'

On doit obtenir quelque chose dans cet esprit :

port 7122
pubkeyauthentication yes
passwordauthentication no
kbdinteractiveauthentication no
permitrootlogin prohibit-password

9. Tester depuis un deuxième terminal

📢📢 Très important 📢📢 : on ne ferme pas la session déjà ouverte.

Depuis un deuxième terminal côté client :

ssh srv-debian

Sans entrée ~/.ssh/config, il faut préciser le port :

ssh -p 7122 -i ~/.ssh/id_ed25519_srv-debian debian@srv-debian.uopslab.local

Puis on teste volontairement que le mot de passe ne passe plus :

ssh -p 7122 -o PreferredAuthentications=password -o PubkeyAuthentication=no debian@srv-debian.uopslab.local

La connexion doit échouer, car le serveur ne doit plus accepter l’authentification par mot de passe.

Quand tout est validé

Après plusieurs tests réussis sur le nouveau port, et seulement quand vous êtes sûr que la connexion par clé fonctionne, vous pouvez retirer l’ancien port SSH du pare-feu.

Si l’ancien port était le port par défaut :

sudo ufw delete allow 22/tcp

10. En cas de problème

Si la connexion par clé ne fonctionne pas, les causes sont souvent très simples. Commencez par vérifier les permissions :

ls -ld ~/.ssh                     -> 700
ls -l ~/.ssh/authorized_keys      -> 600

Vérifiez aussi que la clé publique est bien sur une seule ligne dans authorized_keys.

Côté client, si besoin de plus d’infos, lancez une connexion en mode verbeux :

ssh -vvv -p 7122 -i ~/.ssh/id_ed25519_srv-debian debian@srv-debian.uopslab.local

Et côté serveur, regardez les logs :

sudo journalctl -u ssh -n 80 --no-pager

Et pas de panique, on a tout sauvegardé. Donc si vous avez besoin de revenir rapidement en arrière :

sudo mv /etc/ssh/sshd_config.d/99-key-only.conf /etc/ssh/sshd_config.d/99-key-only.conf.disabled
sudo sshd -t
sudo systemctl reload ssh

À retenir

Passer SSH en authentification par clé, ce n’est pas juste “remplacer un mot de passe par un fichier”.

C’est changer le modèle d’authentification :

➡️ la clé privée reste côté client ;
➡️ la clé publique est autorisée côté serveur ;
➡️ le serveur vérifie une preuve cryptographique ;
➡️ le mot de passe SSH peut ensuite être désactivé.

Et c’est surtout cette dernière étape qui casse l’intérêt du brute force classique. Les robots pourront toujours frapper à la porte. Mais sans authentification par mot de passe disponible, ils n’ont plus grand-chose à tester.