Yann "Bug" Dubois

Développeur WordPress freelance à Paris
Flux RSS

GNU/Linux / Ubuntu / Debian : automatiser les connexions avec une clé SSH

25 August 2010 Par : Yann Dubois Catégorie : Français, tech

Une particularité des systèmes UNIX supportant les connexions ssh sécurisées est la possibilité d’utiliser une paire de clés cryptées pour ne pas avoir à taper de mot de passe quand on se connecte d’une machine à une autre. Nous expliquons ci-dessous comment automatiser ce type de connexion entre deux machines sous GNU/Linux (par exemple entre un poste de travail local sous Ubuntu et un serveur distant sous Debian du type des hébergement OVH).

Cet article est donc un bon complément de mon autre article sur la configuration de base d’un environnement LAMP sur un serveur Debian du type de ceux que l’on peut se procurer avec un hébergement OVH Kimsufi.

Le principe des clés SSH est-il sécurisé ?

La réponse à cette question préalable dépend de l’environnement : on peut arguer qu’avoir à taper un mot de passe à chaque connexion ssh ou scp est une mesure de sécurité appropriée qui interdit à une personne se rendant maître du poste de travail de l’administrateur de prendre également le contrôle des serveurs.

Mais on peut également considérer que la frappe au clavier des mots de passe pose un problème de sécurité, car il est relativement facile d’intercepter le mot de passe au moment où il est tapé (avec des logiciels espions qui enregistrent chaque touche : keystroke spy, trojans, malwares,… ou encore en dissimulant une caméra ou tout simplement en regardant par-dessus l’épaule de l’opérateur !), ou encore de le capturer en dirigeant l’utilisateur sur un serveur fictif qui enregistrera le mot de passe en simulant l’ouverture de session ssh. (Il arrive plus souvent qu’on le pense qu’après avoir fait une faute de frappe, ou suite à une mauvaise résolution DNS, ont tombe sur “la mauvaise machine”, et alors, sans s’en rendre compte, on tente de se connecter avec son login et mot de passe habituel : or il est extrêment simple pour l’administrateur d’un serveur de journaliser (“loguer”) toutes les tentatives de connexion infructueuses, et donc de récupérer au passage les logins et mots de passe d’une personne tentant de se connecter par erreur sur la mauvaise machine !) (l’utilisation volontaire de cette technique en interposant un serveur pour subtiliser un mot de passe est une attaque du type qu’on appelle en anglais “man in the middle”)

Bref, à condition que le poste de l’administrateur système soit suffisemment sécurisé physiquement, et possède ses propres mécanismes de contrôle d’accès local (qui peuvent être assez poussés aujourd’hui avec des systèmes biométriques tels que scanner d’empreintes digitales disponibles sur du matériel grand public,…) il n’est pas absurde de considérer qu’il vaut mieux ne plus jamais avoir à taper de mots de passe au clavier pour effectuer l’administration à distance des serveurs en ssh. Surtout si l’on administre un grand nombre de serveurs… ce qui évitera une des pires failles de sécurité (pourtant très répandue) qui est de stocker des listes de mots de passe en clair dans des fichiers texte, qu’on est ensuite très tenté de transférer par des moyens non sécurisés tels que l’e-mail ou les messageries instantanées !

Le dossier caché .ssh

Que ce soit sous Debian, ou sous Ubuntu, ou sous la plupart des autres distributions GNU/Linux / Unix supportant le mécanisme de connexion sécurisée par clés publiques/privées openssh, votre “trousseau” de clés SSH se trouve stocké dans de simple fichiers textes dissimulés dans un répertoire “caché” nommé .ssh et situé à la racine de votre répertoire “de base” (celui dans lequel vous arrivez après vous être connecté ou après avoir ouvert un terminal en local, en général situé dans “/home/<login>” au sein de l’arborescence du système de fichiers.

Faites l’expérience : ouvrez un terminal en ligne de commande, puis tapez :

cd .ssh
ls

…vous allez alors voir la liste de ces fichiers de gestion de clés. On trouve en général cinq types de fichiers distingués par leur nom qui est toujours du même type quelque soit le système :

  • known_hosts : contient la liste des adresses et des clés publiques des serveurs considérés comme “connus”, c’est-à-dire vers lesquels vous autorisez des connexions en ssh avec échange de clés ou de mot de passe crypté.
  • authorized_keys : contient les trousseaux de clés autorisés (et donc ne nécessitant pas d’entrer un mot de passe pour établir la connexion)
  • authorized_keys2 : (obsolète) contient les trousseaux de clés autorisés pour les sessions en ssh2 (les versions récentes d’openssh ne distinguent plus les deux types de fichier et donc tout peut être stocké dans le seul fichier authorized_keys).
  • id_rsa ou id_rsa.key ou autre fichier .key ou private : votre clé privée (utilisant le cryptage RSA).
  • id_rsa.pub ou autre fichier .pub ou public : votre clé privée (utilisant le cryptage RSA).

Comment générer votre clé SSH

Avant de pouvoir vous connecter à des systèmes distants par clé SSH et donc sans avoir à taper de mot de passe, vous devez vous créer un trousseau personnel de clé publique / clé privée associé à votre login sur la machine locale.

Pour cela, taper la commande suivante en ligne de commande dans un terminal local :

ssh-keygen

Vous obtiendrez le message suivant : “Generating public/private rsa key pair.

Puis l’utilitaire vous demandera où stocker la paire de clés générée. Il faut en général accepter l’emplacement proposé par défaut, qui n’est autre que le répertoire “caché” .ssh décrit ci-dessus : “Enter file in which to save the key (/home/<login>/.ssh/id_rsa):“. Appuyez simplement sur “entrée” pour accepter.

Enfin, l’utilitaire de génération de clé vous demandera un mot de passe optionnel. Comme expliqué ci-dessus, si votre poste local est suffisemment sécurisé par ailleurs au niveau de l’accès à votre session, il est inutile de verrouiller votre trousseau avec un mot de passe supplémentaire (ce qui vous permettra désormais de vous connecter en un clic avec vos clés ssh). En cas de doute, il vaut mieux néanmoins sécuriser votre “signature” RSA, s’il y a un risque qu’elle soit utilisée à votre insu, pour se connecter à des ressources distantes, ou pour crypter ou signer d’autres types de communications à votre place. Dans ce cas, ce mot de passe vous sera demandé à chaque tentative d’utilisation de la clé. Ce mot de passe servant à “déverrouiller” le trousseau, et n’étant jamais transmis sur le réseau, c’est bien plus sécurisé qu’avoir à indiquer un mot de passe au système distant.

Enter passphrase (empty for no passphrase):
Enter same passphrase again:

Si vous ne désirez pas sécuriser votre clé privée, appuyez simplement deux fois sur la touche “entrée” pour terminer le processus de création des clés.

Your identification has been saved in /home/<login>/.ssh/id_rsa.
Your public key has been saved in /home/<loigin>/.ssh/id_rsa.pub.

…deux nouveaux fichiers ont été créés dans votre répertoire .ssh, contenant respectivement votre clé privée (qui ne doit pas quitter votre machine), et votre clé publique (que vous allez pouvoir utiliser pour vous identifier sur des machines distantes, comme expliqué ci-dessous).

Comment échanger les clés ssh entre deux systèmes GNU/Linux

Le système est simplissime et passe par la copie d’une séquence de caractères ASCII d’une machine à l’autre, que l’on copiera dans un petit fichier texte “caché” dans le répertoire .ssh, et le tour est joué. Lors d’une connexion ssh, le système tentera automatiquement l’authentification par clé avec les “trousseaux” disponibles, avant de demander le mot de passe “manuellement” si aucune clé ne convient (c’est du moins la configuration par défaut des serveurs et clients ssh2 tels qu’on les trouve installés par défaut dans toutes les distributions courantes de GNU/Linux, BSD et autres parfums d’Unix suportant openssh ou compatible.)

Voici comment procéder concrètement pas-à-pas :

  1. Se connecter depuis son poste de travail (local) en ssh sur la machine distante (serveur) vers laquelle on souhaite automatiser l’ouverture de session ssh. En ligne de commande, taper :
    ssh -l <login> -p <port ssh (22 par défaut)> <adresse du serveur>

    …Le serveur va demander le mot de passe puis ouvrir la session qui ressemble en tout point à une ligne de commande normale telle qu’on la trouve dans un terminal local ou encore dans le bon vieux Telnet (non sécurisé, et donc devenu obsolète depuis l’avènement généralisé de SSH).

  2. Ouvrir un autre terminal en local, et copier votre clé SSH publique, par exemple comme suit :
    cat ~/.ssh/id_rsa.pub

    …ceci va afficher à l’écran la chaîne de caractères ASCII constituant votre clé publique, qui ressemble à cela :

    ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA/3geS0SPAf3q2DL1ZUHL46cpDQYAlVLTHjty7QKR+Pn4
    c/qPYr247n9/jtzxZKQPnV1RTrh9rsg9LqsCAEVghbU4q7qHRSK+yf7ayWYUkB+Yg1Md+0aD8QZ87849
    YoRPoaNzJLv+KkTfY0+d1JFnGPieD+HOOBHmOqKyWB0g7Gms0kmFH2VOydPxXxW7nWEbO25Gsv/oN8fo
    HfYJJU1iT/doteVsklAAUV8u1cn3BjJbWTfZBLvLvMS2vlMVlaKUrTy2WpnQpD4ws/swpAdtU0pkViVW
    4qRabXCVBkVNxTIENnldPd4Af4nEyTKCzoyfmOq1Ct9Vhdd5GF2VSZA4rw== <login>@<machine>

    (chaque clé est complètement différente, celle-ci étant la mienne, vous ne pourrez rien en faire, si ce n’est m’autoriser à accéder à vos ressources !)

    Puis sous Ubuntu copiez l’ensemble du bloc de texte en le sélectionnant à la souris puis en faisant Ctrl+Maj+C (sur Debian ou autre, il suffit de sélectionner à la souris)

  3. Collez cette clé publique dans le fichier authorized_keys de votre répertoire sur le serveur distant :
    vi ~/.ssh/authorized_keys

    (Selon les cas, ce fichier existe déjà et contiendra peut-être déjà des clés, ou vous le créerez. S’il y a déjà des clés, vous introduirez un saut de ligne avant d’ajouter la vôtre.) Pour copier, passez vi en mode insertion en faisant “Echap” puis “i” et faites un clic droit, ou encore Ctrl+Maj+V sous Ubuntu. Enregistrez les changements avec “Echap” puis “: x” puis “Entrée“.

  4. C’est tout, votre clé publique a été enregistrée pour accéder à votre compte sur le serveur distant en ssh. Vous pouvez maintenant tester la connexion automatique avec la clé !

Tester la connexion automatique avec clé SSH

Une fois l’échange de clés effectué comme indiqué ci-dessus, connectez-vous simplement en ssh à votre serveur distant, en précisant votre login mais pas votre mot de passe :

ssh -l <login> -p <port ssh (22 par défaut)> <adresse du serveur>

…Si tout a bien fonctionné, vous vous retrouvez connecté instantanément sans avoir à préciser de mot de passe ! (Si vous avez verrouillé votre clé privée avec un mot de passe, il vous faudra préalablement taper celui-ci pour établir la connexion; mais comme expliqué ci-dessus, ce mot de passe n’est plus transmis à travers le réseau.) La connexion s’établit via un échange crypté entre les deux machines, qui utilisent votre clé publique pour vérifier la validité de votre clé privée (sans la transmettre) et ainsi identifier votre session.

Si c’est votre première connexion ssh à cette machine, vous devrez préalablement confirmer que vous acceptez cet hôte comme “connu” (ceci l’ajoutera automatiquement dans le fichier known_hosts déjà évoqué ci-dessus).

Attention aux droits !

Un point important à vérifier pour que tout fonctionne, est que le répertoire “caché” .ssh et tout son contenu doivent “appartenir” à l’utilisateur concerné et n’être accessible que par lui. Il faudra donc utiliser la commande ls -al pour vérifier les droits sur le répertoire et les fichiers, et utiliser des commandes chown et chmod pour rétablir les bons droits si ce n’est pas le cas. On comprend aisément pourquoi il est indispensable que les fichiers de clé et d’autorisation ne soient accessibles que par les processus appartenant à l’utilisateur qui doit autoriser ou être identifié… c’est une mesure de sécurité élémentaire.

En cas de dysfonctionnement, si le serveur ssh continue à vous demander un mot de passe à chaque connexion, vérifiez donc bien les permissions sur le répertoire .ssh et les fichiers qu’il contient, dans le répertoire /home de votre utilisateur sur le système distant.

Comment installer openssh sous Ubuntu ou Debian ?

Si d’aventure le paquet ssh n’est pas installé par défaut dans votre distribution, vous pouvez facilement l’installer comme suit :

  • Sous Debian (stable), sur le serveur et sur le client :
    sudo apt-get install ssh
  • Sur votre serveur Ubuntu ou Debian unstable :
    sudo apt-get install openssh-server
  • Sur votre poste local Ubuntu ou Debian unstable :
    sudo apt-get install openssh-client

…pour compléter l’installation du client, n’oubliez pas de générer votre clé avec ssh-keygen comme expliqué ci-dessus.

Ressources complémentaires :

A lire également...

{"code":"internal_server_error","message":"

There has been a critical error on your website.<\/p>

Learn more about debugging in WordPress.<\/a><\/p>","data":{"status":500},"additional_errors":[]}