Se connecter à votre serveur en SSH
SSH (Secure Shell) est la méthode standard pour gérer un serveur Linux à distance. Il ouvre une connexion chiffrée vers le serveur pour que vous puissiez taper des commandes comme si vous étiez devant. Ce guide s’adresse à toute personne qui dispose d’un VPS (serveur privé virtuel) ou d’un serveur cloud. Il explique comment se connecter depuis Windows, macOS et Linux, configurer des clés SSH et corriger les erreurs les plus courantes.
Première connexion
Windows 10 et 11, macOS et Linux incluent tous le client OpenSSH : vous n’avez donc rien à installer. Ouvrez PowerShell ou Windows Terminal sous Windows, ou Terminal sous macOS et Linux, puis lancez :
ssh jane@203.0.113.25
Si le serveur utilise un autre port, ajoutez -p suivi du numéro de port :
ssh -p 2222 jane@203.0.113.25
Le message sur la clé d’hôte
La première fois que vous vous connectez à un serveur, SSH affiche un message comme celui-ci :
The authenticity of host '203.0.113.25 (203.0.113.25)' can't be established.
ED25519 key fingerprint is SHA256:...
Are you sure you want to continue connecting (yes/no/[fingerprint])?
L’empreinte (fingerprint) est un code court qui identifie la clé propre au serveur. Votre ordinateur ne l’a jamais vue, il vous demande donc de confirmer. Si votre fournisseur affiche l’empreinte du serveur, comparez les deux. Tapez yes pour continuer. SSH enregistre la clé dans votre fichier known_hosts et la vérifie à chaque connexion suivante.
Si SSH vous avertit plus tard que l’identification de l’hôte distant a changé (« remote host identification has changed »), arrêtez-vous et cherchez pourquoi avant de vous connecter. C’est normal après une réinstallation du serveur, mais cela peut aussi signifier que vous n’atteignez pas le serveur que vous croyez. Une fois certain que le changement est légitime, supprimez l’ancienne entrée avec ssh-keygen -R 203.0.113.25 et connectez-vous de nouveau.
Utiliser des clés SSH plutôt que des mots de passe
Une paire de clés SSH se compose de deux fichiers liés : une clé privée qui reste sur votre ordinateur, et une clé publique que vous placez sur le serveur. Le serveur vous laisse entrer uniquement si vous détenez la clé privée correspondante. Les clés sont beaucoup plus difficiles à deviner ou à voler que les mots de passe.
Créer une clé
ssh-keygen -t ed25519 -C "jane laptop"
-t ed25519 choisit un type de clé moderne et compact, et -C ajoute une étiquette pour distinguer vos clés plus tard. Appuyez sur Entrée pour accepter l’emplacement par défaut, puis définissez une phrase secrète (passphrase). Elle protège la clé privée si votre ordinateur est perdu ou volé.
Deux fichiers sont alors créés dans le dossier .ssh de votre dossier personnel : id_ed25519 (privée) et id_ed25519.pub (publique).
Ne partagez jamais votre clé privée, le fichier sans .pub : ne l’envoyez pas par e-mail et ne la téléversez nulle part. Seul le fichier .pub va sur les serveurs.
Copier la clé publique sur le serveur
Sous macOS et Linux, ssh-copy-id s’en charge en une seule étape, en utilisant votre mot de passe une dernière fois :
ssh-copy-id jane@203.0.113.25
Windows n’inclut pas ssh-copy-id. Affichez plutôt votre clé publique dans PowerShell avec Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub, copiez la ligne unique qui s’affiche, puis connectez-vous au serveur et ajoutez-la :
mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "ssh-ed25519 AAAA...your-key... jane laptop" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
authorized_keys liste les clés publiques autorisées à se connecter avec cet utilisateur. Votre fournisseur peut aussi vous permettre d’ajouter une clé publique au moment de créer le serveur.
Ouvrez un nouveau terminal et connectez-vous de nouveau. S’il vous demande la phrase secrète de votre clé au lieu du mot de passe du serveur, la clé fonctionne.
Gagner du temps avec un fichier de configuration SSH
Le fichier ~/.ssh/config enregistre les informations de connexion sous un nom court. Sous Windows, il se trouve dans C:\Users\<you>\.ssh\config. Créez-le avec un éditeur de texte :
Host myserver
HostName 203.0.113.25
User jane
Port 22
IdentityFile ~/.ssh/id_ed25519
Désormais, ssh myserver se connecte avec tous ces réglages. Les applications de transfert de fichiers compatibles SFTP peuvent généralement utiliser la même clé.
Erreurs courantes
| Erreur | Ce que cela signifie généralement | Ce qu’il faut vérifier |
|---|---|---|
Connection refused | Le serveur a été atteint, mais rien n’accepte SSH sur ce port | Que le service SSH fonctionne et que vous utilisez le bon port |
Connection timed out | Aucune réponse | L’adresse IP, que le serveur fonctionne, et qu’un pare-feu autorise le port SSH, y compris le pare-feu réseau de votre fournisseur |
Permission denied (publickey) | Le serveur n’accepte que des clés et n’a pas accepté la vôtre | Le nom d’utilisateur, que votre clé publique figure dans le fichier authorized_keys de cet utilisateur, les permissions des fichiers (700 pour ~/.ssh, 600 pour authorized_keys), et que vous présentez la bonne clé avec -i ou votre fichier de configuration |
Permission denied, please try again | Mauvais mot de passe, ou connexion par mot de passe désactivée pour cet utilisateur | Le nom d’utilisateur et le mot de passe, et si le serveur autorise la connexion par mot de passe |
Host key verification failed | L’empreinte enregistrée ne correspond pas à la clé du serveur | Voir l’avertissement sur les clés d’hôte modifiées plus haut |
Pour voir ce que fait SSH étape par étape, ajoutez -v à la commande, par exemple ssh -v jane@203.0.113.25.
Si vous vous êtes bloqué l’accès, de nombreux fournisseurs proposent une console dans le navigateur qui fonctionne sans SSH. Utilisez-la pour corriger la configuration.
Pour le détail de toutes les options, consultez la documentation OpenSSH.
Guides associés
- Sécuriser un nouveau serveur Linux
- Téléverser les fichiers de votre site en SFTP
- Hébergement web, VPS ou cloud