Meine SSH-Sitzung lässt sich nicht starten

SSH-Sitzungen, die über VaultPAM geleitet werden, sind darauf angewiesen, dass der Connector den Zielhost über den TCP-Port 22 (oder einen benutzerdefinierten SSH-Port) erreicht. Wenn sich eine Sitzung nicht öffnen lässt, ist fast immer eine von fünf Grundursachen verantwortlich. Arbeiten Sie sie in der hier aufgeführten Reihenfolge ab — Connector- und Netzwerkprobleme sind weitaus häufiger als Probleme mit Anmeldeinformationen oder Keys.

Symptome

• Beim Klicken auf Sitzung starten erscheint ein Ladekreis und anschließend ein Fehlerbanner.
• Das Sitzungsfenster öffnet sich kurz und schließt sich dann mit einer Meldung wie:
  • SSH connection refused
  • Host unreachable
  • Authentication failed
  • Host key verification failed
  • Permission denied (publickey)
• Die Sitzung erscheint nie in der Ansicht Aktive Sitzungen.

Ursachen

1. Connector ist offline

Der Connector, der zum Zielhost leitet, muss Online sein. Wenn er Offline, Degraded oder Needs recovery ist, schlägt jeder Sitzungsversuch über ihn fehl.

Prüfung: Öffnen Sie Connectors in der Seitenleiste. Suchen Sie den Connector, der dem Ziel-Safe zugewiesen ist. Vergewissern Sie sich, dass die Statusspalte Online anzeigt.

Behebung: Folgen Sie dem Runbook Mein Connector ist offline.

2. Port 22 ist zwischen dem Connector und dem Ziel blockiert

Die Connector-Maschine muss den Zielhost über den SSH-Port (Standard 22) erreichen können. Eine Firewall-Regel, eine Security-Group oder eine hostbasierte Firewall (z. B. ufw, Windows Firewall) blockiert ihn möglicherweise.

Prüfung: Führen Sie auf der Connector-Maschine Folgendes aus:

nc -zv <target-host> 22

oder

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

Eine Antwort mit Connection refused oder ein Timeout bestätigt eine Netzwerksperre.

Behebung: Aktualisieren Sie die Firewall oder die Security-Group, um TCP 22 von der IP des Connectors zum Ziel zuzulassen. Wenn das Ziel einen nicht standardmäßigen SSH-Port verwendet, überprüfen Sie, ob der korrekte Port in den Safe-Einstellungen konfiguriert ist: Safes → Safe auswählen → Bearbeiten → Verbindungseinstellungen → Port.

3. Falscher Benutzername

Der für die SSH-Verbindung verwendete Benutzername muss auf dem Zielhost vorhanden sein und genau übereinstimmen (Linux-Benutzernamen unterscheiden zwischen Groß- und Kleinschreibung).

Prüfung: Vergewissern Sie sich unter Safes → Safe auswählen → Bearbeiten → Anmeldeinformationen, dass der Benutzername korrekt ist. Häufige Fehler: root statt ubuntu, admin statt administrator oder ein übrig gebliebener Standardwert aus einer Vorlage.

Behebung: Aktualisieren Sie den Datensatz der Anmeldeinformation, sodass der korrekte Benutzername verwendet wird.

4. Host-Key-Konflikt

VaultPAM erfasst den SSH-Host-Key bei der ersten Verbindung. Wenn der Zielhost neu aufgesetzt wurde und sich seine SSH-Server-Keys geändert haben (z. B. nach einer Neuinstallation des Betriebssystems), verweigert VaultPAM die Verbindung, um sich vor Man-in-the-Middle-Angriffen zu schützen.

Symptome: Die Fehlermeldung enthält Host key verification failed oder REMOTE HOST IDENTIFICATION HAS CHANGED.

Prüfung: Öffnen Sie Safes → Safe auswählen → Bearbeiten → Verbindungseinstellungen. Wenn ein gespeicherter Host-Key-Fingerprint sichtbar ist, vergleichen Sie ihn mit dem aktuellen Host-Key, indem Sie auf der Zielmaschine Folgendes ausführen:

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

Behebung: Wenn die Key-Änderung erwartet wird (legitimes Neuaufsetzen), klicken Sie in den Safe-Verbindungseinstellungen auf Host-Key zurücksetzen. VaultPAM akzeptiert den neuen Key beim nächsten Verbindungsversuch und speichert ihn für die künftige Überprüfung.

5. Fehlender oder abgelehnter SSH-Key

Wenn der Safe so konfiguriert ist, dass er eine Public-Key-Authentifizierung anstelle eines Passwort-Checkouts verwendet, muss der Connector Zugriff auf einen privaten Key haben, der auf dem Zielhost autorisiert ist.

Prüfung: Vergewissern Sie sich unter Safes → Safe auswählen → Bearbeiten → Anmeldeinformationen, dass der Typ der Anmeldeinformation auf SSH Key gesetzt ist und ein Key angehängt ist. Überprüfen Sie, ob der entsprechende öffentliche Key in ~/.ssh/authorized_keys auf dem Zielhost für den konfigurierten Benutzer aufgeführt ist.

Behebung: Laden Sie den korrekten privaten Key in den Datensatz der Anmeldeinformation hoch oder fügen Sie den öffentlichen Key des Connectors zu authorized_keys auf dem Zielhost hinzu.

Lösungsschritte

1. Öffnen Sie Connectors in der Seitenleiste und vergewissern Sie sich, dass der dem Ziel-Safe zugewiesene Connector Online anzeigt. Falls nicht, folgen Sie Mein Connector ist offline, bevor Sie fortfahren.
2. Führen Sie auf der Connector-Maschine nc -zv <target-host> 22 aus, um zu bestätigen, dass der TCP-Port 22 erreichbar ist. Falls er blockiert ist, aktualisieren Sie die entsprechende Firewall- oder Security-Group-Regel.
3. Öffnen Sie Safes → Safe auswählen → Bearbeiten → Anmeldeinformationen und überprüfen Sie den Benutzernamen. Korrigieren Sie ihn, falls er nicht mit dem Konto des Zielhosts übereinstimmt.
4. Wenn der Fehler einen Host-Key-Konflikt erwähnt, öffnen Sie Safes → Safe auswählen → Bearbeiten → Verbindungseinstellungen und klicken Sie auf Host-Key zurücksetzen, und versuchen Sie die Sitzung dann erneut.
5. Wenn der Safe SSH-Key-Authentifizierung verwendet, vergewissern Sie sich, dass ein privater Key an den Datensatz der Anmeldeinformation angehängt ist und der passende öffentliche Key in ~/.ssh/authorized_keys auf dem Zielhost vorhanden ist.
6. Versuchen Sie die Sitzung nach jeder Änderung erneut, indem Sie im Safe auf Sitzung starten klicken.

Eskalationspfad

Wenn Sie alle fünf Ursachen abgearbeitet haben und die Sitzung weiterhin fehlschlägt:

1. Notieren Sie die genaue Fehlermeldung, die im Sitzungsbanner angezeigt wird.
2. Erfassen Sie auf der Connector-Maschine die letzten 100 Zeilen des Connector-Logs:
   • Docker: docker logs -n 100 vaultpam-connector
   • systemd: journalctl -u vaultpam-connector -n 100
3. Führen Sie nc -zv <target-host> 22 auf der Connector-Maschine aus und fügen Sie die Ausgabe hinzu.
4. Eröffnen Sie ein Support-Ticket mit: Connector-Name, Zielhost (maskiert, falls sensibel), genauer Fehlermeldung, Log-Ausgabe und nc-Ergebnis.

Verwandte Artikel

• Mein Connector ist offline
• Eine Anmeldeinformation rotieren