Comment se connecter à votre nouveau serveur cloud en SSH
Le serveur tourne, la console affiche une adresse IP, un identifiant et un mot de passe, et il faut maintenant entrer dedans. Voici cette première connexion, avec les quelques gestes qui valent la peine avant d'installer quoi que ce soit.
Ce que la console vous donne
Ouvrez le serveur dans votre console et regardez le bloc Access. Il contient les trois éléments nécessaires : l'adresse IP, Login et Password. Deux boutons sont posés à côté. Generate new password en crée un nouveau au hasard, Set new password accepte celui que vous choisissez. Les deux s'appliquent sur le serveur en marche, servez-vous en si le mot de passe traîne dans une fenêtre de discussion.
La première connexion
Sur macOS et sur n'importe quel bureau Linux, SSH est déjà installé. Sous Windows, il fait partie du système depuis Windows 10 et Windows Server 2019, la même commande fonctionne donc dans PowerShell sans installer PuTTY :
ssh root@203.0.113.10
La première fois, SSH affiche une empreinte et demande s'il faut continuer. Cette question n'est pas une formalité : SSH vous dit qu'il n'a jamais vu cet hôte et ne peut pas se porter garant. Sur un serveur que vous venez de créer, répondez yes. La clé est enregistrée dans ~/.ssh/known_hosts et la question ne revient plus pour cette adresse.
Passez aux clés, puis refermez la porte
Les mots de passe sont réutilisés, tapés dans la mauvaise fenêtre et collés dans des tickets. Les clés, non. Générez-en une sur votre propre machine, pas sur le serveur :
ssh-keygen -t ed25519 -C "you@example.com"
ssh-copy-id root@203.0.113.10
Vérifiez ensuite que la connexion par clé fonctionne dans une deuxième fenêtre de terminal, avant de modifier quoi que ce soit. Laissez la première ouverte. Si le nouveau réglage est mauvais, c'est précisément cette session déjà ouverte qui vous servira à revenir en arrière.
Dès que la deuxième fenêtre se connecte sans mot de passe, modifiez /etc/ssh/sshd_config :
PasswordAuthentication no
PermitRootLogin prohibit-password
puis rechargez avec systemctl reload ssh sur Debian et Ubuntu, ou systemctl reload sshd sur AlmaLinux et Rocky.
Les quatre erreurs que l'on rencontre vraiment
| Ce que vous voyez | Ce que cela signifie | Quoi faire |
|---|---|---|
Permission denied (publickey) |
Le serveur n'accepte plus les mots de passe et n'a pas votre clé | Ouvrez la console KVM et vérifiez ~/.ssh/authorized_keys et sshd_config |
Connection refused |
Quelque chose a répondu : l'hôte tourne, mais rien n'écoute sur le port 22 | Console, puis systemctl status ssh - le service est arrêté ou déplacé sur un autre port |
Connection timed out |
Rien n'a répondu du tout : un pare-feu jette les paquets, l'adresse est fausse, ou le serveur est éteint | Vérifiez l'état d'alimentation dans la console, puis vos règles de pare-feu |
REMOTE HOST IDENTIFICATION HAS CHANGED |
La clé de l'hôte diffère de celle que vous aviez enregistrée | Normal après une réinstallation ou une restauration d'instantané. Supprimez l'ancienne entrée avec ssh-keygen -R 203.0.113.10 |
La distinction utile est dans les deux lignes du milieu. Refused veut dire que le serveur est joignable et que le problème est un service. Timed out veut dire que vos paquets n'ont jamais eu de réponse, donc que le problème se situe entre vous et lui.
La console est le chemin du retour
Chaque erreur de cet article vous coupe l'accès SSH, et aucune ne vous coupe l'accès au serveur. La console propose une console KVM, c'est-à-dire un écran et un clavier branchés directement sur la VM, et une console texte pour les systèmes qui la gèrent. Aucune ne passe par SSH, donc un sshd_config cassé, une règle de pare-feu qui a bloqué votre propre adresse ou une clé effacée se réparent en une minute environ.
Cela vaut la peine de le savoir avant de commencer, parce que cela déplace la limite du risque. S'enfermer dehors est ici un désagrément, pas un incident.
Les dix premières minutes
- Mettez le système à jour -
apt update && apt upgradeoudnf upgrade, avant que quoi que ce soit d'autre n'arrive sur le disque - Créez un utilisateur et laissez root de côté -
adduser you, ajoutez-le à sudo ou wheel, et connectez-vous avec lui désormais - Fixez le nom d'hôte et vérifiez l'horloge -
hostnamectl set-hostname web-01, puistimedatectl, car une heure fausse casse les certificats et les journaux - Activez les mises à jour de sécurité automatiques -
unattended-upgradessur Debian et Ubuntu,dnf-automaticailleurs - Prenez un instantané - avant la première installation, pas après la casse
En résumé
La première connexion tient en une commande. Ce qui mérite qu'on ralentisse, c'est le passage aux clés, et la règle qui le rend sûr est simple : ne fermez jamais la session qui marche avant qu'une nouvelle ait fait ses preuves. Si cela tourne mal quand même, l'accès KVM reste disponible.
Serveurs cloud en Tchéquie et au Portugal, à partir de EUR 15/mois, avec console et réinitialisation du mot de passe sur chacun : dcxv.com/data-center#cloud
