Utiliser SCP dans vos scripts.

Bonjour à tous !

Aujourd’hui un petit tuto système !
J’ai été confronté à un problème lorsque j’ai voulu transférer un fichier via SCP dans un de mes scripts. En effet, la commande SCP ne permet pas nativement de renseigner le mot de passe de la machine distante directement dans la commande. Il faut obligatoirement attendre le prompt qui permet de renseigner le mot de passe mais nous allons voir qu’il existe un moyen de contourner le problème.

Pour rappel, SCP est une commande qui permet de copier des fichiers/dossiers d’une machine à une autre via le protocole SSH. Elle s’utilise comme ça :


# scp <fichier_local_a_transferer> <user_distant>@<machine_distante>:<path_distant>

Vous voyez bien que le mot de passe de l’utilisateur distant (« arnaud » ici) m’est demandé pour monter la session SSH. C’est le mode d’authentification par défaut mais il est possible de changer cette méthode d’authentification et de passer via un système de clés asymétriques. On peut techniquement ajouter un mot de passe classique à ces clés ou s’en affranchir complètement, et c’est le cas qui nous intéresse ici. Voyons un peu !

Le principe.

Mettons de suite les pendules à l’heure ! ON NE CRYPTE PAS !! Vous oubliez tout de suite !

On dit « chiffrer« .

Vous vous le faite tatouer sur l’avant-bras, vous le taguez dans votre salon, peu importe, mais pas pitié ne me parlez pas de « crypter ». Bref, parenthèse faite, continuons 🙂

Donc le principe repose sur une paire de clé asymétrique :

  • Une clé privée.
  • Une clé publique.

Et bien évidement ce ne sont pas les mêmes (asymétrique), en revanche elles fonctionnent ensemble ! Et ouais c’est ça qui est fort ! Chaque clé permet de déchiffrer ce que l’autre clé a chiffré ! Sans que pour autant l’on puisse déduire une des clés avec l’autre

  • Je chiffre un message avec la clé privée –> Il me faut la clé publique pour déchiffrer.
  • Je chiffre un message avec la clé publique –> Il me faut la clé privée pour déchiffrer.

Petites précisions sur leur utilités :

La clé privée : Comme son nom l’indique elle est privée. Vous ne devez la communiquer à personne. Elle sera utilisée depuis le (ou les) client(s).
La clé publique : Elle sera stockée sur le serveur auquel on souhaite se connecter. Cette clé peut être communiqué à tout le monde qui souhaite vous envoyer des messages chiffrés.

La clé privée doit être connue et conservée uniquement par vous alors que la clé publique peut être communiquer à tout le monde, par exemple d’autres administrateurs de serveur qui souhaitent vous offrir une authentification sécurisée à leur serveur.

Un petit schéma pour aider à la compréhension :

Avant de passer à la configuration, notez qu’il existe plusieurs algorithmes de chiffrement asymétriques dont RSA et DSA sont les plus répandus. On ne s’éternisera pas sur les différences maintenant mais on utilisera RSA pour nos tests !

Configuration.

Alors pour l’exemple on va partir sur :

  • 1 serveur debian nommé « serveur » (prompt en jaune) : 192.168.1.25.
  • 1 client raspberry nommé « raspberrypi » (prompt en vert) : 192.168.1.199.

Un utilisateur « arnaud » a été créé sur le client et le serveur.

Génération des clés.

La paire de clé peut être générée n’importe où. En gardant à l’esprit que nous récupérerons entre autre notre clé privée et qu’on ne doit pas la communiquer (ce qui implique aussi d’éviter un envoi en clair par mail avec la clé privée…). Dans un soucis pratique on va générer la paire de clé sur le client. Etant donné que ça va être notre client qui aura besoin de la clé privée, on aura pas besoin de lui transférer.

La commande : ssh-keygen -t rsa -b 2048

Cette dernière va générer la paire de clé RSA codée sur 2048 bits. RSA est le type de clé le plus souvent utilisé. Concernant la taille de la clé 2048 est plutôt pas mal ! Hormis si vous vous appelez la NSA, on aura du mal à casser votre clé.
Pour info, j’aurais juste pu utiliser la commande ssh-keygen seule car « rsa » et « 2048 » sont des valeurs par défaut.

On vous demandera quand même quelques informations supplémentaires pendant la génération :

  • L’emplacement et le nom de la clé : Bon bah pas compliqué à comprendre, c’est le nom et l’endroit où seront générés vos clés (vous pourrez toujours les déplacer plus tard)
  • La passphrase : Alors oui, la clé suffit à s’authentifier mais vous pouvez décider de quand même rajouter un mot de passe lié à la clé, ainsi si on vous vole votre clé privée, on ne pourra quand même pas l’utiliser sans le mot de passe associé. Par contre n’oublions pas que dans cet article le but du jeu est bien de se passer d’un quelconque mot de passe afin d’utiliser SCP dans nos scripts, donc j’ai laissé l’option vide.

Et voilà vos clés sont générées sur le client :

Vous l’aurez compris mais le fichier avec l’extension .pub correspond à la clé publique, l’autre la privé. Vous pouvez les afficher pour voir à quoi ça ressemble.

PS : Ce n’est pas la peine d’essayer, cette paire de clé ne me sert qu’au tuto… Petit filou va 😉

Bon, maintenant que les clés sont générées, il faut passer à la configuration du serveur. Et oui, pour le moment le serveur SSH est encore configuré par défaut, c’est à dire qu’il autorise les connexions basées sur une authentification classique login/mdp.

Si vous vous souvenez, le serveur doit connaitre la clé publique de l’utilisateur à autoriser, pour cela on copie/colle la clé publique sur le serveur dans l’emplacement par défaut qui est :

~/.ssh/authorized_keys

« ~ » correspond au répertoire home de l’utilisateur à autoriser. Dans mon cas j’aimerais autoriser l’accès pour les utilisateurs « root » et « arnaud », donc je dois copier la clé publique dans les répertoires :

  • /root/.ssh/authorized_keys
  • /home/arnaud/.ssh/authorized_key

Il se peut que l’arborescence du fichier n’existe pas encore, vous pouvez alors la créer :

Je ne vous le montre pas, mais j’ai fais pareil pour l’utilisateur root.

Maintenant nous allons devoir modifier la configuration du serveur SSH afin qu’il accepte les authentifications par clé.
En tant que root, éditez le fichier /etc/ssh/sshd_config et ajoutez les lignes suivantes si elles n’y sont pas :

Vu que je souhaitais également pouvoir me connecter avec l’utilisateur root, il ne faut pas oublier la ligne qui autorise root à se connecter en ssh (mais ça vous n’êtes pas obligés) :

Une fois ajouté, il faut redémarrer le service afin que les options soient prises en compte (/etc/init.d/ssh restart ou service ssh restart) :

Voilà maintenant nous pouvons tester une connexion depuis notre client vers le serveur, en renseignant uniquement le nom d’utilisateur et la clé. Ça doit fonctionner :

Comme à chaque fois quand on se connecte pour la première fois sur un serveur, il nous demande de vérifier l’empreinte (fingerprint). J’ai aveuglement accepté car je me fais confiance…

Mais vous voyez que si je retente une deuxième fois, je suis directement logué sans avoir quoi que ce soit à taper :

A ce stade donc on peut s’authentifier grâce à notre clé privée (pour l’utilisateur root et arnaud) mais l’authentification par couple login/mot de passe fonctionne toujours car on ne l’a pas désactivé. Libre à vous de choisir si vous autorisez les 2 méthodes d’authentifications ou si vous ne voulez autoriser que la connexion par clé, auquel cas il faudra définir l’option « PasswordAuthentication » (dans /etc/ssh/sshd_config) à no et redémarrer le service.

ATTENTION : Pensez à avoir bien valider la connexion par clé avantt de supprimer l’authentification login/mot de passe car si ça ne fonctionne pas, vous ne pourrez plus vous connecter sur votre serveur !!!

Vous voilà avec une authentification SSH par clé en place, ne nécessitant plus de login/mot de passe. Vous pouvez maintenant utiliser SCP dans vos scripts. Un petit exemple :

Petit explications des commandes pour ceux qui auraient du mal :

  • Je cré un fichier « fichierTest« .
  • J’écris « hello » dedans.
  • Je cré un script « script_envoi_fichier.sh » que j’affiche.
    • scp : bah c’est la commande.
    • -i : option pour indiquer ma clé à utiliser.
    • fichierTest : le fichier local à envoyer.
    • root@192.168.1.25:~ : J’utilise l’utilisateur root pour me connecter sur le serveur 192.168.1.25 et je choisis le répertoire home (~) pour stocker le fichier
  • chmod +x : J’ajoute la possibilité d’executer le fichier.
  • J’exécute le script.

On voit que le transfert s’est bien lancé et a réussi. Je me connecte sur le serveur et je vérifie que j’ai bien reçu mon fichier. Certes ce n’est pas vraiment une preuve mais je vous promets que je suis de bonne foi 😉

Voilà vous pouvez maintenant utiliser SCP pour transférer vos fichiers sans avoir besoin de vous authentifier avec un mot de passe 🙂

A retenir :

Un petit recap des choses importantes à retenir !

  • Une paire de clé asymétrique correspond à :
    • Une clé publique.
    • Une clé privée.
  • Chaque clé peut chiffrer et déchiffrer un message reçu par l’autre clé.
  • La clé publique est renseignée sur le serveur, dans le répertoire de l’utilisateur auquel on souhaite un accès (~/.ssh/authorized_keys par défaut).
  • La clé privée peut s’autosuffire en terme d’authentification ou, il est possible d’ajouter une passphrase à la clé.
  • Il ne faut surtout pas communiquer sa clé privée.
  • Il faut configurer le serveur SSH afin qu’il autorise les connexions par clé.
  • Il faut utiliser l’option -i de scp pour définir le fichier de la clé privée.

Have fun 🙂

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *