Mijn SSH-sessie kan niet worden gestart

SSH-sessies die via VaultPAM worden gerouteerd, zijn afhankelijk van de connector die de doelhost bereikt op TCP-poort 22 (of een aangepaste SSH-poort). Wanneer een sessie niet kan worden geopend, is vrijwel altijd één van vijf oorzaken verantwoordelijk. Werk ze in de aangegeven volgorde af — connector- en netwerkproblemen zijn veel vaker voorkomen dan aanmeld- of sleutelproblemen.

Symptomen

• Het klikken op Launch Session toont een spinner en vervolgens een foutbanner.
• Het sessievenster opent kortstondig en sluit dan met een bericht zoals:
  • SSH connection refused
  • Host unreachable
  • Authentication failed
  • Host key verification failed
  • Permission denied (publickey)
• De sessie verschijnt nooit in de weergave Active Sessions.

Oorzaken

1. Connector is offline

De connector die naar de doelhost routeert, moet Online zijn. Als deze Offline, Degraded of Needs recovery is, zal elke sessiepoging via deze connector mislukken.

Controleren: Open Connectors in de zijbalk. Zoek de connector die aan de doelSafe is toegewezen. Bevestig dat de statuskolom Online weergeeft.

Herstel: Volg de Mijn connector is offline handleiding.

2. Poort 22 is geblokkeerd tussen de connector en het doel

De connectormachine moet het doelhost kunnen bereiken op de SSH-poort (standaard 22). Een firewall-regel, beveiligingsgroep of hostfirewall (bijv. ufw, Windows Firewall) kan dit blokkeren.

Controleren: Voer op de connectormachine het volgende uit:

nc -zv <target-host> 22

of

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

Een Connection refused of timeout-reactie bevestigt een netwerkblokking.

Herstel: Werk de firewall- of beveiligingsgroepregel bij om TCP 22 van het IP-adres van de connector naar het doel toe te staan. Als het doel een niet-standaard SSH-poort gebruikt, controleer dan of de juiste poort in de Safe-instellingen is geconfigureerd: Safes → Safe selecteren → Edit → Connection settings → Port.

3. Onjuiste gebruikersnaam

De gebruikersnaam die voor de SSH-verbinding wordt gebruikt, moet op de doelhost bestaan en moet exact overeenkomen (Linux-gebruikersnamen zijn hoofdlettergevoelig).

Controleren: Bevestig in Safes → Safe selecteren → Edit → Credentials dat de gebruikersnaam correct is. Veelgebruikte fouten: root versus ubuntu, admin versus administrator, of een achtergebleven standaardwaarde van een sjabloon.

Herstel: Werk de aanmeldingsregistratie bij om de juiste gebruikersnaam te gebruiken.

4. Hostsleutels komen niet overeen

VaultPAM registreert de SSH-hostsleutel bij de eerste verbinding. Als de doelhost opnieuw werd gebouwd en de SSH-serversleutels zijn gewijzigd (bijv. na OS-herinstallatie), weigert VaultPAM verbinding te maken ter bescherming tegen man-in-the-middle-aanvallen.

Symptomen: Het foutbericht bevat Host key verification failed of REMOTE HOST IDENTIFICATION HAS CHANGED.

Controleren: Open Safes → Safe selecteren → Edit → Connection settings. Als een opgeslagen hostsleutel-vingerafdruk zichtbaar is, vergelijk deze met de huidige hostsleutel door op de doelmachine het volgende uit te voeren:

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

Herstel: Als de sleutelwijziging verwacht is (legitiem herbouwen), klik dan op Reset host key in de Safe-verbindingsinstellingen. VaultPAM accepteert de nieuwe sleutel bij de volgende verbindingspoging en slaat deze op voor toekomstige verificatie.

5. Ontbrekende of afgewezen SSH-sleutel

Als de Safe is geconfigureerd voor openbare-sleutelverificatie in plaats van wachtwoorduitchecking, moet de connector toegang hebben tot een persoonlijke sleutel die is geautoriseerd op de doelhost.

Controleren: Bevestig in Safes → Safe selecteren → Edit → Credentials dat het aanmeldingstype is ingesteld op SSH Key en dat een sleutel is gekoppeld. Controleer of de overeenkomstige openbare sleutel in ~/.ssh/authorized_keys op de doelhost voor de geconfigureerde gebruiker wordt vermeld.

Herstel: Upload de juiste persoonlijke sleutel naar de aanmeldingsregistratie, of voeg de openbare sleutel van de connector toe aan authorized_keys op de doelhost.

Oplossingsstappen

1. Open Connectors in de zijbalk en bevestig dat de connector die aan de doelSafe is toegewezen Online weergeeft. Zo niet, volg dan eerst Mijn connector is offline.
2. Voer op de connectormachine nc -zv <target-host> 22 uit om te bevestigen dat TCP-poort 22 bereikbaar is. Werk eventuele firewall- of beveiligingsgroepregel bij als deze wordt geblokkeerd.
3. Open Safes → Safe selecteren → Edit → Credentials en controleer de gebruikersnaam. Corrigeer deze als deze niet overeenkomt met het doelhost-account.
4. Als de fout een hostsleutelconflict noemt, open dan Safes → Safe selecteren → Edit → Connection settings en klik op Reset host key, vervolgens probeert u de sessie opnieuw.
5. Als de Safe SSH-sleutelverificatie gebruikt, bevestig dan dat een persoonlijke sleutel aan de aanmeldingsregistratie is gekoppeld en dat de overeenkomstige openbare sleutel in ~/.ssh/authorized_keys op de doelhost staat.
6. Probeer na elke wijziging de sessie opnieuw door op Launch Session op de Safe te klikken.

Escalatiepad

Als u alle vijf oorzaken hebt doorgewerkt en de sessie blijft mislukken:

1. Noteer het exacte foutbericht dat in de sessiebanner wordt weergegeven.
2. Verzamel op de connectormachine de laatste 100 regels van het connectorlogboek:
   • Docker: docker logs -n 100 vaultpam-connector
   • systemd: journalctl -u vaultpam-connector -n 100
3. Voer nc -zv <target-host> 22 uit op de connectormachine en neem de uitvoer op.
4. Open een supportticket met: connectornaam, doelhost (gemaskeerd indien gevoelig), exacte foutbericht, logboekuitvoer en nc-resultaat.

Gerelateerde artikelen

• Mijn connector is offline
• Een aanmeldingsgegevens roteren