Antisèche des commandes SSH : clés, scp et tunnels

Cette antisèche des commandes SSH saute l'histoire du protocole et vous donne les lignes que vous tapez vraiment, les plus utilisées en premier. Connectez-vous avec ssh user@host, ajoutez -p 2222 quand le serveur a quitté le port 22, générez une clé moderne avec ssh-keygen -t ed25519, envoyez-la sur une machine avec ssh-copy-id, et copiez des fichiers avec scp. Les options de tunnel (-L, -D, -R) sont réelles et valent le coup, et elles arrêtent de ressembler à de la magie quand on se souvient que SSH fait deux boulots : il vous connecte, et il peut pousser du trafic dans ce même tuyau chiffré. Un court bloc ~/.ssh/config réduit ensuite les longues commandes à un nom que vous choisissez.

Vous voulez entrer sur une machine. Voilà, c'est tout, et pourtant la moitié des guides SSH commencent par un cours d'histoire sur le protocole. On saute. La commande qu'il vous faut, c'est ssh user@host, et c'est la toute première ci-dessous. Se connecter, générer une clé, copier cette clé, déplacer un fichier. Ces quatre-là couvrent l'essentiel des journées. Les tunnels chic, c'est réel et je m'en sers, mais ce n'est pas pour ça que vous avez ouvert cette page.

Un truc à dire d'entrée. SSH fait deux boulots qui ressemblent à un seul : il vous connecte, et il peut pousser n'importe quel trafic réseau dans ce même tuyau chiffré. Gardez ces deux idées séparées dans votre tête et les options bizarres (le -L, le -D) arrêtent de ressembler à de la magie.

Se connecter à un serveur

Le cas de base est court et il ne change quasiment jamais. ssh user@host, où user est votre compte en face et host un nom ou une IP. À la première connexion, SSH vous montre une empreinte et demande si vous lui faites confiance. Vous tapez yes une fois, il s'en souvient, et il vous préviendra haut et fort si cette empreinte change un jour (c'est tout l'intérêt, cet avertissement est une fonctionnalité, pas un caprice).

Ce -p piège les gens parce que scp utilise un -P majuscule pour la même idée, et les confondre est un passage obligé. Minuscule pour ssh, majuscule pour scp. Je me suis trompé là-dessus plus souvent que je ne voudrais l'admettre.

Générer une clé SSH

Les mots de passe pour SSH, c'est une habitude à lâcher. Une paire de clés est plus solide et, une fois en place, plus rapide : pas de saisie de mot de passe, vous atterrissez direct. On en génère une avec ssh-keygen. Le -t choisit l'algorithme et le -C ajoute un commentaire pour que le vous du futur sache quelle clé est laquelle.

Ça écrit deux fichiers : ~/.ssh/id_ed25519 (votre clé privée, gardez-la comme un mot de passe) et ~/.ssh/id_ed25519.pub (la moitié publique, celle que vous distribuez). Quand il demande une phrase de passe, mettez-en une. Une clé privée sans phrase de passe qui fuite, c'est juste un mot de passe qui traîne dans un fichier, et vous ne remarquerez sa disparition que bien trop tard.

Mon avis : en 2026, ed25519, pas RSA. Pendant des années le défaut était rsa, souvent en 2048 ou 4096 bits, et ça marche encore très bien. Mais les clés ed25519 sont minuscules, rapides, et la sécurité est excellente, donc choisir -t ed25519 pour une nouvelle clé est simplement le meilleur défaut aujourd'hui. Le seul moment où je reviens à -t rsa -b 4096, c'est un vieil équipement antique ou un serveur figé qui ne sait vraiment pas parler ed25519, et c'est assez rare pour que je traite ça comme l'exception, pas la règle. Franchement, si vos clés RSA tournent aujourd'hui, il n'y a pas le feu, pas besoin de tout faire tourner cette nuit. Faites juste les nouvelles clés en ed25519 et laissez les vieilles s'éteindre toutes seules.

Copier sa clé sur un serveur

En voilà une qui m'agace. Tant de gens génèrent une clé, puis se connectent en SSH avec leur mot de passe, puis ouvrent ~/.ssh/authorized_keys dans vi et collent la clé publique à la main, en se battant avec l'indentation, en espérant ne pas avoir ajouté un retour à la ligne de trop. Il y a une commande exactement pour ça. C'est ssh-copy-id, et elle fait toute la danse à votre place.

On vous demandera votre mot de passe cette dernière fois. Après ça, l'authentification par clé prend le relais et la demande de mot de passe disparaît. Si la commande n'est pas sur votre machine (elle manque sur macOS d'origine et quelques installs minimales), le chemin manuel marche toujours : cat ~/.ssh/id_ed25519.pub | ssh user@host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys". Même résultat, plus de frappe.

Copier des fichiers avec scp

Besoin d'un fichier sur l'autre machine, ou d'en récupérer un ? scp, c'est la copie de fichiers de SSH. Le modèle mental, c'est le bon vieux cp, sauf qu'un côté porte un préfixe user@host: pour dire « ce chemin-là est là-bas ». Les deux-points font tout le travail. Oubliez-les et vous fabriquez juste une copie locale au nom déroutant.

Pour un fichier ponctuel, scp est parfait et je ne vais pas vous en dissuader. Pour synchroniser à répétition une grosse arborescence, rsync par-dessus SSH est plus malin parce qu'il n'envoie que ce qui a changé, mais c'est une autre page. Copie rapide, vous prenez scp.

Tunnels : rediriger un port, ou tout un proxy

C'est là que le deuxième boulot de SSH (faire transiter du trafic) gagne sa place. Vous pouvez router un port à travers la connexion chiffrée pour qu'un service d'une machine apparaisse comme tournant sur une autre. Trois parfums, et les lettres prêtent vraiment à confusion, donc ici le tableau compte plus que d'habitude.

La redirection locale (-L), c'est celle de tous les jours. Une base qui n'écoute que sur la loopback du serveur ? ssh -L 5432:localhost:5432 user@host et voilà votre 5432 local qui lui parle, à travers SSH, sans ouvrir le moindre trou dans le pare-feu. Le proxy SOCKS (-D), c'est l'option du génie fainéant : une option et tout votre navigateur sort par le serveur distant, pratique sur un wifi de café douteux. La redirection distante (-R) retourne le cerveau parce qu'elle marche à l'envers, en exposant un truc de votre portable côté serveur. Si garder -L et -R au clair vous fait loucher, un générateur de commande de tunnel SSH construit la ligne exacte et indique quel bout est lequel.

Le fichier ~/.ssh/config (la vraie amélioration)

Si vous ne retenez qu'une chose de cette page, retenez celle-ci. Taper ssh -i ~/.ssh/work_key -p 2222 deploy@203.0.113.10 dix fois par jour, c'est un impôt que vous n'êtes pas obligé de payer. Posez un bloc dans ~/.ssh/config et tout ça s'effondre en un nom que vous choisissez.

Après ça, ssh monserveur est la commande complète. scp file.txt monserveur:/tmp/ aussi, parce que scp lit le même fichier de config. C'est le plus gros gain de confort de toute cette liste, et il faut environ une minute pour configurer le premier hôte. J'en garde une douzaine dans le mien et je ne me souviens quasiment plus des vraies IP, ce qui est un peu le but.

Agent forwarding et débogage

Deux de plus qui méritent leur place. L'une est une commodité avec un bord coupant, l'autre est comment vous comprenez pourquoi une connexion meurt.

À propos de -A : l'agent forwarding est délicieux quand vous faites du SSH vers un rebond et devez aller plus loin sans trimballer de clés privées. Pratique, oui. Mais voici la mise en garde, et elle est réelle : tant que vous êtes connecté, quiconque a les droits root sur cet hôte peut discrètement utiliser votre agent transféré pour s'authentifier en votre nom partout où votre clé ouvre. Sur une machine de pleine confiance, d'accord. Sur un hôte partagé ou non fiable, ne transférez pas votre agent ; utilisez plutôt ProxyJump, qui n'expose pas vos clés à la machine intermédiaire. Et -v, c'est la première chose à essayer quand SSH refuse de se connecter ou rejette silencieusement votre clé. Il montrera les clés proposées, les méthodes d'authentification autorisées par le serveur, exactement où la négociation a déraillé. Neuf fois sur dix la réponse est là, dans la sortie, en général un problème de permissions sur ~/.ssh.

Et après

Voilà le jeu de travail. Se connecter, les clés, ssh-copy-id, scp, les trois types de tunnels, l'alias de config, l'agent forwarding, et -v pour quand tout part de travers. Ça couvre vraiment l'essentiel de ce que je fais avec SSH dans une semaine normale, plus le truc rare que je cherche comme tout le monde. Une fois installé dans le shell, la même habitude copier-plutôt-que-mémoriser paie ailleurs, que vous fouilliez les connexions et les interfaces, que vous cherchiez des fichiers par nom ou par taille avant de les scp, ou que vous projetiez les mêmes idées sur Windows et cmd.

Questions fréquentes