Sesiunea SSH nu poate fi lansată

Sesiunile SSH direcționate prin VaultPAM se bazează pe faptul că conectorul atinge gazda țintă pe portul TCP 22 (sau un port SSH personalizat). Atunci când o sesiune nu se deschide, una dintre cinci cauze fundamentale este aproape întotdeauna responsabilă. Parcurgeți-le în ordinea listată aici — problemele cu conectorul și rețeaua sunt mult mai frecvente decât problemele de acreditare sau cheie.

Simptome

• Făcând clic pe Launch Session se afișează un spinner și apoi o bannă de eroare.
• Fereastra sesiunii se deschide pe scurt și apoi se închide cu un mesaj precum:
  • SSH connection refused
  • Host unreachable
  • Authentication failed
  • Host key verification failed
  • Permission denied (publickey)
• Sesiunea nu apare niciodată în vizualizarea Active Sessions.

Cauze

1. Conectorul este offline

Conectorul care direcționează către gazda țintă trebuie să fie Online. Dacă este Offline, Degraded sau Needs recovery, fiecare încercare de sesiune prin el va eșua.

Verificare: Deschideți Connectors în bara laterală. Găsiți conectorul atribuit Safe-ului țintă. Confirmați că coloana de stare arată Online.

Remediere: Urmați ghidul My connector is offline.

2. Portul 22 este blocat între conector și gazda țintă

Mașina connectorului trebuie să poată atinge gazda țintă pe portul SSH (implicit 22). O regulă de firewall, un grup de securitate sau un firewall bazat pe gazdă (de ex., ufw, Windows Firewall) poate să îl blocheze.

Verificare: De pe mașina connectorului, executați:

nc -zv <target-host> 22

sau

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

Un răspuns Connection refused sau timeout confirmă o blocă de rețea.

Remediere: Actualizați firewall-ul sau grupul de securitate pentru a permite TCP 22 de la IP-ul connectorului la gazda țintă. Dacă gazda țintă utilizează un port SSH non-standard, verificați că portul corect este configurat în setările Safe: Safes → selectați Safe → Edit → Connection settings → Port.

3. Nume de utilizator incorect

Numele de utilizator folosit pentru conexiunea SSH trebuie să existe pe gazda țintă și trebuie să se potrivească exact (numele de utilizator Linux sunt case-sensitive).

Verificare: În Safes → selectați Safe → Edit → Credentials, confirmați că numele de utilizator este corect. Greșeli obișnuite: root vs ubuntu, admin vs administrator, sau o valoare implicită rămasă dintr-un șablon.

Remediere: Actualizați înregistrarea de acreditare pentru a utiliza numele de utilizator corect.

4. Nepotrivire a cheii gazdei

VaultPAM înregistrează cheia gazdei SSH la prima conectare. Dacă gazda țintă a fost reconstruită, cheile serverului SSH s-au schimbat (de ex., după reinstalarea OS), VaultPAM va refuza să se conecteze pentru a se proteja împotriva atacurilor man-in-the-middle.

Simptome: Mesajul de eroare conține Host key verification failed sau REMOTE HOST IDENTIFICATION HAS CHANGED.

Verificare: Deschideți Safes → selectați Safe → Edit → Connection settings. Dacă o amprenta a cheii gazdei stocate este vizibilă, comparați-o cu cheia gazdei actuale executând pe mașina țintă:

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

Remediere: Dacă schimbarea cheii este așteptată (reconstrucție legitimă), faceți clic pe Reset host key în setările de conexiune ale Safe-ului. VaultPAM va accepta noua cheie la următoarea încercare de conectare și o va stoca pentru verificări viitoare.

5. Cheie SSH lipsă sau respinsă

Dacă Safe-ul este configurat să utilizeze autentificarea cu cheie publică în loc de checkout cu parolă, conectorul trebuie să aibă acces la o cheie privată care este autorizată pe gazda țintă.

Verificare: În Safes → selectați Safe → Edit → Credentials, confirmați că tipul de acreditare este setat la SSH Key și o cheie este atașată. Verificați că cheia publică corespunzătoare este listată în ~/.ssh/authorized_keys pe gazda țintă pentru utilizatorul configurat.

Remediere: Încărcați cheia privată corectă în înregistrarea de acreditare, sau adăugați cheia publică a connectorului la authorized_keys pe gazda țintă.

Pași de rezolvare

1. Deschideți Connectors în bara laterală și confirmați că conectorul atribuit Safe-ului țintă arată Online. Dacă nu, urmați My connector is offline înainte de a continua.
2. De pe mașina connectorului, executați nc -zv <target-host> 22 pentru a confirma că portul TCP 22 este accesibil. Dacă este blocat, actualizați regula de firewall sau grupul de securitate relevant.
3. Deschideți Safes → selectați Safe → Edit → Credentials și verificați numele de utilizator. Corectați-l dacă nu corespunde contului de pe gazda țintă.
4. Dacă eroarea menționează o nepotrivire de cheie a gazdei, deschideți Safes → selectați Safe → Edit → Connection settings și faceți clic pe Reset host key, apoi reîncercați sesiunea.
5. Dacă Safe-ul utilizează autentificarea SSH key, confirmați că o cheie privată este atașată la înregistrarea de acreditare și cheia publică potrivită se află în ~/.ssh/authorized_keys pe gazda țintă.
6. După fiecare modificare, reîncercați sesiunea făcând clic pe Launch Session pe Safe.

Cale de escaladare

Dacă ați parcurs toate cinci cauze și sesiunea încă eșuează:

1. Notați mesajul exact de eroare afișat în bannă sesiunii.
2. Pe mașina connectorului, colectați ultimele 100 de linii din jurnalul connectorului:
   • Docker: docker logs -n 100 vaultpam-connector
   • systemd: journalctl -u vaultpam-connector -n 100
3. Executați nc -zv <target-host> 22 de pe mașina connectorului și includeți rezultatul.
4. Deschideți un tichet de suport cu: numele connectorului, gazda țintă (mascată dacă este sensibilă), mesajul exact de eroare, rezultatul jurnalului și rezultatul nc.

Articole conexe

• My connector is offline
• Rotate a credential