Se connecter à un serveur en SSH : Windows, macOS et Linux

Un serveur fraîchement commandé arrive sans écran ni clavier. La seule porte d'entrée passe par SSH, le protocole Secure Shell. Cet article vous accompagne pour la première connexion depuis trois systèmes d'exploitation, explique la question posée sur l'empreinte (que presque tous les débutants valident sans la lire) et montre comment transférer des fichiers. À la fin vient la partie que la plupart des guides passent sous silence : ce que vous faites quand cela ne fonctionne pas, et à quoi vous voyez que cela a vraiment fonctionné.

Toutes les indications ont été vérifiées sur Debian 13, Debian 12, Ubuntu 24.04 LTS et Ubuntu 22.04 LTS. Là où ces quatre systèmes diffèrent, c'est signalé explicitement. Sur le serveur, les commandes s'exécutent en tant que root. Sur votre propre machine en revanche, vous travaillez avec un compte utilisateur normal : chaque commande qui modifie le système y est donc précédée d'un sudo.

Ce dont vous avez besoin avant la première connexion

Trois informations suffisent : l'adresse IP du serveur, le nom d'utilisateur et le mot de passe ou la clé privée. Chez KernelHost, vous trouvez l'IP et les identifiants dans l'espace client une fois le serveur mis à disposition. Sur un serveur root KVM ou un serveur dédié fraîchement installé, l'utilisateur par défaut est en règle générale root.

S'y ajoute une quatrième information : le port. Par défaut, c'est le 22. Vous n'avez besoin d'un autre numéro que si vous l'avez changé vous-même ou si l'image l'a déplacé. Retenez dès maintenant un piège qui vous fera gagner du temps plus tard : ssh écrit le port en minuscule (-p), scp l'écrit en majuscule (-P).

Dans les exemples, l'adresse 203.0.113.10 revient partout. Elle est officiellement réservée à la documentation et n'existe pas. Remplacez-la par l'IP de votre serveur.

La première connexion sous Linux et macOS

Les deux systèmes embarquent le client OpenSSH. Sous macOS, ouvrez Terminal (dans le dossier Utilitaires), sous Linux n'importe quelle fenêtre de terminal. La commande est identique sur les deux :

ssh root@203.0.113.10

Si SSH écoute sur un autre port :

ssh -p 2222 root@203.0.113.10

Si votre système ne connaît pas ssh, ce qui arrive sur des conteneurs (container) très épurés ou des installations minimales, vérifiez et installez de cette manière :

ssh -V
sudo apt update
apt-cache policy openssh-client
sudo apt install -y openssh-client

L'ordre est volontaire. ssh -V est la commande de vérification et non une preuve de réussite : si le shell répond bash: ssh: command not found, c'est que le paquet openssh-client manque et que vous l'installez avec sudo apt install -y openssh-client. sudo apt update doit passer avant apt-cache policy openssh-client, car cette commande reste vide sans listes de paquets à jour, ou n'annonce que Installed: (none). Et le sudo n'est pas décoratif : sans droits d'administration, apt s'arrête sur Could not open lock file /var/lib/apt/lists/lock.

ssh -V écrit la version sur la sortie d'erreur, pas sur la sortie standard. Ce n'est pas un défaut, c'est ainsi depuis toujours. Sous Debian 13, vous voyez OpenSSH_10.0p2, sous Debian 12 OpenSSH_9.2p1, sous Ubuntu 24.04 OpenSSH_9.6p1 et sous Ubuntu 22.04 OpenSSH_8.9p1. Ces numéros comptent pour la suite, car le comportement de scp a justement changé entre ces versions.

L'empreinte, et pourquoi il ne faut pas la valider machinalement

Lors de la toute première tentative de connexion, SSH demande :

The authenticity of host '203.0.113.10 (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:qWU2Zx9mF7hLtHkQ4gRXn0aVbC3sYpJ8dKe1TmNoPU.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Ce qui se passe ici : chaque serveur SSH génère lors de son installation sa propre paire de clés, ce que l'on appelle la clé d'hôte (host key). L'empreinte est une courte somme de contrôle de la partie publique. Votre client ne connaît pas encore ce serveur et ne peut donc pas garantir qu'à l'autre bout se trouve bien votre serveur, et non quelqu'un qui s'est intercalé.

Si vous tapez yes, l'empreinte est enregistrée dans ~/.ssh/known_hosts. À partir de là, votre client vérifie silencieusement à chaque connexion suivante que le serveur présente bien la même clé. Cette unique question est donc le moment où tout le modèle de confiance se construit. Ensuite, plus personne ne vous demande rien.

Vous ne pouvez la contrôler correctement que par un second canal, indépendant. Sur un serveur KVM, la console de l'espace client s'y prête bien : vous vous y connectez localement, sans réseau du tout, et vous faites afficher l'empreinte.

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

La sortie ressemble à ceci :

256 SHA256:qWU2Zx9mF7hLtHkQ4gRXn0aVbC3sYpJ8dKe1TmNoPU root@server (ED25519)

Si la partie qui suit SHA256: correspond à ce qu'affiche votre client, tout va bien. Si vous voulez essayer le format sans le moindre risque, générez en local une clé jetable :

ssh-keygen -t ed25519 -f /tmp/demo -N "" -C demo
ssh-keygen -lf /tmp/demo.pub

Deux remarques tirées de la pratique. Premièrement : un serveur possède généralement plusieurs clés d'hôte (ED25519, ECDSA, RSA). C'est habituellement la clé ED25519 qui s'affiche, parce que les clients modernes la préfèrent. Si vous comparez par mégarde avec ssh_host_rsa_key.pub, rien ne correspondra alors que tout est correct. Deuxièmement : StrictHostKeyChecking=no désactive complètement la vérification. Ce n'est pas une solution, c'est la mise hors service de la fonction de sécurité. Si vous avez besoin d'automatisation, -o StrictHostKeyChecking=accept-new est le bon choix : cette option accepte automatiquement les serveurs inconnus, mais continue d'avertir en cas de changement.

Windows : le client OpenSSH intégré

Depuis Windows 10 version 1809, Microsoft livre le même client OpenSSH que celui utilisé par Linux et macOS. Vous n'avez donc plus besoin d'un logiciel supplémentaire. Ouvrez PowerShell, l'invite de commandes ou Windows Terminal et tapez la même commande que plus haut :

ssh root@203.0.113.10

Sous Windows 10 et Windows 11, le client est un composant facultatif, déjà actif sur la plupart des installations. Si ce n'est pas le cas, vérifiez et installez-le depuis un PowerShell lancé avec des droits d'administrateur :

Get-WindowsCapability -Online -Name OpenSSH.Client*
Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0

Vous pouvez aussi passer par Paramètres, Système, Fonctionnalités facultatives. Les programmes se trouvent ensuite dans C:\Windows\System32\OpenSSH\, votre configuration et les clés d'hôte connues dans %USERPROFILE%\.ssh\, donc typiquement C:\Users\Name\.ssh\known_hosts.

La version Windows est en retard sur la version Linux. Sur les installations Windows 11 récentes, ssh -V annonce le plus souvent OpenSSH_for_Windows_9.5p2. Pour un usage quotidien, cela suffit amplement.

Il reste tout de même une particularité : les droits de fichiers Windows. Si vous déposez une clé privée que d'autres comptes peuvent lire, SSH refuse de travailler et affiche Permissions for 'C:\Users\Name\.ssh\id_ed25519' are too open. Voici comment corriger cela :

icacls "$env:USERPROFILE\.ssh\id_ed25519" /inheritance:r /grant:r "$($env:USERNAME):(R)"

Windows : PuTTY

PuTTY a longtemps été la voie standard sous Windows et l'est resté pour beaucoup. La version actuelle est la 0.84, sortie en mai 2026. Téléchargez-la exclusivement depuis le site de son auteur (chiark.greenend.org.uk) et non depuis des portails de téléchargement, car des versions falsifiées de PuTTY avec vol de mot de passe intégré ont circulé à plusieurs reprises par le passé.

Le déroulé : dans Host Name (or IP address), vous saisissez l'IP, dans Port le 22, comme type de connexion SSH, puis Open. Si vous voulez conserver la connexion, écrivez d'abord un nom dans Saved Sessions et cliquez sur Save. PuTTY ne demande le nom d'utilisateur qu'une fois la fenêtre ouverte, à moins que vous ne le renseigniez sous Connection, Data, Auto-login username.

Lors du premier établissement de connexion, la fenêtre PuTTY Security Alert apparaît et signale que la clé d'hôte n'est pas en cache. Elle affiche la même empreinte SHA256 qu'OpenSSH, vous pouvez donc comparer les deux à l'identique. Accept enregistre la clé durablement, Connect Once se connecte une seule fois sans rien enregistrer, Cancel annule.

Différence importante avec OpenSSH : PuTTY n'a pas de fichier known_hosts. Les clés atterrissent dans le registre, sous HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys. Si vous voulez y faire le ménage après une réinstallation de votre serveur, ouvrez regedit et supprimez l'entrée correspondante. Autre piège : PuTTY utilise son propre format de clé (.ppk). Une clé OpenSSH doit d'abord être convertie avec PuTTYgen via Conversions, Import key avant que PuTTY puisse l'utiliser.

Transférer des fichiers avec scp et sftp

scp copie des fichiers comme cp, mais à travers le réseau. Pour envoyer un fichier :

scp backup.tar.gz root@203.0.113.10:/root/

Pour récupérer un fichier (le point final signifie : dans le répertoire courant) :

scp root@203.0.113.10:/var/log/syslog .

Un répertoire entier, puis avec un port différent :

scp -r website root@203.0.113.10:/var/www/
scp -P 2222 backup.tar.gz root@203.0.113.10:/root/

sftp est la variante interactive, pratique quand vous voulez d'abord regarder ce qui se trouve où :

sftp root@203.0.113.10

Ensuite, vous travaillez avec ls, cd, get fichier, put fichier côté distant, et avec lls, lcd sur votre propre machine. bye met fin à la session. Les deux programmes existent aussi sous Windows, ils font partie de la même installation. PuTTY apporte ses propres équivalents avec pscp et psftp ; si vous préférez une interface graphique, prenez WinSCP.

Et voici la différence sur laquelle beaucoup trébuchent : depuis OpenSSH 9.0, scp ne transfère plus en interne via l'ancien protocole SCP, mais via SFTP. Cela concerne Debian 13, Debian 12 et Ubuntu 24.04. Ubuntu 22.04, avec OpenSSH 8.9, utilise encore l'ancienne méthode. En pratique, cela se remarque à deux endroits. Les caractères génériques comme *.log dans un chemin distant sont interprétés autrement, et si l'hôte en face ne propose pas SFTP (des équipements réseau ou un chroot restreint, par exemple), le transfert s'interrompt avec :

subsystem request failed on channel 0
scp: Connection closed

La solution de secours est scp -O, qui force l'ancien protocole. La solution propre consiste à activer sur le serveur la ligne Subsystem sftp /usr/lib/openssh/sftp-server dans /etc/ssh/sshd_config. Sous Debian et Ubuntu, le paquet nécessaire openssh-sftp-server est installé comme dépendance de openssh-server : il ne manque donc que dans des installations assemblées de façon très particulière.

L'avertissement known_hosts après une réinstallation

Vous réinstallez votre serveur, vous vous connectez, et au lieu de l'invite de commande apparaît un mur de points d'exclamation :

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!      @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
Offending ED25519 key in /home/tom/.ssh/known_hosts:7
Host key for 203.0.113.10 has changed and you have requested strict checking.
Host key verification failed.

Ce n'est pas un défaut, c'est exactement la fonction pour laquelle vous aviez tapé yes la première fois. Lors d'une réinstallation, le serveur génère de nouvelles clés d'hôte et l'ancienne entrée ne correspond plus. Le même message apparaît d'ailleurs quand la même adresse IP a été réattribuée à un autre client, ou quand vous avez démarré une copie du serveur.

Avant de supprimer l'entrée, réfléchissez un instant : venez-vous vraiment de réinstaller ? Si oui, retirez l'ancienne ligne :

ssh-keygen -R 203.0.113.10

Avec un port différent, l'entrée s'écrit entre crochets, sinon la commande ne trouve rien :

ssh-keygen -R "[203.0.113.10]:2222"

Pour savoir si une entrée existe tout court, utilisez ssh-keygen -F 203.0.113.10. Regarder dans un éditeur de texte n'apporte généralement pas grand-chose, car Debian et Ubuntu enregistrent par défaut les noms d'hôtes de known_hosts sous forme de hash. Vous ne pouvez donc pas y faire de recherche, d'où les deux commandes ci-dessus.

À la tentative de connexion suivante, SSH redemande l'empreinte. C'est le moment de la contrôler à nouveau via la console de l'espace client, au lieu de taper yes par réflexe. Cette seconde chance est précisément le sens de tout cet avertissement.

Sous Windows, ssh-keygen -R fonctionne de la même manière dans PowerShell. Si vous utilisez PuTTY, supprimez plutôt l'entrée du registre, ou confirmez dans la fenêtre WARNING - POTENTIAL SECURITY BREACH! avec Accept que la nouvelle clé doit être enregistrée.

Les messages d'erreur mot pour mot, et ce qui se cache derrière

D'expérience, les messages suivants couvrent la grande majorité des cas.

• Connection refused : la connexion est bien arrivée jusqu'au serveur, mais personne n'écoute sur ce port. Soit le service SSH ne tourne pas, soit il écoute ailleurs. Depuis la console, vérifiez avec systemctl status ssh et ss -tlnp si le port 22 est occupé.
• Connection timed out : aucune réponse n'est arrivée. Typique d'une IP erronée, d'un serveur éteint ou d'un pare-feu qui jette les paquets au lieu de les rejeter. Vérifiez l'adresse IP caractère par caractère, ainsi que les règles du pare-feu.
• Permission denied, please try again. : le nom d'utilisateur ou le mot de passe ne correspond pas. La cause la plus fréquente est un mauvais utilisateur, par exemple root au lieu d'ubuntu ou l'inverse.
• Permission denied (publickey). : le serveur n'accepte aucun mot de passe, uniquement des clés. C'est le réglage par défaut de beaucoup d'images cloud. Soit vous y déposez votre clé publique, soit vous autorisez temporairement PasswordAuthentication yes depuis la console.
• Too many authentication failures : votre agent propose trop de clés à la suite et le serveur coupe avant la bonne. Remède : ssh -o IdentitiesOnly=yes -i ~/.ssh/ma_cle root@203.0.113.10.
• WARNING: UNPROTECTED PRIVATE KEY FILE! accompagné de Permissions 0644 for ... are too open : la clé privée est lisible par d'autres et se retrouve donc ignorée. Sous Linux et macOS, un chmod 600 sur le fichier de clé règle le problème, sous Windows c'est la commande icacls vue plus haut.
• Bad owner or permissions on ~/.ssh/config : même cause, mais pour le fichier de configuration. chmod 600 ~/.ssh/config.
• kex_exchange_identification: read: Connection reset by peer : la connexion a été coupée en plein échange initial. En pratique, il s'agit presque toujours d'un blocage automatique après plusieurs échecs, par exemple par fail2ban. Attendez la fin du blocage ou levez-le depuis la console avec fail2ban-client unban ADRESSE_IP.
• no matching host key type found. Their offer: ssh-rsa : le serveur ne propose que des clés RSA signées en SHA-1. Depuis OpenSSH 8.8, elles sont refusées, ce qui concerne les quatre systèmes traités ici en tant que clients. La bonne réponse est de mettre à jour le vieux serveur, pas d'affaiblir le client.
• client_loop: send disconnect: Broken pipe : la session s'est endormie et un pare-feu ou un routeur l'a nettoyée. Inscrivez dans ~/.ssh/config la ligne ServerAliveInterval 60, et la liaison reste au chaud.

Règle de base pour toute intervention sur la configuration SSH : gardez une session fonctionnelle ouverte pendant que vous testez. Un redémarrage du service SSH n'éjecte pas les connexions existantes. Si vous vous enfermez dehors avec une configuration erronée, vous revenez par cette seconde session ou par la console de l'espace client.

Différences entre Debian 13, Debian 12, Ubuntu 24.04 et 22.04

Pour le simple établissement de la connexion, les quatre se comportent de la même façon. Dès que vous modifiez quelque chose sur le serveur, ils divergent.

Activation par socket au lieu d'un service permanent

Depuis la version 22.10, Ubuntu ne démarre plus le service SSH en permanence, mais seulement à la première connexion entrante. C'est ssh.socket qui s'en charge, pas ssh.service. Cela vaut pour Ubuntu 24.04 et, sur les systèmes fraîchement installés, pour Debian 13 également. Debian 12 utilise encore le service permanent classique.

Deux conséquences. Premièrement, un Port 2222 dans /etc/ssh/sshd_config n'y change absolument rien, puisque ce n'est plus sshd qui écoute sur le port, mais systemd. Le port doit alors aller dans un fichier complémentaire que vous créez avec systemctl edit ssh.socket, avec un ListenStream= vide pour réinitialiser la valeur par défaut et une seconde ligne ListenStream=2222. Deuxièmement, systemctl reload ssh peut échouer avec fatal: Cannot bind any address sur les systèmes Debian 13 fraîchement installés. Dans ce cas, utilisez systemctl restart ssh.service ou désactivez complètement l'activation par socket avec systemctl disable --now ssh.socket.

Algorithmes et héritages du passé

Debian 13 embarque OpenSSH 10.0 et ne connaît plus du tout les clés DSA, pas même via une option de compatibilité. Si vous utilisez encore une clé très ancienne, générez-en une nouvelle au préalable. Les clients très récents (macOS 26.3 et plus, avec OpenSSH 10.1 ou supérieur) affichent en outre un avis quand le serveur ne propose pas d'échange de clés résistant au quantique :

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.

C'est un avertissement, pas une erreur, et la connexion s'établit malgré tout. Il disparaît dès que le serveur est suffisamment récent. Debian 12 et Ubuntu 24.04 satisfont à cette exigence, contrairement à Ubuntu 22.04 avec OpenSSH 8.9 dans sa configuration par défaut.

Un mot sur les versions plus anciennes

Debian 10 n'est plus maintenu depuis juin 2024, Ubuntu 20.04 depuis mai 2025. Ni l'un ni l'autre ne reçoit encore de mises à jour de sécurité pour OpenSSH. Un serveur joignable en SSH depuis Internet ne devrait plus tourner là-dessus.

Moins de saisie grâce à ~/.ssh/config

Dès que vous gérez plus d'un serveur, le fichier de configuration devient rentable. Créez-le et posez les droits, sinon SSH le refuse :

mkdir -p ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/config
chmod 600 ~/.ssh/config

Une entrée y ressemble à ceci :

Host web1
    HostName 203.0.113.10
    User root
    Port 2222
    ServerAliveInterval 60

Ensuite, ssh web1 suffit, et scp fichier web1:/root/ fonctionne également. Le client Windows comprend le même fichier, il se trouve là-bas sous %USERPROFILE%\.ssh\config.

Vous n'avez pas besoin de deviner si votre bloc s'applique vraiment. ssh -G affiche la configuration définitive sans établir de connexion :

ssh -G localhost

Remplacez localhost par votre nom court, et vous verrez noir sur blanc, dans les lignes hostname, user et port, ce que SSH va utiliser. Une faute de frappe dans le nom du Host se repère ainsi en deux secondes, au lieu de vingt minutes de recherche.

Comment savoir que cela a vraiment fonctionné

Une invite de commande qui s'affiche n'est pas encore une preuve. Avec plusieurs fenêtres ouvertes, plus d'un administrateur a déjà lancé un rm sur le mauvais serveur. Quatre commandes courtes lèvent le doute :

hostname
id
cat /etc/os-release
uptime

hostname doit afficher le nom de votre serveur, pas celui de votre ordinateur portable. id affiche uid=0(root) si vous travaillez en tant que root. cat /etc/os-release donne la distribution et la version, par exemple Debian GNU/Linux 13 (trixie) ou Ubuntu 24.04.3 LTS. Et uptime correspond à la durée de fonctionnement d'un serveur, pas à celle d'un poste de travail que l'on éteint chaque soir.

Le test le plus rapide pour savoir si vous êtes vraiment en SSH et non dans un terminal local :

echo $SSH_CONNECTION

Si une ligne apparaît avec quatre valeurs (votre IP, votre port source, l'IP du serveur, le port de destination), vous êtes connecté. Si elle reste vide, vous tapez en ce moment sur votre propre machine. La session se termine avec exit ou la combinaison de touches Ctrl et D.

La suite

L'étape suivante qui a du sens est le passage des mots de passe aux clés. Une clé SSH ne se devine pas, et vous pouvez ensuite désactiver complètement l'authentification par mot de passe, ce qui fait tomber dans le vide la plus grande partie des tentatives d'attaque automatisées. La marche à suivre est décrite dans Mettre en place l'authentification par clé SSH. Viennent ensuite le pare-feu et le blocage automatique, décrits dans Sécuriser le serveur après l'installation.

Pour débuter, retenez ceci : une fois que vous êtes entré, que vous avez vérifié l'empreinte et que vous savez comment revenir après une réinstallation, le plus difficile est fait. Tout le reste se passe dans une fenêtre que vous pouvez ouvrir dès maintenant.