Linux / Commande ssh : connexion distante, clés d’hôte et transferts

ssh est le client OpenSSH qui ouvre une session chiffrée sur un serveur distant ou y exécute une commande. Pour vous connecter, indiquez le serveur et le compte distant, puis vérifiez son identité à l’aide de sa clé d’hôte avant l’authentification. Le chiffrement ne remplace pas cette vérification, particulièrement lors du premier accès ou d’un changement de clé.

Préparer la connexion et choisir le compte

SSH signifie Secure Shell. Il distingue l’identité du serveur, vérifiée avec une clé d’hôte, et celle de l’utilisateur, prouvée par les méthodes autorisées : mot de passe, clé publique ou autres mécanismes configurés. Préparez l’adresse réelle, le port, un compte autorisé et la méthode d’authentification prévue.

ssh [OPTIONS] [UTILISATEUR@]HOTE [COMMANDE_DISTANTE]

ssh alice@server.example.com
ssh -p 2222 alice@server.example.com

alice est le compte du serveur, pas nécessairement votre compte local. server.example.com et le port 2222 sont à remplacer par les valeurs fournies pour votre serveur. Le port par défaut est normalement 22 ; une configuration cliente peut aussi sélectionner d’autres paramètres. L’option de port est ici -p, en minuscule.

Après une connexion et une authentification réussies, vous obtenez normalement un shell distant. Vérifiez la machine et le compte avant des commandes d’administration. Pour fermer une session ordinaire, utilisez exit ou Ctrl+D ; un programme encore actif dans la session peut nécessiter d’abord sa propre fermeture.

Vérifier la clé d’hôte au premier accès

Un premier accès peut afficher une demande ressemblant à celle-ci. La forme et l’algorithme dépendent du serveur et du client ; les points de suspension remplacent ici une vraie empreinte :

The authenticity of host 'server.example.com' can't be established.
ED25519 key fingerprint is SHA256:...
Are you sure you want to continue connecting (yes/no/[fingerprint])?

1. Obtenez l’empreinte attendue auprès de l’administrateur ou d’une console de gestion fiable, par un chemin indépendant de cette nouvelle connexion.
2. Comparez l’algorithme et l’empreinte complète avec la valeur affichée. Vérifiez également le nom et la destination prévus.
3. Acceptez uniquement lorsque la comparaison est correcte. Le client peut alors enregistrer la clé, normalement dans ~/.ssh/known_hosts selon sa configuration.

Lors d’une alerte de clé modifiée, arrêtez la tentative et confirmez la cause. Une réinstallation ou une rotation de clé est possible, mais une mauvaise destination ou une interception l’est aussi. Supprimer automatiquement l’entrée connue ou désactiver la vérification retire précisément la protection qui signale ce changement.

Les configurations d’entreprise peuvent employer des certificats ou d’autres mécanismes de confiance, auquel cas le message initial peut différer. L’absence de la demande ci-dessus ne dispense pas de suivre la politique de vérification prévue pour le serveur.

Utiliser une clé et exécuter une commande distante

Si vous disposez déjà d’une paire de clés dont la clé publique est autorisée pour ce compte distant :

ssh -i ~/.ssh/id_ed25519 alice@server.example.com
ssh alice@server.example.com hostname

-i choisit le fichier d’identité ; ce n’est pas une commande de création ou d’installation de clé sur le serveur. La clé privée reste locale et doit être protégée, avec une sauvegarde adaptée et des droits limités à son propriétaire. Une phrase secrète peut la protéger au repos. Ne transmettez pas cette clé privée au serveur ni à une autre personne.

La seconde commande exécute hostname sur le serveur puis termine la session de commande ; elle n’affiche pas le nom de votre poste local. Le résultat attendu est le nom rapporté par le serveur, sans valeur fixe à copier ici. Le code de sortie de ssh est normalement celui de la commande distante, ou 255 en cas d’erreur SSH.

Pour une commande plus complexe, distinguez l’interprétation par le shell local et celle par le shell distant. Les arguments d’une commande distante sont assemblés pour être exécutés côté serveur ; les guillemets locaux ne garantissent donc pas à eux seuls la préservation de toute donnée arbitraire. Commencez par des commandes simples et vérifiez l’endroit où une variable doit être développée.

Passer par un saut ou créer un transfert local

ssh -J alice@jump.example.com alice@server.example.com

-J établit le passage par un hôte de saut autorisé. Les paramètres propres au saut, comme un port ou une identité différents, doivent être configurés pour cet hôte ; les options de destination ne s’appliquent pas toutes automatiquement au saut. Cette méthode ne nécessite pas d’ajouter par défaut le transfert d’agent -A.

Pour rendre accessible depuis la boucle locale de votre poste un service HTTP autorisé sur la boucle locale du serveur SSH :

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:8080:127.0.0.1:80 alice@server.example.com

La première adresse 127.0.0.1 est celle de l’écoute sur votre poste, au port 8080. La seconde est la destination vue depuis le serveur distant, au port 80. Le trafic entrant dans ce port local traverse le canal SSH, puis le serveur ouvre la connexion vers sa propre boucle locale. Cela suppose que ce service existe et que la politique SSH autorise ce transfert.

-N n’exécute pas de commande distante. ExitOnForwardFailure=yes demande l’arrêt si le transfert ne peut pas être établi, par exemple si l’écoute locale échoue ; cela ne garantit pas que le service final répondra à chaque connexion. Vérifiez ensuite la réponse HTTP sur http://127.0.0.1:8080 depuis votre poste. Ctrl+C dans le terminal de ce ssh au premier plan ferme ce tunnel.

L’adresse locale explicite évite une écoute sur toutes les interfaces dans cet exemple. Même une écoute de boucle locale peut être utilisée par d’autres processus locaux ; elle n’ajoute pas une authentification applicative au service. Ne remplacez pas cette adresse par une adresse générique sans examiner la portée d’accès souhaitée.

Séparer les étapes d’un échec de connexion

ssh -v alice@server.example.com

Une erreur de nom relève de la résolution DNS ; un délai ou un refus peut concerner le chemin, le port ou le service. Une alerte de clé d’hôte concerne l’identité du serveur. Un refus d’authentification apparaît à une autre étape : vérifiez le compte, la clé autorisée, les permissions et la politique du serveur.

La vérification TCP avec nc donne un indice limité sur le port ; elle ne remplace pas la négociation SSH. Les traces -v peuvent exposer noms, comptes, chemins et détails de configuration : relisez-les avant de les partager.

Les options officielles du client OpenSSH et le manuel de sa configuration décrivent les identités, les hôtes de saut et la portée des transferts. Utilisez aussi ssh -V et la documentation de votre version locale.