Se connecter en SSH via une paire de clefs
Rédigé par Alexandre le 2020-05-01
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 pour12345
(ne pas utiliser ce port sshd !)PermitRootLogin no
: empêcher le super-utilisateur de se connecter en SSHPasswordAuthentication no
: désactiver l'authentification par mot de passeBanner 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
DebianBanner no
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
Complément
Verrouiller l'utilisateur root via la commande suivante :
sudo passwd --lock root
Réactiver, si besoin, en définissant un mot de passe pour root avec la commande suivante :
sudo passwd root
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.