Linux pour les devs - 12 - SSH : l'acces distant sécurisé

Cles SSH, config, tunnels, rsync et bonnes pratiques : tout pour se connecter a ses serveurs sans friction.

  1. 01 Linux pour les devs - 00 - Pourquoi Linux meme si tu codes sur Mac ou Windows
  2. 02 Linux pour les devs - 01 - Le terminal, bash et zsh
  3. 03 Linux pour les devs - 02 - Fichiers et répertoires
  4. 04 Linux pour les devs - 03 - Permissions et droits d'acces
  5. 05 Linux pour les devs - 04 - Utilisateurs, groupes et sudo
  6. 06 Linux pour les devs - 05 - nano, vim, sed et awk
  7. 07 Linux pour les devs - 06 - Pipes et redirections
  8. 08 Linux pour les devs - 07 - grep et find en profondeur
  9. 09 Linux pour les devs - 08 - Les processus : comprendre ce qui tourne sur ta machine
  10. 10 Linux pour les devs - 09 - systemd : gerer tes services comme un pro
  11. 11 Linux pour les devs - 10 - Le réseau : comprendre ce qui passe par le fil
  12. 12 Linux pour les devs - 11 - Le firewall : contrôler qui entre et qui sort
  13. 13 Linux pour les devs - 12 - SSH : l'acces distant sécurisé
  14. 14 Linux pour les devs - 13 - Les variables d'environnement : configurer sans hardcoder
  15. 15 Linux pour les devs - 14 - Scripts bash : automatiser pour ne plus se répéter
  16. 16 Linux pour les devs - 15 - cron : les taches planifiees
  17. 17 Linux pour les devs - 16 - Les logs : lire, filtrer, comprendre
  18. 18 Linux pour les devs - 17 - Stockage et disques
  19. 19 Linux pour les devs - 18 - Les gestionnaires de paquets
  20. 20 Linux pour les devs - 19 - Les conteneurs sans Docker
  21. 21 Linux pour les devs - 20 - Securiser un serveur Linux
  22. 22 Linux pour les devs - 21 - Performance et diagnostic
  23. 23 Linux pour les devs - 22 - tmux : le multiplexeur de terminal
  24. 24 Linux pour les devs - 23 - Glossaire Linux

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/config elimine les commandes a rallonge
  • ProxyJump pour atteindre les serveurs sur réseau prive
  • Tunnels -L pour acceder aux services distants localement
  • rsync -avz plutot que scp pour 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

Sources

Réservez un audit gratuit de 30 minutes. Je vous montre concrètement ce qu'on peut automatiser.