SSH : se connecter et gérer un serveur à distance

SSH (Secure Shell) est le protocole standard pour piloter une machine distante depuis son terminal, en toute confidentialité. Dès que vous louez un VPS, déployez un site ou administrez un serveur, c’est le premier outil que vous ouvrez. Ce guide part de la connexion la plus simple pour aller jusqu’aux clés, aux transferts de fichiers, aux tunnels et à la sécurisation d’un serveur exposé sur Internet. Toutes les commandes sont réelles et fonctionnent sous Linux, macOS et le terminal WSL/Git Bash sous Windows.

Se connecter pour la première fois

La forme de base indique l’utilisateur et l’adresse du serveur, séparés par un @ :

ssh [email protected]

Si le serveur SSH n’écoute pas sur le port par défaut (22), on le précise avec -p :

ssh -p 65002 [email protected]

À la toute première connexion, SSH affiche l’empreinte de la clé du serveur et demande de la valider. Répondez yes : l’empreinte est alors enregistrée dans ~/.ssh/known_hosts. Si un jour vous voyez un avertissement bruyant de type « REMOTE HOST IDENTIFICATION HAS CHANGED », c’est que la clé du serveur a changé (réinstallation… ou attaque). Ne l’ignorez pas à la légère.

Par défaut, la connexion demande le mot de passe du compte distant. C’est fonctionnel mais fragile : on va rapidement le remplacer par des clés.

Les clés SSH : le vrai bon réflexe

Une paire de clés remplace le mot de passe par un couple clé privée (qui reste sur votre machine, jamais partagée) et clé publique (déposée sur le serveur). C’est plus sûr et plus pratique.

Générer une paire de clés

L’algorithme Ed25519 est le choix moderne recommandé :

ssh-keygen -t ed25519 -C "alice@mon-portable"

L’outil propose un emplacement par défaut (~/.ssh/id_ed25519) et demande une passphrase. Mettez-en une : elle chiffre la clé privée sur le disque, de sorte qu’un fichier volé reste inutilisable. Deux fichiers sont créés :

~/.ssh/id_ed25519 — la clé privée, à protéger absolument.
~/.ssh/id_ed25519.pub — la clé publique, que l’on peut diffuser.

Copier la clé publique sur le serveur

Le plus simple, quand l’accès par mot de passe est encore actif :

ssh-copy-id -p 65002 [email protected]

La commande ajoute proprement votre clé publique dans le fichier ~/.ssh/authorized_keys du serveur. Si ssh-copy-id n’est pas disponible (Windows notamment), on fait la même chose à la main :

cat ~/.ssh/id_ed25519.pub | ssh -p 65002 [email protected] "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Reconnectez-vous : SSH utilise désormais la clé, et ne demande plus le mot de passe du compte (juste, éventuellement, la passphrase de la clé).

ssh-agent : ne taper sa passphrase qu’une fois

ssh-agent garde la clé déchiffrée en mémoire le temps de la session, pour ne pas retaper la passphrase à chaque connexion.

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Sur macOS, on peut enregistrer la passphrase dans le trousseau :

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

Vérifiez les clés chargées avec ssh-add -l.

Le fichier ~/.ssh/config : des alias qui changent la vie

Retaper ssh -p 65002 [email protected] dix fois par jour est pénible. Le fichier ~/.ssh/config permet de tout condenser en un mot :

Host serveur-prod
    HostName 203.0.113.10
    User alice
    Port 65002
    IdentityFile ~/.ssh/id_ed25519

Host *.dev
    User deploy
    ForwardAgent yes

Désormais, ssh serveur-prod suffit. Ce fichier profite aussi à scp, rsync et Git. Pensez à le protéger : chmod 600 ~/.ssh/config. Comme pour tout fichier sous ~/.ssh, les permissions comptent — SSH refuse une clé privée lisible par d’autres utilisateurs ; si le sujet vous échappe, notre guide sur les permissions Linux éclaire ce point.

Transférer des fichiers : scp et rsync

Une session SSH sert aussi de canal pour déplacer des fichiers.

scp pour un envoi ponctuel

# Envoyer un fichier local vers le serveur
scp rapport.pdf serveur-prod:~/documents/

# Récupérer un fichier depuis le serveur
scp serveur-prod:/var/log/nginx/access.log ./

# Un dossier entier
scp -r ./site serveur-prod:/var/www/

Grâce à l’alias serveur-prod, plus besoin de répéter port et utilisateur.

rsync pour synchroniser

rsync est bien plus intelligent : il ne transfère que ce qui a changé et sait reprendre une copie interrompue. Idéal pour déployer un site.

rsync -avz --delete ./dist/ serveur-prod:/var/www/site/

-a conserve permissions et dates, -v détaille, -z compresse à la volée.
--delete supprime côté serveur ce qui n’existe plus en local (attention, miroir strict).
La barre finale de ./dist/ est significative : elle copie le contenu du dossier, pas le dossier lui-même.

Ce genre de commande s’intègre naturellement dans un script Bash de déploiement.

Les tunnels SSH

Un tunnel fait transiter un autre trafic par la connexion chiffrée. Cas classique : accéder à une base de données qui n’écoute que sur localhost côté serveur.

# Le port local 5433 pointe vers le PostgreSQL du serveur (port 5432)
ssh -L 5433:localhost:5432 serveur-prod

Tant que la session reste ouverte, psql -h localhost -p 5433 sur votre machine parle à la base distante, chiffré de bout en bout. Le tunnel inverse (-R) expose un service local vers le serveur, pratique pour une démo. L’option -N ouvre le tunnel sans lancer de shell, et -f le bascule en arrière-plan :

ssh -fN -L 5433:localhost:5432 serveur-prod

Sécuriser le serveur SSH

Une fois les clés en place, verrouillez l’accès. Toute la configuration serveur se trouve dans /etc/ssh/sshd_config (à éditer en root).

Désactiver l’authentification par mot de passe

C’est la mesure la plus efficace contre le bruteforce. Vérifiez d’abord que votre clé fonctionne, sinon vous vous enfermez dehors.

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password

Puis rechargez le service :

sudo systemctl reload ssh

Autres réflexes utiles

Changer le port (Port 65002) réduit énormément le bruit des scanners automatiques. Ce n’est pas une protection en soi, mais un filtre commode.
Installer fail2ban pour bannir les IP qui multiplient les échecs :

sudo apt install fail2ban
sudo systemctl enable --now fail2ban

Ouvrir uniquement le port SSH nécessaire dans le pare-feu :

sudo ufw allow 65002/tcp
sudo ufw enable

Limiter les utilisateurs autorisés avec une directive AllowUsers alice deploy dans sshd_config.

En résumé

Retenez la progression : connexion simple, puis clés Ed25519, puis ~/.ssh/config pour des alias confortables, et enfin scp/rsync pour les fichiers. Côté serveur, la combinaison gagnante est claire — clés uniquement, mot de passe désactivé, port modifié et fail2ban. Avec ces briques, vous administrez un serveur distant aussi sereinement que votre propre machine, et vos déploiements deviennent une simple commande.