Parmi les bonnes pratiques permettant de se prémunir des attaques extérieures, notamment celles de botnets qui tentent en boucle de se connecter à vous, se trouve désactiver le login par nom d’utilisateur et mot de passe, pour seulement autoriser le login par clé SSH.
Nous allons mettre cela en place sur un Raspberry Pi, mais ça fonctionnera de la même façon sur un PC Linux classique.
C’est certes lourdingue, mais bien plus sécurisé que le login/password classique. En avant.
Note : il existe plusieurs manières de générer la paire de clés. La méthode que j’utilise génère la clé depuis le serveur, puis nécessite le transfert de la clé privée vers le PC. La méthode la plus répandue est d’utiliser la génération de clé depuis votre client, puis de propager la clé publique vers le serveur. Ayant eu quelques soucis notamment à cause du formalisme de PuTTYGen, j’ai opté pour le transfert de la clé privée. Comme ça vous savez!
1- Générer la clé
Connectez-vous sur votre Pi en SSH classiquement, puis générez votre paire de clés (une publique et une privée) :
cd ~
mkdir ~/.ssh && chmod 700 ~/.ssh -R
ssh-keygen -f ./my-key -t ecdsa -b 521
Il est demandé une passphrase : c’est le mot de passe pour ouvrir la clé privée (celle avec laquelle vous vous authentifierez pour vous connecter au serveur) : même si le mot de passe est facultatif, je vous recommande chaudement d’en indiquer un.
Ceci fait, nous avons donc deux fichiers qui ont été créés : /home/utilisateur/my-key et /home/utilisateur/my-key.pub.
Nous allons maintenant faire en sorte que la clé publique (my-key.pub) soit reconnue par notre Raspberry Pi.
Ceci se passe via le fichier /home/utilisateur/.ssh/authorized_keys, que nous allons créer à partir de notre clé publique avec les bonnes autorisations.
cp ~/my-key.pub ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys2- Activer l’authentification par clé
Maintenant, nous allons autoriser la connexion via paire de clés.
sudo nano /etc/ssh/sshd_configPuis cherchez la ligne AllowUsers, à laquelle vous ajoutez après un espace votre nom d’utilisateur courant. Normalement, vous ne devriez avoir qu’un seul nom : le vôtre.
AllowUsers Utilisateur4 lignes plus bas, vous devriez pouvoir trouver :
PubkeyAuthentication yesAssurez-vous du yes!
Ceci fait :
sudo service ssh restart3- Exporter la clé privée
Maintenant, copiez votre clé my-key (et pas my-key.pub, sauf pour votre sauvegarde) via WinSCP ou n’importe quelle commande permettant de transférer des fichiers depuis votre Pi vers votre PC.
4- Se connecter via Windows (avec PuTTY)
Commençons par télécharger PuTTY ainsi que PuTTYGen; le premier nous servira à la connexion et le second à procéder à une adaptation de notre clé privée.
Lançons d’ailleurs PuTTYGen et cliquez sur Conversions (menu en haut) puis Import key… et sélectionnez my-key.
Puis, cliquez sur le bouton Save private key
Lançons d’ailleurs PuTTYGen et cliquez sur Conversions (menu en haut) puis Import key… et sélectionnez my-key.
Puis, cliquez sur le bouton Save private key :
Si vous n’avez pas mis de mot de passe pour votre clé privée (la passphrase), PuTTYGen vous le fera remarquer (et vous pourrez en rajouter un avec les champs au-dessus).
Notez que votre nouvelle clé s’appelle maintenant my-key.ppk.
Ouvrez maintenant PuTTY.
Selon les versions, la clé en .ppk est à indiquer soit dans Connection > SSH > Auth directement, soit Connection > SSH > Auth > Credentials.
Il vous suffit ensuite de renseigner le chemin via le bouton Browse… vers votre clé privée.
Vous pouvez maintenant tester votre login comme d’habitude (même nom d’utilisateur) via PuTTY, et vous devriez maintenant avoir l’indication que l’authentification passe par votre clé, et non plus par la paire classique login/mot de passe :
5- Le mot de la fin
Globalement, il s’agira peu importe le logiciel que vous utilisez pour vous connecter à votre serveur de lui fournir la clé privée dans les réglages de site.
Parfois, la clé PPK sera trop récente, il faudra donc bien conserver la clé my-key originale… Des fois que !
6- Conseil de pro (ou pas)
J’ai eu beaucoup (BEAUCOUP) d’attaques de bots via SSH. Genre, /var/log/auth.log était absolument boursouflé de plus de 1000 tentatives par jour… C’est une chose courante et, si votre paire classique login/mot de passe est assez costaude, vous ne risquez pas grand-chose.
Cependant, j’ai lu et appliqué qu’il était chaudement recommandé de :
- désactiver le login en root à distance : dans /etc/ssh/sshd_config :
PermitRootLogin no - désactiver l’identification par login et mot de passe, ainsi que les mots de passe vides (ça inhibe un peu le spam des bots) :
PasswordAuthentication no
PermitEmptyPasswords no
Evidemment, cela présuppose que tout fonctionne comme il se doit avec la clé SSH…