S'authentifier sur un Linux avec une clé
Déclaration côté client
Déclaration côté serveur
Les logs
Interdire de login mot de passe
Sur un poste de travail Linux
Le but ici est de ne plus à avoir à saisir de mot de passe pour s'authentifier sur un serveur SSH sous Linux alors qu'on a un poste de travail sous Windows.
Non seulement c'est plus pratique, et en plus c'est plus sécure.
Pour cela j'ai regardé 2 ou 3 sites pour faire marcher l'authentification sans mot de passe.
Il y a eu ssh.com mais ce n'était pas forcément une bonne idée car ce n'est pas le site officiel de ssh. Le site officiel est openssh.com d'après wikipedia), sauf qu'il n'est pas du tout attrayant.
doc.ubuntu-fr.org est du coup comme souvent un très bon choix mais entre deux je suis tombé sur pixiscreen.fr qui est moins complet mais qui a fait le job.
Bref, pour s'authentifier avec une paire de clé, cad une publique et l'autre privée, il faut déjà les générer. Pour cela on va utiliser puttygen.
Il est livré avec putty quand on l'installe, sinon on peut le récupérer sur
https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html
En remarque, si on avait été directement sur un os Linux, la paire de clés aurait pu être générée avec une simple commande, à savoir
cd
ssh-keygen -t ed25519 -b 256 -f .ssh/nom_fichiers_de_cles
En bas de l'interface, on peut choisir la taille de la clé. Là dessus l'article https://nbeguier.medium.com/a-real-world-comparison-of-the-ssh-key-algorithms-b26b0b31bfd9
préconise Ed25519 ou RSA (avec 3072 bits de longueur minimale) et de ne jamais utiliser DSA ou ECDSA.
Ce n'est pas obligatoire mais vous pouvez entrer par 2 fois une Passphrase, cad un mot de passe, qu'il vous faut noter ou retenir. Ainsi celui qui arrive à copier votre clé privée ne pourra pas s'en servir sans.
Entrer un éventuel commentaire.
Sauvegarder la clé publique et la clé privée
De là, vous pouvez basiquement côté client, cad côté putty, au niveau de votre session, indiquer sous
Connection>SSH>Auth>Credentials le chemin vers votre clé privée
Vous pouvez aussi utiliser pageant qui va gérer vos clés privées pour vous.
Pour cela, lancer pageant
Aller sur View keys
Ajouter une clé
Ajouter votre clé privée
Entrer sa passphrase
La configuration du service ssh côté serveur Linux peut se voir avec la commande
cat /etc/ssh/sshd_configVia le paramètre AuthorizedKeysFile, on voit que par défaut les clés autorisées doivent être dans
.ssh/authorized_keys
Côté de votre serveur Linux, cela va se passer au niveau du homefolder du login qui va se présenter.
Dans le répertoire du home folder il faut qu'un répertoire .ssh existe et qu'il contienne un fichier nommé authorized_keys
Donc il faut se logger avec le compte pour lequel on veut s'authentifier avec un certificat et créer le répertoire .ssh avec cette commande (enfin le répertoire existe déjà normalement)
cd
mkdir ~/.sshAjustez les droits du répertoire .ssh avec la commande
chmod 700 .sshIl faut ajouter votre clé publique dans un fichier nommé authorized_keys qui n'existe pas forcément.
Pour cela on va utiliser la commande echo à laquelle on demandera d'ajouter la clé publique dans le fichier authorized_keys.
La commande écho délimite le début et la fin de la clé par " et "
La clé publique doit être en une seule ligne, sans retour à la ligne etc
Pour copier la clé publique, dans puttygen, faire un clic droit sur cette dernière et choisir Tout sélectionner
Refaire un clic droit et copier toute la clé publique
Cote serveur coller la clé publique entre les 2 " "
La commande à adapter avec votre clé publique est donc
echo "votreclépublique" >> authorized_keysVous devez donc vous retrouver avec une commande super longue à exécuter
Sur cet autre exemple, vous remarquerez qu'en plus de la clé publique, le début de la ligne commence par ssh-rsa et qu'elle se termine par un commentaire.
C'est directement ajouté par Putty Key Generator, et c'est ce qu'il faut.
Suivant l'algorithme choisi pour la paire de clés générée, cela aurait pu commencer par autre chose que ssh-rsa, comme ecdsa-sha2-nistp521
Bref, le fichier authorized_keys doit exister et contenir votre clé publique
La ligne doit commencer par le type d'algorithme, ici ssh-rsa, et s'il y a un commentaire, il doit être à la fin.
Voila, vous devez maintenant pouvoir vous connecter avec votre paire de clés, sans à avoir à saisir un mot de passe !
Les logs d'authentification se voient avec
sudo tail -f /var/log/auth.log
#ou
sudo tail -f /var/log/secureQuand vous vous connectez avec le certificat, ce message doit passer dans les logs :
Accepted publickey for votrelogin from votreip port leport
On peut aller plus loin dans le concept et carrément interdire de se logger avec un login/mot de passe. Seul l'authentification par clé passera.
Pour cela, comme vous n'aurez plus de mot de passe, il faut autoriser votre compte à passer root dans sudo sans à avoir à saisir de mot de passe. Pour cela on va créer un fichier sous /etc/sudoers.d/ et préciser cela. Pour se faire, adapter cette commande avec votre login :
sudo echo 'youraccount ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers.d/adminsEnsuite on trouve des sites comme https://www.cyberciti.biz/faq/how-to-disable-ssh-password-login-on-linux/
qui expliquent des paramètres à modifier dans la config du serveur ssh dans /etc/ssh/sshd_config
Sachant que dans les configs modernes, il faut éviter de modifier directement /etc/ssh/sshd_config sous peine d'avoir ce message lors d'un upgrade
Dans les configs modernent, dans /etc/ssh/sshd_config on trouve un Include /etc/ssh/sshd_config.d/*.conf
ce qui permet de mettre toutes les customisations dans un fichier à part.
Pour cela on peut faire
sudo nano /etc/ssh/sshd_config.d/99-hardening.confY placer
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
ChallengeResponseAuthentication no
X11Forwarding no
AllowTcpForwarding no
PermitRootLogin no
PermitTunnel no
GatewayPorts no
UsePAM yes
Explications :
- PubkeyAuthentication à yes authorise l'authentification par clé
- PasswordAuthentication à no interdit l'usage d'un mot de passe
- KbdInteractiveAuthentication à no car inutile si on n'utilise pas du MFA
- ChallengeResponseAuthentication à no car ChallengeResponseAuthentication a été remplacé par KbdInteractiveAuthentication
- X11Forwarding à no empêche de lancer une application graphique distante via SSH. C'est inutile sur serveur sans environnement graphique et peut permettre interception ou injection X11.
- AllowTcpForwarding à no empêche le rebond sur une autre machine en ssh
- PermitTunnel à no empêche la création d’interfaces réseau tunnel (tun/tap) via SSH.
- GatewayPorts à no fait que le port reverse est bind uniquement sur localhost.
- UsePAM à yes : permet le verrouillage après échecs, la gestion des comptes expirés, permet d'être compatible CIS et auditd
Sur un poste de travail Linux, comme dit plus haut, c'est nettement plus simple. On génère la paire de clés dans .ssh avec
cd
mkdir -m 700 .ssh
ssh-keygen -t ed25519 -b 256 -f .ssh/nom_fichiers_de_clesOn autorise la clé SSH sur un poste distant avec ssh-copy-id
ssh-copy-id -i ~/.ssh/nom_fichiers_de_cles.pub utilisateur@serveur_distantSur le serveur distant, il faut vérifier un paramètre, pour cela faire
sudo nano /etc/ssh/sshd_configVérifier que PubkeyAuthentication est bien à yes et que la ligne n'est pas commentée avec un #
PubkeyAuthentication yesDe là vous pouvez maintenant spécifier à ssh l'emplacement de la clé privée avec l'option -i
cd
ssh -i .ssh/nom_fichiers_de_cles utilisateur@serveur_distantPour simplifier l'authentification SSH on peut utiliser un agent SSH et y ajouter notre clé privée.
eval `ssh-agent`
ssh-add .ssh/nom_fichiers_de_clesTéléchargement(s)
| Nom | Site Web d origine | Description |
|---|---|---|
| Putty V0.63 | http://www.chiark.greenend.org... | Client ssh Putty |
Article(s) suivant(s)
Article(s) précédent(s)