Aller au contenu principal

Le lancement de ma session SSH échoue

Les sessions SSH acheminées via VaultPAM reposent sur la capacité du connecteur à atteindre l'hôte cible sur le port TCP 22 (ou un port SSH personnalisé). Lorsqu'une session ne parvient pas à s'ouvrir, l'une des cinq causes racines en est presque toujours responsable. Examinez-les dans l'ordre indiqué ici — les problèmes de connecteur et de réseau sont bien plus fréquents que les problèmes d'identifiants ou de clé.

Symptômes

  • Cliquer sur Lancer la session affiche un indicateur de chargement, puis une bannière d'erreur.
  • La fenêtre de session s'ouvre brièvement, puis se ferme avec un message tel que :
    • SSH connection refused
    • Host unreachable
    • Authentication failed
    • Host key verification failed
    • Permission denied (publickey)
  • La session n'apparaît jamais dans la vue Sessions actives.

Causes

1. Le connecteur est hors ligne

Le connecteur qui achemine vers l'hôte cible doit être En ligne. S'il est Hors ligne, Dégradé ou Récupération requise, chaque tentative de session via celui-ci échouera.

Vérification : Ouvrez Connecteurs dans la barre latérale. Repérez le connecteur affecté au coffre-fort cible. Confirmez que la colonne de statut affiche En ligne.

Correction : Suivez le guide Mon connecteur est hors ligne.

2. Le port 22 est bloqué entre le connecteur et la cible

La machine du connecteur doit pouvoir atteindre l'hôte cible sur le port SSH (22 par défaut). Une règle de pare-feu, un groupe de sécurité ou un pare-feu local à l'hôte (par exemple ufw, le Pare-feu Windows) peut bloquer la connexion.

Vérification : Depuis la machine du connecteur, exécutez :

nc -zv <target-host> 22

ou

ssh -v <username>@<target-host>

Une réponse Connection refused ou un dépassement de délai confirme un blocage réseau.

Correction : Mettez à jour le pare-feu ou le groupe de sécurité pour autoriser le TCP 22 depuis l'adresse IP du connecteur vers la cible. Si la cible utilise un port SSH non standard, vérifiez que le port correct est configuré dans les paramètres du coffre-fort : Coffres-forts → choisir le coffre-fort → Modifier → Paramètres de connexion → Port.

3. Nom d'utilisateur incorrect

Le nom d'utilisateur utilisé pour la connexion SSH doit exister sur l'hôte cible et correspondre exactement (les noms d'utilisateur Linux sont sensibles à la casse).

Vérification : Dans Coffres-forts → choisir le coffre-fort → Modifier → Identifiants, confirmez que le nom d'utilisateur est correct. Erreurs courantes : root au lieu d'ubuntu, admin au lieu d'administrator, ou une valeur par défaut résiduelle issue d'un modèle.

Correction : Mettez à jour l'enregistrement d'identifiant pour utiliser le nom d'utilisateur correct.

4. Non-concordance de la clé d'hôte

VaultPAM enregistre la clé d'hôte SSH lors de la première connexion. Si l'hôte cible a été reconstruit et que ses clés de serveur SSH ont changé (par exemple, après une réinstallation du système d'exploitation), VaultPAM refusera de se connecter pour se protéger contre les attaques de l'intercepteur (man-in-the-middle).

Symptômes : Le message d'erreur contient Host key verification failed ou REMOTE HOST IDENTIFICATION HAS CHANGED.

Vérification : Ouvrez Coffres-forts → choisir le coffre-fort → Modifier → Paramètres de connexion. Si une empreinte de clé d'hôte stockée est visible, comparez-la à la clé d'hôte actuelle en exécutant sur la machine cible :

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

Correction : Si le changement de clé est attendu (reconstruction légitime), cliquez sur Réinitialiser la clé d'hôte dans les paramètres de connexion du coffre-fort. VaultPAM acceptera la nouvelle clé lors de la prochaine tentative de connexion et la stockera pour les vérifications ultérieures.

5. Clé SSH manquante ou rejetée

Si le coffre-fort est configuré pour utiliser l'authentification par clé publique plutôt que l'emprunt de mot de passe (checkout), le connecteur doit avoir accès à une clé privée autorisée sur l'hôte cible.

Vérification : Dans Coffres-forts → choisir le coffre-fort → Modifier → Identifiants, confirmez que le type d'identifiant est défini sur Clé SSH et qu'une clé est jointe. Vérifiez que la clé publique correspondante figure dans ~/.ssh/authorized_keys sur l'hôte cible pour l'utilisateur configuré.

Correction : Téléversez la clé privée correcte dans l'enregistrement d'identifiant, ou ajoutez la clé publique du connecteur à authorized_keys sur l'hôte cible.

Étapes de résolution

  1. Ouvrez Connecteurs dans la barre latérale et confirmez que le connecteur affecté au coffre-fort cible affiche En ligne. Si ce n'est pas le cas, suivez Mon connecteur est hors ligne avant de continuer.
  2. Depuis la machine du connecteur, exécutez nc -zv <target-host> 22 pour confirmer que le port TCP 22 est accessible. S'il est bloqué, mettez à jour la règle de pare-feu ou de groupe de sécurité concernée.
  3. Ouvrez Coffres-forts → choisir le coffre-fort → Modifier → Identifiants et vérifiez le nom d'utilisateur. Corrigez-le s'il ne correspond pas au compte de l'hôte cible.
  4. Si l'erreur mentionne une non-concordance de clé d'hôte, ouvrez Coffres-forts → choisir le coffre-fort → Modifier → Paramètres de connexion et cliquez sur Réinitialiser la clé d'hôte, puis réessayez la session.
  5. Si le coffre-fort utilise l'authentification par clé SSH, confirmez qu'une clé privée est jointe à l'enregistrement d'identifiant et que la clé publique correspondante figure dans ~/.ssh/authorized_keys sur l'hôte cible.
  6. Après chaque modification, réessayez la session en cliquant sur Lancer la session sur le coffre-fort.

Procédure d'escalade

Si vous avez examiné les cinq causes et que la session échoue toujours :

  1. Notez le message d'erreur exact affiché dans la bannière de session.
  2. Sur la machine du connecteur, collectez les 100 dernières lignes du journal du connecteur :
    • Docker : docker logs -n 100 vaultpam-connector
    • systemd : journalctl -u vaultpam-connector -n 100
  3. Exécutez nc -zv <target-host> 22 depuis la machine du connecteur et incluez la sortie.
  4. Ouvrez un ticket de support en y joignant : le nom du connecteur, l'hôte cible (masqué s'il est sensible), le message d'erreur exact, la sortie du journal et le résultat de nc.

Articles connexes