Cours RechercherCtrl K

Sécuriser un serveur Leçon 2

Se connecter avec une clé SSH

Remplacer le mot de passe par une paire de clés, puis interdire les connexions par mot de passe et en root.

30 min

À la fin de cette leçon, tu sauras

  • Comprendre la paire clé privée / clé publique
  • Créer une clé et l'installer sur le serveur
  • Durcir la configuration du serveur SSH sans se bloquer dehors

Le problème des mots de passe

Ouvre le journal de n'importe quel serveur sur Internet : des milliers de tentatives par jour essaient root / 123456, admin / admin… Un mot de passe peut être deviné, volé ou réutilisé. Une clé SSH, non.

Une paire de clés

  • la clé privée reste sur ton ordinateur, et ne le quitte jamais (comme la clé de chez toi) ;
  • la clé publique (le fichier .pub) se donne au serveur (comme une serrure qu'on installe : la montrer ne risque rien).

À la connexion, le serveur pose une « question » que seule la clé privée sait résoudre. Rien de secret ne passe sur le réseau.

# sur TON ordinateur (Windows PowerShell, macOS ou Linux)
ssh-keygen -t ed25519 -C "moi@mon-pc"       # crée ~/.ssh/id_ed25519 et id_ed25519.pub
ssh-copy-id eleve@mon-serveur.fr             # installe la clé publique sur le serveur
ssh eleve@mon-serveur.fr                     # plus de mot de passe demandé

Sous Windows : ssh-copy-id n'existe pas. On copie le contenu de id_ed25519.pub à la fin du fichier ~/.ssh/authorized_keys du serveur. C'est tout ce que fait ssh-copy-id.

Durcir le serveur SSH

Une fois la connexion par clé testée, on ferme les autres portes. Plutôt que de modifier le gros fichier /etc/ssh/sshd_config, on ajoute un petit fichier à nous dans /etc/ssh/sshd_config.d/ : il est lu en premier, et une mise à jour de Debian ne l'écrasera pas.

echo "PasswordAuthentication no" | sudo tee /etc/ssh/sshd_config.d/10-securite.conf
echo "PermitRootLogin no" | sudo tee -a /etc/ssh/sshd_config.d/10-securite.conf
sudo sshd -t                      # vérifie la configuration : rien ne s'affiche = tout va bien
sudo systemctl reload ssh         # applique, sans couper les connexions en cours

Pourquoi | sudo tee et pas sudo echo … > fichier ? Parce que la redirection > est faite par ton shell, sans les droits administrateur. tee, lancé avec sudo, écrit le fichier lui-même ; -a ajoute à la fin au lieu d'écraser.

Attention : garde toujours ta session SSH actuelle ouverte, et teste la nouvelle configuration dans une deuxième fenêtre. Si quelque chose ne va pas, tu peux encore corriger depuis la première.

sudo sshd -T affiche la configuration réellement appliquée, toutes options confondues : sudo sshd -T | grep passwordauthentication vérifie une option précise.

À retenir

  • La clé privée ne quitte jamais ton ordinateur ; la clé publique (.pub) va dans ~/.ssh/authorized_keys du serveur.
  • ssh-keygen -t ed25519 -C "moi@pc", puis ssh-copy-id utilisateur@serveur.
  • Ses réglages dans un fichier à soi : /etc/ssh/sshd_config.d/10-securite.conf.
  • PasswordAuthentication no et PermitRootLogin no, une fois la clé testée.
  • Toujours sudo sshd -t avant sudo systemctl reload ssh, et garder une session ouverte.

Voir la fiche de révision de cette leçon (à imprimer ou à relire avant un contrôle)

Exercice 1 · Ta première paire de clés

Facile

Dans ce terminal, le « serveur » est simulé par la même machine.

  1. crée une paire de clés de type ed25519, avec le commentaire eleve@pc ;
  2. liste le contenu de ton dossier ~/.ssh ;
  3. affiche ta clé publique (jamais la privée !) ;
  4. installe-la sur le serveur avec ssh-copy-id eleve@serveur.
commandes.sh
eleve@cours: ~

Tape tes commandes ici ou dans le fichier à gauche : chaque commande tapée dans le terminal est ajoutée au fichier.

Consignes à réussir

  • À faire : La clé publique ~/.ssh/id_ed25519.pub existe
  • À faire : Le commentaire est eleve@pc
  • À faire : La clé publique est affichée
  • À faire : La clé privée n'est jamais affichée
  • À faire : La clé est installée sur le serveur (authorized_keys)
Toujours bloqué ? Voir une solution 
ssh-keygen -t ed25519 -C "eleve@pc"
ls ~/.ssh
cat ~/.ssh/id_ed25519.pub
ssh-copy-id eleve@serveur

Exercice 2 · Fermer la porte aux mots de passe

Moyen

La connexion par clé fonctionne. Crée le fichier /etc/ssh/sshd_config.d/10-securite.conf qui :

  1. interdit la connexion par mot de passe (PasswordAuthentication no) ;
  2. interdit la connexion directe en root (PermitRootLogin no) ;
  3. limite à 3 essais par connexion (MaxAuthTries 3).

Vérifie ensuite la configuration avec sshd -t, puis recharge le service ssh.

commandes.sh
eleve@cours: ~

Tape tes commandes ici ou dans le fichier à gauche : chaque commande tapée dans le terminal est ajoutée au fichier.

Consignes à réussir

  • À faire : PasswordAuthentication vaut no
  • À faire : PermitRootLogin vaut no
  • À faire : MaxAuthTries vaut 3
  • À faire : Le réglage est dans sshd_config.d/10-securite.conf
  • À faire : La configuration est vérifiée (sshd -t) avant le rechargement
Toujours bloqué ? Voir une solution 
echo "PasswordAuthentication no" | sudo tee /etc/ssh/sshd_config.d/10-securite.conf
echo "PermitRootLogin no" | sudo tee -a /etc/ssh/sshd_config.d/10-securite.conf
echo "MaxAuthTries 3" | sudo tee -a /etc/ssh/sshd_config.d/10-securite.conf
sudo sshd -t
sudo systemctl reload ssh

Exercice 3 · Une faute de frappe dangereuse

Pour aller plus loin

Un collègue a modifié la configuration SSH, mais il a fait une faute de frappe. S'il redémarre le serveur, SSH ne démarrera plus.

  1. lance la vérification de la configuration et lis le message d'erreur ;
  2. regarde le fichier fautif ;
  3. réécris-le correctement (il doit contenir PasswordAuthentication no) ;
  4. vérifie à nouveau, puis affiche la valeur appliquée de passwordauthentication avec sshd -T et grep.
commandes.sh
eleve@cours: ~

Tape tes commandes ici ou dans le fichier à gauche : chaque commande tapée dans le terminal est ajoutée au fichier.

Consignes à réussir

  • À faire : La configuration est valide
  • À faire : PasswordAuthentication vaut no
  • À faire : Le fichier fautif est affiché
  • À faire : La valeur appliquée est vérifiée avec sshd -T
Toujours bloqué ? Voir une solution 
# la faute du collègue (ne pas modifier)
echo "PaswordAuthentication no" | sudo tee /etc/ssh/sshd_config.d/10-securite.conf

# à toi :
sudo sshd -t
cat /etc/ssh/sshd_config.d/10-securite.conf
echo "PasswordAuthentication no" | sudo tee /etc/ssh/sshd_config.d/10-securite.conf
sudo sshd -t
sudo sshd -T | grep passwordauthentication

Quiz

1Quel fichier donnes-tu au serveur ?
2Pourquoi sudo echo "x" > /etc/ssh/… échoue-t-il ?
3Que fais-tu juste avant systemctl reload ssh ?