SSH – Authentification par clés
Génération des clés
Les clés seront générées et sauvegardées automatiquement dans le répertoire $HOME/.ssh de l’utilisateur courant.
Une passphrase (un mot de passe) sera demandée pendant la procédure de génération : elle permet de protéger la clé privée au cas où un tiers s’en emparerait. La clé privée protégée ne pourra pas être utilisée sans la passphrase que vous avez renseignée.
Si vous ne souhaitez pas que la clé soit protégée, vous pouvez laisser le champ vide et valider.
Notez qu’on peut ajouter un commentaire, dans le fichier de la clé publique, avec la commande ssh-keygen -t rsa -C "commentaire"
.
Vous obtenez donc 2 fichiers :
- « id_rsa« , la clé privée
- « id_rsa.pub« , la clé publique
Téléchargez la clé privée sur votre ordinateur local (le client), est sauvegardez-là en lieu sûr : elle ne doit en aucun cas être volée par un tiers, puisque c’est elle qui autorise les connexions.
Une fois téléchargée, vous devez supprimer la clé privée du serveur :
N.B. : ici nous avons généré les clés sur un serveur distant, il aurait été plus convenable de les générer sur le poste client (on évite ainsi le transfert de la clé privée).
Conversion de la clé privée au format PuTTY
Pour pouvoir vous connecter avec PuTTY ou WinSCP, la clé privée doit être au format PuTTY, voici donc la procédure à suivre :
- téléchargez PuTTYgen (site officiel),
- exécutez PuTTYgen et allez dans « Conversions » puis « Import key »,
- ensuite sélectionnez la clé privée « id_rsa » pour la charger dans le programme,
- cliquez sur le bouton « Save private key » et choisissez un fichier de destination pour sauvegarder la clé au format PuTTY « .ppk« .
Autoriser la clé publique
Nous devons autoriser les connexions par jeu de clés sur le serveur, pour cela il suffit d’ajouter la clé publique au fichier « authorized_keys » (ou « authorized_keys2 » mais ce nom de fichier est déprécié, même si les deux fonctionnent normalement) de l’utilisateur avec lequel on va se connecter.
Veuillez noter que le serveur peut gérer plusieurs clés publiques : il suffit d’ajouter une clé par ligne dans le fichier « authorized_keys« .
Activer l’authentification par clés
Vous devez ajouter/modifier les directives suivantes dans le fichier de configuration d’OpenSSH (/etc/ssh/sshd_config) :
Rechargez la configuration du serveur OpenSSH :
Testez la connexion en utilisant la clé privée avec PuTTY ou WinSCP.
Désactiver les mots de passe
Vous pouvez désactiver la connexion par mot de passe si le test a été concluant.
Vous devez ajouter/modifier les directives suivantes dans le fichier de configuration d’OpenSSH (/etc/ssh/sshd_config) :
Rechargez la configuration du serveur OpenSSH :
Limiter les connexions
Vous pouvez spécifier quels utilisateurs sont autorisés à se connecter via le serveur SSH, il suffit pour cela d’ajouter leur nom à la directive « AllowUsers » en les séparant par un espace, toujours dans le fichier de configuration d’OpenSSH (/etc/ssh/sshd_config) :
Rechargez la configuration du serveur OpenSSH :
Connexion
Pour se connecter avec le client SSH dans un terminal :
La spécification du port avec le paramètre p
est facultative, par défaut le port 22 est utilisé.
On peut forcer l’utilisation d’une clé privée avec le paramètre i
, on peut l’omettre si les clés sont bien présentes dans le dossier $HOME/.ssh
(le client tentera alors la connexion avec chaque clé privée trouvée), ou dans le cas où un fichier de configuration $HOME/.ssh/config
existe et est correctement renseigné.
A des fins de debugging, pour savoir quelles clés sont proposées au serveur, on peut lancer une connexion en mode verbeux et chercher les lignes commençant par « Offering… »
Configuration de connexion client
Le fichier $HOME/.ssh/config
permet de s’affranchir du passage de plusieurs paramètres au client SSH. Voici le format utilisé :
On utilisera le client de la manière suivante :
Notes
Les utilisateurs créés avec la commande « useradd » doivent avoir un mot de passe valide, dans le cas contraire, les utilisateurs seront bloqués et ne pourront pas se connecter. On peut vérifier la présence d’un mot de passe dans le fichier « /etc/shadow » : celui-ci contient un « ! » après le nom d’un utilisateur bloqué.
Voir aussi : https://wiki.debian.org/fr/SSH.