Utiliser SSH intelligemment

Module 2: SSH et clés · Temps de lecture : 10 minutes

Objectif pédagogique : À l'issue de cette leçon, vous saurez utiliser SSH au quotidien avec votre propre fichier de configuration, copier des fichiers avec scp et rsync, et accéder à une base de données par un tunnel sans ouvrir le port de la base de données sur Internet.

Notions clés : ~/.ssh/config, Host, HostName, User, IdentityFile, scp, rsync, sftp, redirection de port (port forwarding), -L, tunnel, ProxyJump, ServerAliveInterval, autre numéro de port, révocation d'une clé

Taper moins avec ~/.ssh/config

Au bout de quelques semaines, vous tapez ceci des dizaines de fois par jour :

anna@laptop:~$ ssh -i ~/.ssh/id_ed25519 anna@192.0.2.10

Avec un fichier de configuration pour le client, la commande devient plus courte et vous faites moins d'erreurs. Ce fichier se trouve sur votre propre ordinateur : ~/.ssh/config (Windows : C:\Users\anna\.ssh\config, sans extension).

Host web1
    HostName 192.0.2.10
    User anna
    IdentityFile ~/.ssh/id_ed25519
    ServerAliveInterval 60

Host test
    HostName test.example.com
    User anna
    Port 2222

Il suffit désormais de taper :

anna@laptop:~$ ssh web1
anna@web1:~$

À quoi servent ces lignes ?

• Host est le surnom que vous choisissez vous-même. Vous le tapez après ssh, scp et rsync.
• HostName est l'adresse réelle : une adresse IP ou un nom présent dans le DNS.
• User et Port sont le nom d'utilisateur et le port, que vous n'avez ainsi plus besoin de retenir.
• IdentityFile désigne la clé. C'est pratique si vous avez plusieurs clés ; sans cette ligne, ssh essaie vos clés par défaut.
• ServerAliveInterval 60 envoie toutes les 60 secondes un petit signe de vie. Beaucoup de box Internet et de réseaux wifi coupent une connexion silencieuse après quelques minutes ; grâce à cette option, votre session reste ouverte.

Ici aussi, comme sur le serveur, c'est la première valeur qui compte. Placez donc les règles générales comme Host * en bas du fichier.

Copier des fichiers : scp, rsync et sftp

scp copie un fichier, avec la même syntaxe que cp, mais précédée de host: :

anna@laptop:~$ scp backup.sql web1:/home/anna/
anna@laptop:~$ scp web1:/var/log/nginx/error.log .

rsync est plus malin pour les dossiers et les gros volumes : il n'envoie que ce qui a changé et peut reprendre une copie interrompue. Il doit être installé des deux côtés (apt install rsync).

anna@laptop:~$ rsync -avz --progress ./site/ web1:/var/www/example.com/

Faites attention à la barre oblique après ./site/ : avec la barre oblique, rsync copie le contenu du dossier ; sans elle, il copie le dossier lui-même (vous obtenez alors /var/www/example.com/site/). En cas de doute, faites d'abord un essai avec --dry-run, et soyez très prudent avec --delete, qui supprime du côté destinataire tout ce qui n'existe pas chez vous.

sftp et les programmes graphiques comme FileZilla ou WinSCP utilisent la même connexion SSH et la même clé. Aucun serveur FTP séparé n'est donc nécessaire. Un serveur FTP classique sur un VPS est déconseillé : le FTP ordinaire envoie votre mot de passe en clair sur le réseau.

Un tunnel plutôt qu'un port ouvert

C'est peut-être ce que SSH sait faire de plus utile. Imaginons qu'une base de données PostgreSQL tourne sur votre serveur. Vous voulez y accéder depuis votre ordinateur portable avec un programme graphique. La tentation est grande d'ouvrir le port 5432 sur Internet. Ne le faites pas : les ports de base de données ouverts sont l'une des principales causes de fuites de données (leçon 10.2), et la formation vérifiera plus tard depuis l'extérieur qu'ils sont fermés (exercice Z5.1).

Avec la redirection de port locale, vous demandez à SSH de créer un tunnel :

anna@laptop:~$ ssh -L 5432:127.0.0.1:5432 web1

Lisez cela ainsi : « écoute sur mon ordinateur portable sur le port 5432, et envoie tout ce qui y arrive à travers la connexion SSH vers 127.0.0.1:5432, vu depuis le serveur ». Tant que cette session reste ouverte, vous connectez votre programme de base de données à localhost port 5432 sur votre propre ordinateur portable, et vous arrivez sur la base de données du serveur.

Pourquoi est-ce si intéressant ?

• La base de données n'écoute que sur 127.0.0.1 sur le serveur et reste inaccessible depuis l'extérieur.
• La connexion est chiffrée par SSH, même si la base de données elle-même ne chiffre rien.
• Seules les personnes capables de se connecter en SSH peuvent y accéder. Vous profitez donc de la sécurité solide que vous avez déjà mise en place.

Si quelque chose utilise déjà le port 5432 sur votre ordinateur portable, choisissez un autre numéro à gauche : -L 15432:127.0.0.1:5432, et connectez-vous au port 15432. Si vous placez le tunnel dans ~/.ssh/config, vous l'avez toujours sous la main :

Host web1-db
    HostName 192.0.2.10
    User anna
    LocalForward 15432 127.0.0.1:5432

Avec ssh -N web1-db, vous obtenez uniquement le tunnel, sans ligne de commande.

Passer par un serveur intermédiaire : ProxyJump

Il arrive qu'un serveur ne soit joignable qu'en passant par un autre, par exemple un serveur de base de données sans adresse IP publique placé derrière votre serveur web. ProxyJump rebondit via le premier serveur pour atteindre le second :

Host db1
    HostName 10.0.0.5
    User anna
    ProxyJump web1

La différence avec le transfert d'agent (agent forwarding, leçon 2.1) : avec ProxyJump, le chiffrement s'étend de bout en bout entre votre ordinateur portable et db1. Le serveur intermédiaire ne fait que transmettre les paquets et ne peut pas utiliser votre clé.

Un autre numéro de port : oui ou non ?

Beaucoup de tutoriels conseillent de placer SSH sur un autre port, par exemple 2222. Qu'est-ce que cela change vraiment ?

• Cela réduit le bruit : la plupart des tentatives automatisées ne visent que le port 22. Votre journal devient plus calme.
• Ce n'est pas une mesure de sécurité. Un scanner qui parcourt tous les ports trouve SSH en quelques secondes grâce à sa bannière de version.

Avec des clés et la connexion par mot de passe désactivée (leçon 2.2), le port ne change pas grand-chose à la sécurité. Si vous voulez quand même en changer, procédez dans le bon ordre : ouvrir le nouveau port dans le pare-feu, faire écouter SSH sur les deux ports, tester dans une deuxième fenêtre, et seulement ensuite fermer l'ancien port. Sur Ubuntu 24.04 et versions ultérieures, il faut aussi tenir compte de systemctl daemon-reload et systemctl restart ssh.socket (leçon 2.2). N'oubliez pas que votre fournisseur dispose peut-être aussi d'un pare-feu.

Révoquer un accès

Un ancien collègue ou un développeur web avait une clé sur votre serveur et ne travaille plus pour vous ? Révoquer son accès est simple, à condition de tenir vos clés à jour :

1. Affichez toutes les clés : ssh-keygen -lf ~/.ssh/authorized_keys, et faites-le pour chaque utilisateur (y compris /root/.ssh/authorized_keys).
2. Supprimez la ligne de cette personne.
3. Si elle utilisait son propre compte utilisateur, verrouillez-le (leçon 3.1) et vérifiez si elle faisait partie du groupe sudo (leçon 3.2).
4. Si elle a vu des mots de passe, par exemple un mot de passe de base de données dans un fichier de configuration, changez-les aussi.

Une clé ordinaire n'a pas de date d'expiration. Ce que vous ne supprimez pas continue de fonctionner, même des années plus tard. Si vous donnez un accès temporaire à quelqu'un, vous pouvez placer l'option expiry-time="20261231" devant sa ligne dans authorized_keys ; après cette date, le serveur refuse la clé.

Résumé

• ~/.ssh/config sur votre propre ordinateur enregistre pour chaque serveur le nom, l'utilisateur, le port et la clé ; Host * se place en bas.
• scp pour des fichiers isolés, rsync pour des dossiers (attention à la barre oblique et à --delete), sftp au lieu de FTP.
• Avec ssh -L, vous accédez à une base de données par un tunnel chiffré, tandis que le port de la base de données reste fermé depuis l'extérieur.
• ProxyJump rebondit en toute sécurité via un serveur intermédiaire ; c'est mieux que le transfert d'agent.
• Un autre numéro de port réduit le bruit, mais ne protège pas. Les clés que vous ne supprimez pas continuent de fonctionner.

Quiz

Exercice

Exercice O2.3 : Une configuration SSH et un tunnel. Créez sur votre propre ordinateur un fichier ~/.ssh/config avec un surnom pour votre serveur, connectez-vous avec seulement ssh <bijnaam>, copiez un fichier avec scp ou rsync, et créez un tunnel avec -L vers un service qui, sur votre serveur, n'écoute que sur 127.0.0.1 (si vous n'avez pas encore de base de données, utilisez le port 22 du serveur lui-même : ssh -L 2200:127.0.0.1:22 <bijnaam> puis ssh -p 2200 anna@localhost). Répondez aux questions sur ce que fait le tunnel et sur la raison pour laquelle le port n'a pas besoin d'être ouvert.

Pour aller plus loin

Les étapes décrites dans ces articles s'appliquent aux VPS et aux panneaux de WebOké ; chez d'autres fournisseurs, le fonctionnement est similaire.

• Se connecter à votre VPS en SSH (et créer une clé SSH)
• Manuel de ssh_config (paramètres du client) : https://man.openbsd.org/ssh_config
• Manuel de ssh (options -L, -J, -N) : https://man.openbsd.org/ssh