====== 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 : ((https://fr.wikipedia.org/wiki/Cryptographie_asym%C3%A9trique))
* __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 :
- ''ssh-copy-id -i ~/.ssh/id_dsa.pub user@machine''
- 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éfaut((https://linux.die.net/man/1/ssh-keygen)) 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 [[https://superuser.com/questions/929566/sha256-ssh-fingerprint-given-by-the-client-but-only-md5-fingerprint-known-for-se|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é ((RTFM)):
ssh-keygen -p -f CHEMIN_DU_FICHIER