Connexion à un serveur via SSH¶

Dans cet article

• Connexion à un serveur via SSH depuis Linux
• Connexion à un serveur via SSH depuis Windows
• Dépannage de la connexion SSH

Connexion à un serveur via SSH depuis Linux¶

Pour vous connecter à votre serveur via SSH depuis Linux, suivez ces étapes :

1. Vérifiez l'adresse IP du serveur. Assurez-vous de connaître l'adresse IP du serveur. Si vous ne la connaissez pas, vous pouvez la trouver dans le Invapi Control Panel.

2. Installez un client SSH (si nécessaire). Un client SSH est généralement déjà installé par défaut sur la plupart des distributions Linux. Pour vérifier cela, ouvrez un terminal et exécutez la commande :

   ssh --version
   

   Si le client est installé, vous verrez la version du programme.

   Si le client SSH n'est pas installé, installez-le en utilisant le gestionnaire de paquets de votre distribution :

   • Pour Ubuntu/Debian :

     sudo apt update
     sudo apt install openssh-client
     

   • Pour CentOS/RHEL :

     sudo yum install openssh-clients
     

3. Connectez-vous au serveur. Ouvrez un terminal et saisissez la commande suivante :

   ssh <username>@<server IP address>
   

   Par exemple :

   ssh [email protected]
   

4. Saisissez votre mot de passe. Après la connexion, le système vous demandera de saisir le mot de passe de l'utilisateur spécifié. L'identifiant et le mot de passe du serveur vous sont envoyés par e-mail lors de la livraison.

Connexion à un serveur via SSH depuis Windows¶

1. Vérifiez l'adresse IP du serveur. Assurez-vous de connaître l'adresse IP du serveur. Si ce n'est pas le cas, vous pouvez la trouver dans l'Invapi Control Panel sur le site HOSTKEY.com à l'adresse https://invapi.hostkey.com.

2. Sous Windows 11, il existe plusieurs façons de se connecter à un serveur via SSH :

Utilisation d'OpenSSH (application intégrée)¶

• À partir de la mise à jour d'octobre 2018 de Windows 10, le client SSH est inclus par défaut. Pour vérifier cela, lancez PowerShell et exécutez :

  ssh
  

  Si le client est installé, vous verrez les options de sortie pour son utilisation.

• Si le client SSH n'est pas installé, activez-le via Settings :

  1. Allez dans **Settings** > **System** > **Additional components**.
  
  2. Recherchez `OpenSSH Client` et installez-le.
  

• Connectez-vous au serveur. Ouvrez PowerShell et saisissez la commande suivante :

  ssh <username>@<server IP address>
  

  Par exemple :

  ssh root@192.168.0.100
  

• Saisissez votre mot de passe. Après la connexion, le système vous demandera de saisir le mot de passe de l'utilisateur spécifié. L'identifiant et le mot de passe du serveur vous sont envoyés par e-mail lors de la livraison.

Utilisation de PuTTY (client alternatif) :¶

• Téléchargez PuTTY sur le site officiel https://www.putty.org.

• Lancez PuTTY et saisissez l'adresse IP du serveur dans le champ "Host Name (or IP address)".

• Spécifiez le type de connexion comme SSH et cliquez sur Open.

• Connectez-vous au serveur :

  • Saisissez l'adresse IP du serveur dans le champ Host Name (or IP address).

  • Spécifiez le port 22 pour SSH s'il a été modifié.

  • Cliquez sur Open. Dans la fenêtre qui s'ouvre, saisissez votre nom d'utilisateur et votre mot de passe.

• Saisissez votre mot de passe. Après la connexion, le système vous demandera de saisir le mot de passe de l'utilisateur spécifié. L'identifiant et le mot de passe du serveur vous sont envoyés par e-mail lors de la livraison.

Dépannage de la connexion SSH¶

En effectuant ce diagnostic, vous pourrez déterminer où la connexion SSH est perdue : de votre côté, sur le serveur (sshd, pare-feu, paramètres), ou du côté de votre fournisseur. Effectuez les étapes dans l'ordre et enregistrez la sortie des commandes — elle sera requise par le support.

Étape 1. Vérification depuis votre ordinateur¶

L'objectif est de déterminer si le serveur est joignable et si le port 22 répond. Ces commandes sont exécutées sur l'ordinateur depuis lequel vous vous connectez.

1. Disponibilité réseau du serveur

   ping -c 4 SERVER_IP
   

   L'absence de réponse ne signifie pas nécessairement une erreur : l'ICMP est souvent bloqué par un pare-feu. Le test principal est l'étape suivante.

2. Le port 22 répond-il ?

   nc -vz -w 5 SERVER_IP 22
   
   # si nc n'est pas installé :
   timeout 5 bash -c '</dev/tcp/SERVER_IP/22' && echo OPEN || echo CLOSED
   

   Résultat	Signification
   succeeded / open	Le port est ouvert, le réseau fonctionne — le problème vient de l'authentification ou des paramètres de sshd (Étape 4)
   Connection refused	Le serveur est joignable, mais rien n'écoute sur le port 22 ou le pare-feu envoie un REJECT (Étapes 2–3)
   timed out	Les paquets sont perdus : pare-feu DROP, filtre du fournisseur ou blocage sur la route (Étapes 3 et 5)
   No route to host	Aucune route vers le serveur ou le serveur est éteint (vérifiez son statut dans le panneau)

3. Vérification précise via nmap

   Affiche l'état du port et ce qui est en cours d'exécution sur celui-ci. Installation : sudo apt install nmap ou sudo dnf install nmap.

   # état du port 22 et version du serveur SSH
   sudo nmap -Pn -sV -p 22 SERVER_IP
   
   # avec la raison de l'état et la route vers le serveur
   sudo nmap -Pn -p 22 --reason --traceroute SERVER_IP
   
   # comparer le 22 avec d'autres ports (filtre uniquement le 22 ou tout ?)
   sudo nmap -Pn -p 22,80,443,2222 --reason SERVER_IP
   
   # algorithmes SSH – si le script s'exécute, l'échange de clés fonctionne
   nmap -Pn -p 22 --script ssh2-enum-algos SERVER_IP
   

   -Pn est requis pour que nmap ne suppose pas que le serveur est hors ligne si le ping est bloqué.

   État nmap	Signification
   open (reason syn-ack)	Le port est ouvert, sshd répond ; -sV devrait afficher une version OpenSSH
   closed (reason reset)	Le serveur est joignable, mais sshd n'écoute pas sur le port (Étape 2)
   filtered (reason no-response)	Les paquets sont perdus : pare-feu DROP ou blocage sur la route (Étapes 3 et 5)
   filtered (reason admin-prohibited)	Le pare-feu répond par un rejet — règle REJECT sur le serveur ou chez le fournisseur (Étape 3)
   open, mais -sV ne montre aucune version ou tcpwrapped	La connexion TCP passe, mais le banner SSH n'est pas reçu — TCP Wrappers, fail2ban ou DPI (Étapes 4–5)

   Si les réponses de --traceroute s'arrêtent aux nœuds de votre fournisseur alors que les ports 80/443 restent ouverts, c'est un signe fort d'un filtrage spécifique sur le port 22. Enregistrez la sortie pour le support : ajoutez -oN nmap.txt à la commande.

4. Journal de connexion détaillé

   Montre à quelle étape la connexion est interrompue :

   ssh -vvv -o ConnectTimeout=10 user@SERVER_IP 2>&1 | tee ssh_debug.log
   

   • Blocage à Connecting to — problème de réseau.
   • Déconnexion après Connection established (ex: à SSH2_MSG_KEXINIT ou Connection reset by peer) — signe typique d'un filtrage DPI ou de fail2ban.
   • Permission denied — le réseau fonctionne, mais la clé ou le mot de passe est incorrect.

5. Route vers le serveur spécifiquement via le port TCP 22

   sudo traceroute -T -p 22 SERVER_IP
   
   # ou un résumé de la perte de paquets :
   sudo mtr -T -P 22 -r -c 50 SERVER_IP > mtr.txt
   

   Observez à quel nœud les réponses s'arrêtent. Une déconnexion au sein du réseau de votre fournisseur indique un filtrage sur la route plutôt qu'un problème avec le serveur.

6. Écarter votre propre réseau

   Répétez l'étape 2 en utilisant un partage de connexion mobile et vérifiez si le port 22 sortant est bloqué par votre pare-feu professionnel/d'entreprise.

Étape 2. Le serveur SSH est-il en cours d'exécution ?¶

Effectuée sur le serveur (via la console web de l'hébergement). Sous Debian/Ubuntu, le service s'appelle ssh ; sous CentOS/RHEL/Alma/Rocky, il s'appelle sshd.

1. État du service

   systemctl status ssh || systemctl status sshd
   

   Il doit être active (running). S'il est inactive ou failed, démarrez le service et activez-le pour qu'il démarre au démarrage :

   sudo systemctl enable --now ssh   # ou sshd
   

   Si le service ne parvient pas à démarrer, la raison sera listée dans les journaux.

2. Paquet non installé

   Erreur Unit ssh.service could not be found :

   sudo apt install openssh-server   # Debian/Ubuntu
   sudo dnf install openssh-server   # CentOS/RHEL/Alma/Rocky
   

3. Sur quel port et quelle adresse sshd écoute-t-il ?

   sudo ss -tlnp | grep -E 'sshd|:22'
   

   Sortie	Signification
   0.0.0.0:22 ou [::]:22	Tout est correct ; écoute sur toutes les interfaces
   127.0.0.1:22	Écoute uniquement en local — corrigez ListenAddress (Étape 4)
   Autre port, ex: :2222	Connectez-vous en utilisant ce port : ssh -p 2222 user@SERVER_IP
   Vide	sshd n'est pas en cours d'exécution ou ne peut pas se lier au port — voir les journaux ci-dessus

4. Ubuntu 22.10+ et activation par socket

   Dans ces versions, le port est défini dans ssh.socket ainsi que dans sshd_config. Pour vérifier :

   systemctl status ssh.socket
   

   Après avoir modifié le port, exécutez :

   sudo systemctl daemon-reload && sudo systemctl restart ssh.socket
   

5. Test depuis le serveur lui-même

   ssh -v localhost
   

   Si cela fonctionne localement mais pas de l'extérieur, le problème vient du pare-feu ou du réseau (Étapes 3 et 5).

Étape 3. Pare-feu du serveur¶

Généralement, l'un des trois pare-feu suivants est actif sur le serveur : ufw (Ubuntu), firewalld (CentOS/RHEL), ou iptables/nftables brut. Vérifiez les trois — parfois deux sont actifs simultanément.

ufw

sudo ufw status verbose

# si 22/tcp n'est pas dans la liste ALLOW :
sudo ufw allow 22/tcp

firewalld

sudo firewall-cmd --state
sudo firewall-cmd --list-all

# si ssh n'est pas dans les services :
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

iptables / nftables

sudo iptables -L INPUT -n -v --line-numbers
sudo nft list ruleset

Recherchez des règles avec dpt:22 ou tcp dport 22 et l'action DROP / REJECT, ainsi qu'une policy DROP sans règle d'autorisation pour le port 22. Faites attention aux règles restreignant l'accès par source (-s) ou par pays (en utilisant des modules geoip ou des listes ipset) : à cause de celles-ci, le serveur pourrait être accessible de partout sauf de votre pays.

Pour autoriser temporairement le SSH au début de la chaîne (jusqu'au redémarrage) :

sudo iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT

Si la connexion fonctionne après cela, la cause est identifiée ; enregistrez la règle via votre pare-feu (ufw/firewalld) ou en utilisant iptables-save.

Étape 4. Paramètres sshd et outils de sécurité¶

Si le port est ouvert mais que la connexion est interrompue ou que l'authentification échoue, vérifiez votre configuration et les éventuels blocages.

1. Configuration finale de sshd

   En tenant compte des fichiers dans sshd_config.d/ :

   sudo sshd -T | grep -Ei '^(port|listenaddress|permitrootlogin|passwordauthentication|pubkeyauthentication|allowusers|allowgroups|denyusers|maxstartups)'
   

   Vérifiez :

   • port 22;
   • listenaddress 0.0.0.0 (pas 127.0.0.1);
   • que votre utilisateur est dans allowusers, si ce paramètre est défini ;
   • permitrootlogin et passwordauthentication — assurez-vous qu'ils sont réglés sur les valeurs requises.

2. Vérification de la syntaxe avant redémarrage

   Après toute modification de /etc/ssh/sshd_config, vérifiez toujours la syntaxe avant de redémarrer :

   sudo sshd -t && sudo systemctl restart ssh   # ou sshd
   

3. fail2ban

   Il peut avoir bloqué votre IP après des tentatives de connexion échouées :

   sudo fail2ban-client status sshd
   
   # pour débloquer votre IP :
   sudo fail2ban-client set sshd unbanip YOUR_IP
   

   Vous pouvez trouver votre IP externe depuis votre machine cliente en utilisant la commande curl -4 ifconfig.me. De même, vérifiez CrowdSec ou sshguard s'ils sont installés.

4. TCP Wrappers (sur les systèmes plus anciens)

   cat /etc/hosts.allow /etc/hosts.deny 2>/dev/null
   

   Une ligne comme sshd: ALL dans hosts.deny bloque tout le monde qui n'est pas spécifié dans hosts.allow.

5. Ce que le serveur voit lors de votre tentative de connexion

   Exécutez ceci sur le serveur, puis tentez de vous connecter depuis le client :

   sudo journalctl -u ssh -u sshd -f
   
   # dans une deuxième fenêtre – vérifiez si les paquets atteignent le serveur :
   sudo tcpdump -ni any tcp port 22 and host YOUR_IP
   

   • Si tcpdump ne montre rien — les paquets n'atteignent pas le serveur ; le problème se situe sur le chemin réseau (Étape 5).
   • Si les paquets arrivent mais que le journal sshd est vide — ils sont rejetés par le pare-feu du serveur (Étape 3).

Étape 5. Indisponibilité spécifiquement depuis votre pays¶

Si tout est correct sur le serveur (Étapes 2–4) mais que les paquets de votre pays n'arrivent pas, vous devez comparer la disponibilité du port depuis votre pays par rapport à d'autres pays.

1. Vérifiez le port depuis des emplacements externes

   Utilisez le service check-host.net → onglet TCP port, saisissez SERVER_IP:22. Vérifiez les résultats pour votre pays et les nœuds internationaux.

   Depuis votre pays	Depuis d'autres pays	Conclusion
   Échec	Fonctionne	Filtrage de routage depuis votre pays ou géoblocage côté serveur/hébergeur
   Échec	Échec	Problème sur le serveur — retour aux Étapes 2–4
   Fonctionne	Fonctionne	Problème avec votre FAI ou votre réseau local

2. Comparez les fournisseurs dans votre pays

   L'internet domestique et les opérateurs mobiles se comportent souvent différemment. Si cela fonctionne via l'un mais pas l'autre, le blocage se situe du côté du fournisseur spécifique.

3. Vérifiez si c'est spécifiquement le port 22 qui est affecté

   Ajoutez temporairement un second port à /etc/ssh/sshd_config sur le serveur (la ligne Port 22 originale doit rester) :

   Port 22
   Port 2222
   

   Autorisez 2222/tcp dans votre pare-feu (Étape 3), puis exécutez :

   sudo sshd -t && sudo systemctl restart ssh
   

   Et connectez-vous :

   ssh -p 2222 user@SERVER_IP
   

   Sur les systèmes SELinux (CentOS/RHEL), effectuez cette étape supplémentaire :

   sudo semanage port -a -t ssh_port_t -p tcp 2222
   

   Si cela fonctionne sur le 2222 mais pas sur le 22, le port standard est filtré.

4. Signes de filtrage DPI

   La connexion TCP est établie (nc indique open), mais ssh -vvv s'interrompt pendant l'échange de clés ; ou la connexion fonctionne quelques secondes puis se fige. Dans ce cas, les paramètres du serveur ne sont pas la cause — veuillez envoyer les journaux au support.

Ce qu'il faut inclure dans votre message au support¶

Si le problème n'est pas résolu, envoyez-nous les éléments suivants — cela réduira le temps de diagnostic :

• L'IP du serveur et votre IP publique (curl -4 ifconfig.me), votre ville et votre FAI ;
• Le fichier nmap.txt et le résultat de nc -vz -w 5 SERVER_IP 22;
• Le fichier ssh_debug.log (Étape 1, point 4) ;
• Le fichier mtr.txt ou la sortie de traceroute -T -p 22;
• La sortie du serveur : systemctl status ssh, ss -tlnp | grep :22, et les règles du pare-feu (ufw status verbose / firewall-cmd --list-all / iptables -L INPUT -n -v);
• Un lien vers le résultat du test de port TCP de check-host.net ;
• Si la connexion fonctionne via internet mobile et sur le port 2222 (si vous l'avez testé).