Se connecter en SSH via une paire de clefs

Rédigé par Alexandre il y a 1 mois

#auto-hébergement #debian #loisir

Depuis bien longtemps, j'utilise cet article comme documentation, mais je me suis dit que ça ne serait pas mal de faire la mienne.

L'idée ici est de générer deux clefs permettant de rendre la connexion SSH fluide mais aussi de pouvoir exécuter des tâches. Il est nécessaire de créer deux clefs :

  • la clef privée : à ne jamais transmettre à qui que ce soit, elle permet d'identifier qui glisse la clef dans la serrure
  • la clef publique : qui doit être placée sur l'ensemble des machines où l'on souhaite se connecter, c'est elle la clef de la serrure

Emplacement

Avant de générer la paire de clefs, il est nécessaire de créer le dossier qui va la contenir, pour se faire :

mkdir ~/.ssh

La clef privée devant être... privée... restreindre son accès à l'utilisateur courant, pour cela je restreins directement l'accès au dossier qu'on vient de créer :

chmod go-rwx ~/.ssh

Création

Générer la paire de clefs :

ssh-keygen -b 4096 -t ed25519 -f ~/.ssh/id_ed25519 -P ""

Deux fichiers sont alors générés :

  • id_ed25519 qui contient la clef privée
  • id_ed25519.pub qui contient la clef publique

Déployer la clef sur un serveur, le mot de passe SSH est demandé pour la dernière fois :

ssh-copy-id -i ~/.ssh/id_ed25519.pub UTILISATEUR@SERVEUR

Sécurisation

Une fois que la clef est déployée, tester la connexion SSH au serveur. Si tout s'est déroulé correctement, le serveur ne vous demande plus de mot de passe. Maintenant que la clef fonctionne, on va sécuriser un peu notre serveur SSH :

  • Port 12345: changer le port SSH pour 12345 (ne pas utiliser ce portsshd !)
  • PermitRootLogin no : empêcher le super-utilisateur de se connecter en SSH
  • PasswordAuthentication no : désactiver l'authentification par mot de passe
  • Banner none : ne pas révéler d'information à quelqu'un qui n'est pas connecté

Voici comment ajouter ces paramètres (penser à changer le port !) :

sudo tee --append /etc/ssh/sshd_config <<EOF

# Custom
Port 12345
PermitRootLogin no
PasswordAuthentication no
Banner none
EOF

Adapter la configuration du pare-feu, ici nftables :

[[ -f /etc/nftables.conf ]] && sudo sed -i 's/tcp dport 22 accept/tcp dport 12345 accept/g' /etc/nftables.conf

Redémarrer le serveur SSH :

sudo systemctl restart sshd

Ouvrir un autre terminal et tenter de se connecter au serveur. Si cela ne fonctionne pas, revenir au premier terminal pour commenter les lignes ajoutée précédemment, redémarrer le serveur SSH et chercher ce qui ne va pas.

Terminer en appliquant la configuration du pare-feu :

sudo systemctl restart nftables

Conclusion

Chaque utilisateur d'une machine doit avoir sa propre paire de clefs. Cela permet qu'en cas de compromission de son compte, sa clef publique peut tout simplement être retirée des serveurs sur lesquels il se connectait.

La clef privée est quelque chose de sensible et qu'il ne faut absolument pas perdre. Personnellement, je conserve la paire de clefs que j'ai généré sur mon poste principal dans ma base de données KeepassXC. Cela évite de n'avoir aucune solution de repli en cas de problème avec l'ensemble de mon matériel (destruction de mon lieu d'habitat par exemple).

A titre d'information et pour vraiment conclure cet article, l'utilisation d'une paire de clefs me permet d'externaliser les sauvegardes de mes serveurs via rsync ou rclone.