SSH Clé Privée

Cet article est un brouillon, mais comme je ne suis pas sûr de le parfaire un jour je préfère déjà le publier.

Présentation

Avec SSH nous pouvons contrôler un serveur à distance ou échanger des fichiers (sftp).
Traditionnellement la connexion à un serveur est sécurisée par un nom d’utilisateur et un mot de passe. Le défaut de cette méthode c’est qu’il faut être sûr que le mot de passe ne pourra pas être deviné, ou pire : récupéré du post it collé sur l’écran d’un utilisateur…

Une connexion plus sécurisée consiste à se connecter avec un système de clés asymétriques. Je ne vais pas entrer des les détails alors nous garderons à l’esprit 2 choses :

  • la personne voulant communiquer possède une clé privée (un fichier) qu’elle va garder très précieusement sans que personne ne puisse mettre la main dessus, elle va par contre diffuser sans retenu la clé publique correspondante.
  • tout message codé avec la clé privée ne peut être décodé qu’avec la clé publique, et inversement. Les conséquences en sont multiples dont la plus importante dans notre cas : toute personne possédant la clé publique pourra être sure que le message crypté (une simple signature en bas d’un message par exemple) provient bien du possesseur de la clé privée. Tout cela est possible grâce à des concepts mathématiques concernant les nombres premiers…

En pratique, sur notre serveur nous allons donc associer une clé publique à un utilisateur. L’utilisateur ne pourra se connecter que s’il possède la clé privée correspondante, qui est elle-même le plus souvent protégée par une phrase de passe.

  • Première conséquence de cette méthode : finie l’époque où on avait un mot de passe par accès, à présent on ne possède qu’une seule clé pour tous les accès sans jamais avoir à communiquer de mot de passe à l’administrateur des serveurs. Fournir le fichier de clé publique suffit pour qu’on nous ouvre un accès qui ne fonctionnera que pour le possesseur de la clé privée.
  • Deuxième conséquence : les logiciels de ftp ou ssh n’enregistrent plus vos mots de passes.
  • conséquence de ces 2 conséquences : on peut utiliser des outils comme Pageant de PuTTY ou ssh-add (linux ou Mac OS) pour mettre en mémoire cette clé pour 3h par exemple et initier des connexions ssh ou sftp (via filezilla ou autre) vers une multitude de serveurs sans avoir à saisir la moindre authentification (fini les saisies sans fin du même mot de passe !) et pourtant cela reste sécurisé, et certainement plus qu’avec un mot de passe stocké et communiqué de multiples fois.

Pour réussir une intrusion après ça, le hacker devrait obtenir le fichier de clé privée et la phrase de passe de cette clé. Et cette clé privée n’a jamais besoin de circuler, contrairement aux mots de passes ancestraux, ce qui rend son interception plus difficile.

Mise en place

Concrètement créons nos clés :

  • Sous Windows, en utilisant les outils de PuTTy (http://www.putty.org/) on peut créer une clé avec PuTTYgen. On obtiendra alors un fichier ppk .
    Je vous conseille de télécharger le pack d’installation entier : http://the.earth.li/~sgtatham/putty/latest/x86/putty-0.60-installer.exe, du coup les clés seront associées au gestionnaire Pageant, il suffira donc de double cliquer sur notre clé privée pour la mettre en mémoire jusqu’à ce qu’on ferme Pageant.
    Après l’installation on lance PuTTyGen, on clique sur “Generate”
    Création Clé SSH PuTTyGen
    Là on bouge la souris dans la partie vide de la fenêtre, ce déplacement aléatoire génère le jeu tout aussi aléatoire de clés. Une fois la clé générée, indiquez le commentaire (une email a le mérite d’être unique) et choisissez votre phrase de passe qui se doit d’être bien longue et compliquée car on ne la tapera qu’une fois par jour normalement :
    Crétion Clé SSH PuTTyGen
    Pour sauver le résultat, cliquez sur Save Private Key (on garde le fichier .ppk généré très précieusement et personne ne doit pouvoir y accéder à part vous). Puis cliquez sur Save Public Key, c’est la clé publique que vous devrez fournir à l’adminstrateur du serveur SSH afin qu’il associe votre clé à votre compte.
  • Sous linux avec la commande ssh-keygen
    chris@server:~$ ssh-keygen
    Generating public/private rsa key pair.
    Enter file in which to save the key (/home/chris/.ssh/id_rsa):
    Enter passphrase (empty for no passphrase): choisir la phrase de passe ici
    Enter same passphrase again: ne rien mettre si la clé est destinée à rsync via ssh
    Your identification has been saved in /home/chris/.ssh/id_rsa.
    Your public key has been saved in /home/chris/.ssh/id_rsa.pub.
    The key fingerprint is:
    16:0f:ef:d9:e3:df:7d:87:ec:65:71:dc:fb:15:9c:1f chris@server.company.com

    J’ai alors ma clé privée dans /home/chris/.ssh/id_rsa que je ne dois jamais communiquer.
    J’ai ma clé publique dans /home/chris/.ssh/id_rsa.pub

  • Une clé générée avec Linux n’est pas au même format qu’une clé créée avec PuTTy. Si on utilise parfois linux et parfois Windows, il est plus sûr de créer sa clé avec linux puis de la passer dans PuTTy qui est capable de la convertir à son format comme indiqué dans l’image ci-dessous obtenir avec l’outil PuTTyGen :
    Importer Clé SSH dans PuTTyGen

Une fois qu’on a générée ces clés asymétriques on garde très précieusement la clé privée (/home/chris/.ssh/id_rsa) et on place la clé publique (/home/chris/.ssh/id_rsa.pub) sur les serveurs ssh où l’on souhaite accéder.

Afin que notre clé soit acceptée par un serveur pour le compte USER1 il faut ajouter la clé publique au fichier /home/USER1/.ssh/authorized_keys (accessible en lecture par tout le monde), et créer ce fichier s’il n’existe pas encore. On peut autoriser plusieurs clés, une ligne par clé :

chris@server:~$ cat /home/USER1/.ssh/authorized_keys
ssh-dss AAAAB3NlHS9FTiqhF54K9[...]qCPVQolzHqqJsozzwe/Uw== chris@gonzofamily.com
ssh-dss AAAAB3NzaC1kc3MAAAC[...]FoSVAVddhXsjDy42HXEowI chris@putty

Utilisation

  • Sous Windows, on double clique sur notre fichier .PPK, Pageant se lance et demande le mot de passe. Par la suite si PuTTy est bien configuré il n’y aura plus d’authentification demandée. Pour bien configurer putty :
    • dans Connection > DATA on indique l’AUTO USERNAME
    • dans Connection > SSH > Auth on indique le chemin vers Private Key (notre fichier PPK

    Idem pour Filezilla, où je n’indique aucun mot de passe, je choisi à la place le type d’authentification “Interactif” mais j’indique quand même mon login, sur les vieilles version de Filezilla j’indiquais volontairement un mauvais mot de passe puisque c’était obligatoire.

  • Sous Linux ou Mac OS X, il faut que le fichier de clé privée soit dans le dossier .ssh du dossier utilisateur (exemple /Users/chris/.ssh/id_dsa) on tape alors ssh-add -t 10600 pour charger la clé 3h en mémoire (10600 secondes). Sur un linux de base il faut avoir exécuté ssh-agent avant que ssh-add fonctionne, cela a été ajouté par défaut dans gnome et dans Mac OS X. Voici ce que vous pouvez ajouter dans votre bash_profile sous linux si ssh-add ne fonctionne pas de suite, il y a d’autres possibilités à découvrir avec google (je n’ai pas testé celle là) :
    SSHAGENT=/usr/bin/ssh-agent
    SSHAGENTARGS="-s"
    if [ -z "$SSH_AUTH_SOCK" -a -x "$SSHAGENT" ]; then
      eval `$SSHAGENT $SSHAGENTARGS`
      trap "kill $SSH_AGENT_PID" 0
    fi

    Voila, à présent SSH, Filezilla et mes scripts rsync fonctionnent directement sans demande de mot de passe pendant 3h.

One thought on “SSH Clé Privée”

Leave a Reply

Your email address will not be published. Required fields are marked *