Se connecter en SSH à son VPS

2 min de lecture07 novembre 2026

SSH ouvre un terminal chiffré sur votre VPS. À la première connexion, votre client reçoit une empreinte de clé d'hôte et doit décider s'il fait confiance au serveur, puis vous vous authentifiez par mot de passe ou par clé. Les deux étapes sont distinctes : confondre l'une et l'autre explique la plupart des blocages de départ.

Se connecter avec l'adresse IPv6

Récupérez l'adresse dans le panneau VPS, puis lancez :

Bash
ssh root@VOTRE_IPV6

OpenSSH accepte l'adresse IPv6 brute après l'arobase. En revanche, scp, rsync et les URL exigent des crochets :

Bash
scp fichier.tar.gz root@[VOTRE_IPV6]:/root/

Si le port a été changé, ajoutez -p 2222 (la casse compte : -p pour ssh, -P pour scp). Pour diagnostiquer, ssh -v root@VOTRE_IPV6 affiche chaque étape de la négociation.

Vérifier l'empreinte de l'hôte

Au premier échange, le client affiche une empreinte SHA256:... et propose d'enregistrer la clé. Ne validez pas à l'aveugle : comparez-la avec celle du serveur. Ouvrez la console du panneau et exécutez :

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

La sortie doit correspondre exactement. En cas de réinstallation, l'empreinte change : c'est normal, mais vérifiez d'abord par la console que personne n'a remplacé la machine. Après confirmation, retirez l'ancienne entrée avec ssh-keygen -R VOTRE_IPV6.

Mot de passe ou clé

Le mot de passe root fourni par NeoHeberg suffit pour la première connexion. Il est long et aléatoire : collez-le dans le terminal, il ne s'affiche pas à la frappe. Une clé SSH est plus sûre et plus confortable ; sa mise en place est décrite dans le guide des clés SSH. Tant que PermitRootLogin autorise le mot de passe, une clé compromise reste moins grave qu'un mot de passe réutilisé ailleurs.

Erreurs courantes

Message Cause probable
Connection timed out Pare-feu, route absente ou service arrêté
Connection refused sshd arrêté ou port différent
Permission denied (publickey,password) Identifiants refusés ou root interdit
Host key verification failed Empreinte changée, souvent après réinstallation
Too many authentication failures Trop de clés proposées par l'agent

Pour le dernier cas, forcez la bonne clé avec ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes root@VOTRE_IPV6.

Après la première connexion

Vérifiez l'identité et le système :

Bash
whoami
cat /etc/os-release
ss -tlnp | grep :22

whoami doit répondre root, os-release doit afficher la distribution attendue et ss doit montrer le port 22 en écoute. Si ce n'est pas le cas, la console reste disponible pour corriger sshd_config avant de redémarrer le service avec systemctl restart ssh.

Publicité

Cet article vous a-t-il aidé ?

À lire aussi