12 - SSH : l'acces distant sécurisé
Ce que tu vas apprendre
- Generer et utiliser des clés SSH (ed25519)
- Configurer ~/.ssh/config pour simplifier tes connexions
- Creer des tunnels SSH pour acceder a des services distants
- Transferer des fichiers avec scp et rsync
- Securiser ton serveur en desactivant l'auth par mot de passe
Prerequisites
Connaitre les bases du firewall et avoir un serveur distant (ou un second PC) pour pratiquer.
SSH, c'est le premier truc que tu utilises sur un serveur et le dernier truc que tu veux voir casser. Pourtant, je vois encore des devs qui se connectent avec un mot de passe, qui n'ont pas de fichier config, et qui font des scp a rallonge. On va corriger tout ca.
Generer une paire de clés
Une clé SSH, c'est une paire : une clé privee (qui reste sur ta machine, jamais partagee) et une clé publique (que tu copies sur les serveurs).
bash# Generer une cle ed25519 (plus moderne et plus sure que RSA)
ssh-keygen -t ed25519 -C "nicolas@monpc"
# Ca genere deux fichiers :
# ~/.ssh/id_ed25519 (cle privee - NE JAMAIS PARTAGER)
# ~/.ssh/id_ed25519.pub (cle publique - a copier sur les serveurs)
On te demande une passphrase. Mets-en une. C'est une couche de sécurité supplementaire : meme si quelqu'un vole ta clé privee, il lui faut la passphrase pour l'utiliser.
Copier ta clé sur un serveur
bash# La methode simple
ssh-copy-id user@serveur
# Ca ajoute ta cle publique dans ~/.ssh/authorized_keys sur le serveur
# Si ssh-copy-id n'est pas disponible
cat ~/.ssh/id_ed25519.pub | ssh user@serveur "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
# Apres ca, tu peux te connecter sans mot de passe
ssh user@serveur
~/.ssh/config : la vraie productivité
Taper ssh -i ~/.ssh/cle_speciale -p 2222 nicolas@192.168.1.50 a chaque fois, ca use. Le fichier ~/.ssh/config resout ca :
# ~/.ssh/config
Host prod
HostName 203.0.113.50
User deploy
IdentityFile ~/.ssh/id_ed25519
Port 22
Host staging
HostName 203.0.113.51
User deploy
IdentityFile ~/.ssh/id_ed25519
Host db-prod
HostName 10.0.0.20
User admin
ProxyJump prod
Maintenant tu te connectes avec :
bashssh prod
ssh staging
ssh db-prod # passe par prod pour atteindre un serveur interne
ProxyJump est une perle. Ca te permet d'atteindre un serveur qui n'est pas directement accessible depuis Internet, en rebondissant via un autre serveur. Sur paltemps.fr, ma base de donnees est sur un réseau prive : j'y accede en passant par le serveur web.
Les tunnels SSH
Les tunnels SSH permettent de faire passer du trafic réseau à travers une connexion SSH chiffree. C'est magique pour acceder a des services distants comme si ils etaient locaux.
bash# Tunnel local (-L) : acceder a un service distant localement
# Ici, PostgreSQL sur le serveur distant devient accessible sur localhost:5432
ssh -L 5432:localhost:5432 prod
# Acceder a un service sur le reseau interne du serveur
ssh -L 5432:10.0.0.20:5432 prod
# Tunnel distant (-R) : exposer un service local sur le serveur distant
# Ton app locale (port 3000) devient accessible sur le serveur au port 8080
ssh -R 8080:localhost:3000 prod
# Proxy SOCKS (-D) : faire passer tout le trafic via le serveur
ssh -D 1080 prod
# Puis configure ton navigateur pour utiliser le proxy SOCKS sur localhost:1080
# Tunnel en arriere-plan sans ouvrir un shell
ssh -fN -L 5432:localhost:5432 prod
Le tunnel local -L c'est celui que j'utilise quotidiennement. Besoin de regarder la base de prod ? ssh -L 5432:localhost:5432 prod, puis psql -h localhost. Simple, sécurisé, pas besoin d'exposer PostgreSQL sur Internet.
Transferer des fichiers : scp et rsync
bash# scp : copie simple
scp fichier.txt prod:/opt/app/
scp prod:/var/log/app.log ./
# Copier un repertoire
scp -r ./dist prod:/opt/app/
# rsync : la version intelligente (ne copie que les differences)
rsync -avz --progress ./dist/ prod:/opt/app/dist/
# Decomposition :
# -a : archive (preserve permissions, dates, etc.)
# -v : verbose
# -z : compression pendant le transfert
# --progress : affiche l'avancement
# Exclure des fichiers
rsync -avz --exclude 'node_modules' --exclude '.env' ./app/ prod:/opt/app/
# Dry run : voir ce qui serait copie sans rien faire
rsync -avzn ./dist/ prod:/opt/app/dist/
rsync est supérieur a scp dans presque tous les cas. Il ne transféré que les différences, supporte la reprise apres interruption, et compresse a la volee. Pour les déploiements, c'est l'outil de référencé.
Agent forwarding
L'agent forwarding permet a un serveur distant d'utiliser tes clés SSH locales. Utile quand tu dois cloner un repo Git depuis un serveur sans y mettre ta clé privee :
bash# Dans ~/.ssh/config
Host prod
HostName 203.0.113.50
User deploy
ForwardAgent yes
# Ou en ligne de commande
ssh -A prod
# Sur le serveur, tu peux maintenant faire :
git clone git@github.com:monorg/monrepo.git
# Ca utilise ta cle locale, pas une cle sur le serveur
Attention : n'active le forwarding que vers des serveurs de confiance. Un admin malveillant du serveur pourrait utiliser ta clé pendant que tu es connecte.
Désactiver l'authentification par mot de passe
Une fois que tes clés SSH fonctionnent, désactivé l'auth par mot de passe. Ca elimine toutes les attaques par brute force :
bash# Sur le serveur, edite la config SSH
sudo nano /etc/ssh/sshd_config
# Change ces lignes :
# PasswordAuthentication no
# PubkeyAuthentication yes
# PermitRootLogin no
# Recharge la config
sudo systemctl reload sshd
Verifie bien que ta connexion par clé fonctionne AVANT de désactiver les mots de passe. Ouvre un second terminal, teste la connexion. Si ca marche, tu peux couper les mots de passe sans risque.
Résumé
- Utilise ed25519 pour tes clés, toujours avec une passphrase
~/.ssh/configelimine les commandes a rallongeProxyJumppour atteindre les serveurs sur réseau prive- Tunnels
-Lpour acceder aux services distants localement rsync -avzplutot quescppour les transferts- Desactive l'auth par mot de passe une fois les clés en place
Article précédent : Le firewall Article suivant : Les variables d'environnement