WikiMiNET

La documentation technique et administrative

Outils pour utilisateurs

Outils du site


wiki:guide_du_debutant:cle_ssh

Clés SSH

Quand tu commenceras à avoir des accès à MiNET et à travailler sur le cluster de dev il te faudra des accès à ce dernier. MiNET utilisant un VLAN d'administration privé, la création de clefs SSH ou VPN est alors indispensable. Pourquoi donc ? Let me explain (quickly).

Short Story

Tout d'abord, installez openssh :

apt-get install openssh-client

Ensuite générez la clé :

ssh-keygen -t rsa -b 4096

Vous devez impérativement renseigner une passphrase, sinon il suffit d'un live CD pour voler vos clef.

Vous avez maintenant un dossier .ssh dans votre home qui contient la clé privée (à ne divulguer sous aucun prétexte), ainsi que la clé publique à mettre sur les serveurs où vous voulez vous connecter.

Copiez ensuite le contenu de votre clé public sur le serveur en faisant

ssh-copy-id -i ~/.ssh/id_dsa.pub user@machine

(ou manuellement en copiant la clé publique dans le fichier .ssh/authorized_keys de votre home.)

Pour modifier sa passphrase :

ssh-keygen -p -f CHEMIN_DU_FICHIER

Voilà c'est fait, vous pouvez maintenant accéder au VLAN d'administration de MiNET !

Long Story

Pourquoi des clés SSH ?

Quelques définitions : on parle généralement de paire de clé en cryptographie asymétrique. On introduit la notion de clé privé et de clé publique. Concrètement, une clé est un fichier texte qui contient une succession de caractères. Brièvement, elles permettent de : 1)

  • chiffrer un message que l'on souhaite transmettre à quelqu'un : la clé publique va permettre d'encoder notre message, la clé privé va permettre de déchiffrer le message.
  • signer un message (c'est à dire, prouver notre identité (c'est MOI et pas un autre)) : la clé privé va permettre de coder un message, la clé publique va permettre de déchiffrer le message.

On remarquera bien que dans le premier cas, on souhaite que le destinateur soit le seul capable de déchiffrer le message de l'expéditeur, tandis que dans le deuxième cas, on souhaite que l'expéditeur soit le seul capable de chiffrer son message (authenticité).

Pour pouvoir s'authentifier via SSH sur une machine distante, il existe deux possibilités : en utilisant un mot de passe ou une identification par clés. Pourquoi utiliser des clés ? Il existe plusieurs raisons, mais une des plus importantes est de considérer un utilisateur plus “faillible” qu'un algorithme : l'utilisateur va créer un mot de passe influencé par ses goûts, ses idées etc. tandis qu'un algorithme va générer une clé aléatoirement (ou pseudo-aléatoirement).

Création de clés SSH

Pour générer notre paire de clé, on utilise la commande suivante :

ssh-keygen -t ALGO -b NB_BITS

où ALGO correspond à l'algorithme utilisé lors de la génération et NB_BITS correspond à la longueur de la clé. Plus c'est long, plus c'est dur… à deviner. ;-)

En ce qui concerne l'algorithme à utiliser, le manuel propose 5 algorithmes, mais on parle particulièrement de RSA (nommé en l'honneur de Ronald Rivest, Adi Shamir et Leonard Adleman) et DSA (Digital Signature Algorithm). Le débat est sans fin pour savoir lequel des deux est le “meilleur” (vous pouvez aller vous perdre dans les fils de discussion sur le net, je ne vous retiens pas…). On retiendra que RSA est le plus répandu…

Par défaut, ssh-keygen génère une clé de 2048 bits avec l'algorithme RSA et DSA de 1024 bits exactement.

Lors de la création de vos clés, il vous demandera si vous souhaitez mettre une passphrase. Cette étape est très importante, car elle va permettre de protéger votre clé privé, qui deviendra inutilisable sans la passphrase. Sans passphrase, votre clé privé est écrite en clair dans un fichier et il suffit d'un live CD pour récupérer votre clé. Vous voyez le problème, n'est-ce pas ?

Après la génération de vos clés, vous obtenez deux fichiers : un fichier sans extension (qui s'agit de votre clé privé à ne diffuser sous aucun prétexte) et un fichier avec une extension .pub qui constitue votre clé publique.

Vous devez déposer la clé publique sur le serveur distant auquel vous souhaitez vous connecter. Pour cela, deux options :

  1. ssh-copy-id -i ~/.ssh/id_dsa.pub user@machine
  2. copie manuelle dans le fichier .ssh/authorized_keys de votre home.

Par ailleurs, vous avez récupérer un output similaire à celui-ci :

Generating public/private rsa key pair.
The key fingerprint is:
05:1e:1e:c1:ac:b9:d1:1c:6a:60:ce:0f:77:6c:78:47 kikoolol@minet.net
The key's randomart image is:
+--[ RSA 2048]----+
|       o=.       |
|    o  o++E      |
|   + . Ooo.      |
|    + O B..      |
|     = *S.       |
|      o          |
|                 |
|                 |
|                 |
+-----------------+
  • La fingerprint correspond à l'identifiant unique du fichier qui stock la clé. Elle est obtenue en hachant en md5 la clé publique, clé publique elle-même en base64 (voir sur Google ce que veut dire hachage et algorithme de hachage). (ssh-keygen spécifie qu'il utilise par défaut2) sha256 pour afficher l'empreinte, notamment lorsqu'on effectue une première connexion sur un serveur. CEPENDANT, il s'agit ici de l'empreinte en md5.). Pour vérifier, faites un :
 cat MA_SUPER_CLE | base64 -D | md5 
  • Le randomart est utilisé à des fins de comparaison graphique entre la clé privé et la clé publique associée, ce qui permet une invalidation visuelle plus rapide en cas de différence. La commande pour voir le randomart d'une clé déjà existante est la suivante :
ssh-keygen -lv -f MA_CLE 

En naviguant sur le Web, j'ai vu un mec qui a fait un script sympa pour avoir un visuel des empreintes en md5 et sha256, voilà le lien du fil de discussion.

Enfin, une option bien pratique pour pouvoir modifier la passphrase de la clé privé, notamment lorsqu'on a mis une passphrase moisie (ou aucune passphrase, c'est encore pire!) sur sa clé privé 3):

ssh-keygen -p -f CHEMIN_DU_FICHIER
wiki/guide_du_debutant/cle_ssh.txt · Dernière modification: 2020/06/27 18:16 (modification externe)