Clés SSH et transferts SCP sans mot de passe

Salut à tous, aujourd’hui un rapide tuto pour sécuriser et automatiser des transferts SCP sans mot de passe entre 2 machines linux. Pour ça on va utiliser des clés SSH, d’un point de vue crypto, il s’agit simplement d’un système classique clé publique/privée où vous installer votre clé publique sur un serveur puis vous utilisez la clé privée associée pour prouver votre identité auprès de ce serveur. A noter qu’un problème de ce système pour SSH c’est qu’il ne supporte pas nativement les certificats X509 et que par défaut il faut utiliser un format SSH « maison ». Il existe néanmoins des builds de openSSH supportant les certificats numérique standard comme PKIX-SSH.

Et sans transition la procédure pour mettre ça en place avec des clés SSH classiques.

Génération de clés SSH

Sur le serveur qui devra exécuter SCP et établir la connexion TCP :

apt-get install openssh-client

Puis générer une bi-clé RSA pour SSH :

ssh-keygen -t rsa -b 2048

Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa): /home/user/.ssh/script1_rsa
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/script1_rsa
Your public key has been saved in /home/user/.ssh/script1_rsa.pub
The key fingerprint is:
ca:5b:25:78:21:62:d6:c8:0d:20:fe:c9:1e:c7:66:73 user@server

Installation de la clé publique sur le serveur distant

On copie l’ID sur le serveur distant à l’aide de l’utilitaire prévu a cette effet ssh-copy-id :

ssh-copy-id -i ~/.ssh/script1_rsa.pub user@targetserver.domain.fr

The authenticity of host 'user@targetserver.domain.fr (192.168.0.66)' can't be established.
ECDSA key fingerprint is 12:23:56:78:90:ab:cd:ef:00:00:00:00:00:00:00:ff.
Are you sure you want to continue connecting (yes/no)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
user@targetserver.domain.fr's password:

Number of key(s) added: 1

Now try logging into the machine, with: "ssh 'user@targetserver.domain.fr'"
and check to make sure that only the key(s) you wanted were added.

Et si on essaye de suite, ça marche pas.. En fait il manque 2 étapes sur le serveur source, il faut configurer ssh pour qu’il prenne en compte cette nouvelle clé par défaut pour cette hôte. Pour cela :

vim ~/.ssh/config

Puis ajouter dans le fichier :

Host targetserver.domain.fr
   IdentityFile ~/.ssh/script1_rsa # clé privé

Enfin, ces clés RSA sont des éléments sensibles de votre infra car elles permettent de rebondir sur les serveurs qui les acceptent de façon transparente. Et à un attaquant de pourrir tout votre SI si elles sont mal protégées… C’est pour cela que la plupart des distributions linux récente refusent d’utiliser ces clé tant que les droits systèmes ne sont pas configurés correctement sur les fichiers de clés ! C’est à dire, en tant que l’utilisateur qui détient les clés, appliqué les ACL suivantes :

chmod 400 ~/.ssh/script1_rs
chmod 400 ~/.ssh/script1_rsa.pub 
chmod 644 ~/.ssh/config

Et à partir de là on peut faire :

ssh 'user@targetserver.domain.fr'
Last login: Tue Sep 20 09:37:25 2016 from server.domain.fr
Kickstarted on 2016-09-03
-bash-4.2$

Et voilà !

Transferts SCP sans mot de passe

SCP utilisant la connexion et la configuration de SSH, il va prendre en compte automatiquement les clés SSH qu’on a mis en place. Ci dessous un exemple pour pousser des fichiers vers notre serveur distant :

scp Chemin/vers/fichier_à_transférer.ext user@targetserver.domain.fr:/dossier/de/destination/

Notez que ça marche aussi dans l’autre sens tant que c’est le même serveur source qui établi la connexion. Vous pouvez télécharger des fichiers vers votre serveur source :

scp user@targetserver.domain.fr:Chemin/vers/fichier_à_récupérer.ext /dossier/de/destination/local

et à partir de maintenant : RTFM si vous voulez plus de détails

Gérer ses Clés SSH avec Putty

Vous pouvez également  utiliser les clés SSH depuis PuTTY sous Windows : Pour cela, utiliser PuTTYGen livré avec le logiciel. Après avoir cliquer su « Generate », il faut bouger la souris dans l’encart « key »pour générer de l’aléatoire (on se sent un peu con en faisant ça d’ailleurs). A partir de la, sauver vos clés dans des fichiers en ajoutant une passphrase et éventuellement un commentaire associé.

Pensez bien à copier-coller dans un fichier le bloc pour OpenSSH en haut de la fenêtre, car PuTTY ne sauvegarde pas la clé publique dans ce format.

Pour mettre en place la clé, rendez vous sur le ou les serveur ou vous comptez vous connecter avec PuTTY et saisir les commandes suivantes avec le compte qui sera associé à cette clé publique :

mkdir ~/.ssh
chmod 0700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 0644 ~/.ssh/authorized_keys
# et dans vim
vim ~/.ssh/authorized_keys

et copier le contenu de votre clé pour open ssh tel qu’afficher dans l’interface au dessus dans ce fichier authorized_keys.

Pour finir, il suffit de configurer votre clé privé dans PuTTY->Options->Connection->SSH->Auth et sélectionner le fichier .ppk généré juste avant, de retour dans session, configurer une connexion incluant le nom de l’utilisateur user@targetserver.domain.fr et  et sauvegardez-là. Les connexions vers ce serveur seront désormais sans mot de passe à saisir.

Désactiver l’authentification par mot de passe pour SSH

Le plus paranoïaques d’entre nous pourrons carrément désactiver l’authentification par mot de passe. pour cela rendez vous dans le fichier /etc/ssh/sshd_config et ajouter/modifier les lignes suivantes :

[...]
PasswordAuthentication no
[...]
UsePAM no
[...]

Puis :

service reload ssh

Mais alors il ne faut pas perdre votre clé maintenant… faite des backups…

Conclusion

Voilà, cette technique est assez pratique pour les scripts automatisés qui doivent effectuer des tansferts SCP sans mot de passe entre des serveurs et quand vous ne voulez pas claquer un mot de passe en clair dans votre programme. Après d’un point de vu sécu si votre serveur possédant la clé privée se fait trouer : tous les serveurs auxquels il peut se connecter seront à coup sûr compromis. Il peut donc être souhaitable d’utiliser des comptes Linux  chrooté dans SSH et dédiés à cette utilisation pour rajouter une barrière en cas de compromission.

Enfin je vous invite a regarder du côté de ssh-agent si vous voulez encore monter d’un cran la sécurité et rajouter une passphrase sur la clé privée SSH.

That’s all folks…