SSH toi comme un pro !

Lors de ma formation de développeur, on nous avait appris à faire une interface utilisateur, du maquettage, des pages dynamiques avec Javascript, de l’architecture web, du rendu côté serveur avec PHP et de l’enregistrement en base de données avec MySQL. Bref à “coder” comme on dit pour simplifier tout ça.

Le souci, c’est que tout cet apprentissage se faisait en local. Aucun problème, j’utilisais une pile de développement (X/W/L/AMP) et tout fonctionnait parfaitement. Mais tout a basculé lorsque j’ai dû héberger mon travail ailleurs que sur ma propre machine (bon, après tout, c’est le but du métier 😀).

Le stress est monté lorsque j’ai compris que je devais, en plus de coder, commencer à comprendre comment communiquent les ordinateurs entre eux et notamment comment interagir avec une machine distante.

Ce tutoriel permettra de balayer les connexions SSH essentiellement qui sont la base du développement (gestion de serveur, au CI/CD, bref à du devops).

Le SSH (Secure Shell) est un protocole de communication sécurisé entre deux ordinateurs
La machine A demande à la machine B un accès pour y faire des opérations.

Principe du SSH

​C’est un protocole de communication sécurisé à l’aide de deux modes d’authentification :

Par mot de passe (Le serveur demande le mot de passe de l’utilisateur (ici devexploris) et l’utilisateur renseigne le serveur de son mot de passe.
Par clé (L’utilisateur présente de lui-même sa clé de connexion et le serveur procède aux vérifications).
La première authentification fonctionne de la même façon qu’une authentification classique login / mot de passe mais elle possède aussi les mêmes faiblesses => brute force ou social engineering.

Elle possède aussi un problème lié à l’automatisation (notamment pour les cas de CI/CD ou d’opérations autonomes).
La seconde technique permet de s’affranchir de mot de passe et est donc totalement transparente pour l’utilisateur (Et bien pratique pour des opérations autonomes) une fois configurée. Elle est aussi plus sécurisée (selon le type d'algorithme de chiffrement utilisé) et c’est celle-ci que l’on va voir maintenant.

1. Autoriser la connexion par clé

​Si c’est ton serveur à toi (sous entendu, tu es solo dessus), il est fort probable que la connexion par clé soit désactivée lors de sa livraison, auquel cas, suis cette partie ci dessous. Si ton serveur est partagé avec d’autres utilisateurs, il est fort probable que la connexion par clé soit déjà active. Tu peux toujours regarder cette première partie si jamais un jour tu es amené à faire cette manipulation.

Que tu aies besoin de te connecter à un PC distant, un VPS, un serveur physique etc … la commande de base est :

ssh votreIdentifiant@tonIpServeur

Si le port SSH de cette machine distante est activé (par défaut c’est le 22), en entrant cette commande dans votre terminal, tu devrais avoir quelque chose comme ceci la première fois :

The authenticity of host '192.168.x.x (192.168.x.x)' can't be established.
ED25519 key fingerprint is SHA256:972F9A0Af340045f97F8a/C8284ed/d9023+nNub7688.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?   

Le fingerprint c’est l’empreinte du serveur laissée sur ta machine. Ton système va récupérer l’empreinte du serveur auquelle tu tentes de te connecter et la comparer avec les empreintes déjà existantes sur ton système.

Si c’est un nouveau serveur que tu n’as jamais ajouté, c’est normal qu’il n’existe pas encore, auquel cas, fais simplement "yes".

Si c’est un serveur dont tu as l’habitude d’accéder, alors ce n’est pas normal et ça peut être une tentative de hack (la personne malveillante génère un faux fingerprint et te fais croire que tu te connectes au bon endroit).

Ici ce n’est pas notre cas, on renseigne “yes” et on valide.

Warning: Permanently added 192.168.x.x' (ED25519) to the list of known hosts.  
monIdentifiant@192.168.xx.xxx's password:  Last login: Sun Jan  5 10:19:08 2025

On est connecté en SSH avec la méthode login/mdp. Maintenant notre but, c’est de faire la même chose avec une clé ssh.

La config SSH se trouve dans le fichier sshd_config d’un système UNIX.
On y retrouve dans ce fichier pas mal de paramètres lié à SSH tels que :

• ​La possibilité de se connecter en root

• Le port SSH (22 par défaut)

• La connexion par clé

• L’endroit où sont stockés les clés

On va d’abord paramétrer le serveur distant pour accepter la connexion par clé SSH.
Pour ça on va faire un sudo nano /etc/ssh/sshd_config dans le terminal.

Une fois ce fichier ouvert, cherche la ligne "#PubkeyAuthentication yes" et enlève le # pour décommenter la ligne.

On vient d’autoriser l’authentification par clé.
Maintenant redémarre le service qui gère le ssh avec un sudo systemctl restart sshd.service. C’est bon, on peut maintenant passer au vif du sujet, la connexion par clé.

2. Génération de la paire de clés

Le protocole SSH nécessite une paire de clés cryptographique qu’on appelle clé privée et clé publique.
La clé privée comme son nom l’indique, c’est ta clé personnelle, comme ta clé de maison.
La clé publique par contre c’est une clé que tu peux donner à un serveur pour lui ajouter une serrure qui correspond à ta clé privée.
Comme ta clé de maison, il va de soi que tu ne la donnerais pas à des inconnus, alors il en est de même pour ta clé privée car elle est la porte d’entrée à ta machine distante.

Génération de la clé

Sur ton PC, tu vas ouvrir un terminal et faire cette commande :
ssh-keygen -t ed25519 -f /home/tonuser/.ssh/my_first_key -b 4096 -C “my first ssh key” Tu vas faire entrée, et le système te demande si tu veux y mettre un mot de passe par dessus, c’est plus sécurisé mais pour les automatisations c’est pas terrible, par conséquent c’est à toi de voir si tu veux en mettre un ou pas.
On va décortiquer la commande ssh-keygen :

• -t c’est le type d’algo de chiffrement (ici ED25519), il en existe plein, je te laisse te documenter dessus.

• -f c’est le chemin où la clé sera générée, tu peux la mettre où tu veux mais en général c’est dans ton user /.ssh (A adapter en fonction de ton système, par défaut tu peux la laisser vide, il se placera dans tes documents)

• -b c’est la longueur de la clé, plus c’est long plus c’est robuste

• -C c’est si tu as plusieurs clés, tu peux y ajouter un commentaire pour t’y retrouver dans ton trousseau.

​Voila donc maintenant si tu vas dans ton dossier .ssh, tu as 2 clés => et my_key.pub (pour .public).
Je le répète une nouvelle fois, my_key reste bien au chaud sur ton PC et ne sera jamais donné à quelqu’un.

3. Dépôt de la clé publique

​Maintenant qu’on à notre clé publique, on va venir la déposer sur notre machine distante à l’aide d’une commande :

ssh-copy-id -i .ssh/my_key.pub monIdentifiant@192.168.xx.xxx
(cette commande fonctionne nativement sous UNIX mais sous Windows, ouvre un git bash pour faire cette action).
Renseigne ton mot de passe et … magie magie ! La clé a été déposée dans /home/tonIdentiiant/.ssh/authorized_keys.
c’est le fichier qui gère les autorisations des clés. Si ta clé publique n’est pas dans ce fichier, aucune serrure pour ta clé privée ne sera créée sur le serveur et rien ne se passera.

Envoi de la clé publique

4. Connexion SSH

​On arrive au bout du tunnel ! Il ne nous reste plus qu’à nous connecter avec la commande du début :

ssh monIdentifiant@192.168.xx.xxxsauf qu’on va lui rajouter la clé privée :
ssh monIdentifiant@192.168.xx.xxx -i .ssh/my_key
Si tout est bien configuré de ton côté sans mot de passe, tu as accès à ta machine.
Si le serveur te redemande un mot de passe, refais les étapes précédentes dans l’ordre.

Comment ça se passe derrière ?
Lors de notre commande, notre PC va venir demander un accès au serveur. Le serveur va vérifier dans le fichier authorized_keys si une clé publique de monIdentifiant existe. Si elle existe, le serveur envoie un challenge (une sorte de Captcha pour serveur) et la clé privée va résoudre celui-ci. Si le challenge est résolu, alors la clé privée et la clé publique sont bien une paire confirmée et l’utilisateur est donc authentifié. Sinon, il est rejeté.

Challenge SSH

Tu comprends pourquoi ta clé privée ne dois jamais être partagée car avec elle, une personne malveillante à accès au système où se trouve la clé publique.

Pour des raisons de sécurité, je t’invite à faire une paire par système et pas une paire pour l’ensemble de tes systèmes. Comme ça, si un jour, une clé privée est corrompue, tu n’as qu’un seul système à mettre à jour avec une nouvelle paire de clé.

Pour augmenter la sécurité de ta connexion SSH tu peux aussi te rendre dans le fichier de configuration de tout à l’heure /etc/ssh/sshd_config et tu décommentes la ligne suivante : "#PasswordAuthentication yes" puis passe la à “no”.

Ensuite restart le service : service sshd restartAttention, fais bien cette étape uniquement si tu as accès avec ta clé(car elle rend impossible la connexion par mot de passe) pour ne pas te retrouver bloqué en dehors de ton serveur sans moyen de connexion.

Le balrog a oublié sa clé SSH !

A présent tu as accès à ton système à distance, de manière sécurisée, tu peux donc paramétrer ton serveur pour y déployer ton application tranquillement.

4. Cas d'application

Tu trouveras ci-dessous quelques exemples de l'utilisation de clés SSH.

A. Github

Pour éviter de faire par la méthode "HTTPS", tu peux le faire en SSH, ce qui te permet de faire du CI/CD depuis Github et également de ne plus avoir à rentrer ton MDP quand tu fais une action sur un de tes repository.

Pour cela, tu vas générer une paire de clés pour github (Partie II de l’article) puis tu vas ouvrir ta clé publique et copier l’ensemble du fichier sur Github : Paramètres => clé SSH => Nouvelle clé SSH => colle le contenu de ta clé publique.
Tu auras maintenant ton github en SSH, plus besoin de rentrer ton mot de passe à chaque fois pour push.
L’ensemble de la procédure est disponible sur leur site si tu es perdu : GitHub.

B. Le Proxy Jump

​C'est un concept un petit peu plus avancé sur l’utilisation du SSH mais cela consiste à faire du “saute mouton” entre machines distantes qui possèdent elles-mêmes leurs clés d’accès aux autres machines.
Par exemple, notre machine n’a pas accès directement à la machine C. Mais possède un accès SSH via la machine B.
On va donc se connecter à la machine B puis la machine B se connecte à la machine C. On a donc accès à la machine C par l'intermédiaire de B.

Proxy Jump

C. Le Port Forwarding

C'est ce qu'on appelle en français la "redirection de port".

Prenons un exemple, tu as un serveur de développement où tu dev directement dessus (donc pas de local) et ton code c'est du React. Tu lances ton serveur de dev fourni par React avec la commande "npm start" et là ton serveur te dit de te connecter à localhost:3000.

Sauf que tu n'es pas physiquement présent sur ta machine de dev, donc si tu fais depuis ton navigateur préféré : https://codelab.devexploris.com, tu auras un joli "localhost refused to connect.". Mais du coup, comment voir ton résultat ? Et bien grâce au port forwarding, tu vas rediriger le port 3000 de react qui est sur ton serveur de dev, vers ta machine locale avec cette commande :

ssh -L 3000:localhost:3000 user@server

Ce qui va te permettre ainsi de dev directement sur ta machine locale avec ton code sur ta machine distante.

Bref tu l’auras compris, le ssh c’est un peu la base de la gestion des serveurs et j’espère que ce tutoriel te permettra de moins appréhender cette partie !