La mia sessione SSH non si avvia

Le sessioni SSH instradate attraverso VaultPAM richiedono che il connector raggiunga l'host di destinazione sulla porta TCP 22 (o su una porta SSH personalizzata). Quando una sessione non si apre, una di cinque cause alla radice è quasi sempre responsabile. Elaborarle nell'ordine elencato di seguito — i problemi di connector e di rete sono molto più comuni di quelli di credenziali o chiavi.

Sintomi

• Fare clic su Launch Session mostra uno spinner e quindi un banner di errore.
• La finestra della sessione si apre brevemente e quindi si chiude con un messaggio come:
  • SSH connection refused
  • Host unreachable
  • Authentication failed
  • Host key verification failed
  • Permission denied (publickey)
• La sessione non appare mai nella vista Active Sessions.

Cause

1. Il connector è offline

Il connector che instrada verso l'host di destinazione deve essere Online. Se è Offline, Degraded o Needs recovery, ogni tentativo di sessione attraverso di esso avrà esito negativo.

Verifica: Aprire Connectors nella barra laterale. Trovare il connector assegnato al Safe di destinazione. Confermare che la colonna dello stato mostra Online.

Soluzione: Seguire il runbook My connector is offline.

2. La porta 22 è bloccata tra il connector e la destinazione

La macchina del connector deve essere in grado di raggiungere l'host di destinazione sulla porta SSH (predefinita 22). Una regola del firewall, un gruppo di sicurezza o un firewall basato su host (ad es. ufw, Windows Firewall) potrebbe bloccarla.

Verifica: Dalla macchina del connector, eseguire:

nc -zv <target-host> 22

oppure

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

Una risposta Connection refused o timeout confirma un blocco di rete.

Soluzione: Aggiornare il firewall o il gruppo di sicurezza per consentire TCP 22 dall'IP del connector alla destinazione. Se la destinazione utilizza una porta SSH non standard, verificare che la porta corretta sia configurata nelle impostazioni del Safe: Safes → scegliere Safe → Edit → Connection settings → Port.

3. Nome utente errato

Il nome utente utilizzato per la connessione SSH deve esistere sull'host di destinazione e deve corrispondere esattamente (i nomi utente Linux sono sensibili alle maiuscole/minuscole).

Verifica: In Safes → scegliere Safe → Edit → Credentials, confermare che il nome utente sia corretto. Errori comuni: root vs ubuntu, admin vs administrator, o un valore predefinito residuo da un template.

Soluzione: Aggiornare il record delle credenziali per utilizzare il nome utente corretto.

4. Mancata corrispondenza della chiave host

VaultPAM registra la chiave host SSH alla prima connessione. Se l'host di destinazione è stato ricostruito, le sue chiavi del server SSH sono cambiate (ad es. dopo una reinstallazione del sistema operativo), VaultPAM si rifiuterà di connettersi per proteggere contro attacchi man-in-the-middle.

Sintomi: Il messaggio di errore contiene Host key verification failed o REMOTE HOST IDENTIFICATION HAS CHANGED.

Verifica: Aprire Safes → scegliere Safe → Edit → Connection settings. Se è visibile un'impronta digitale della chiave host memorizzata, confrontarla con la chiave host attuale eseguendo sulla macchina di destinazione:

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

Soluzione: Se il cambio della chiave è previsto (ricostruzione legittima), fare clic su Reset host key nelle impostazioni di connessione del Safe. VaultPAM accetterà la nuova chiave al prossimo tentativo di connessione e la memorizzerà per la verifica futura.

5. Chiave SSH mancante o rifiutata

Se il Safe è configurato per utilizzare l'autenticazione a chiave pubblica anziché il checkout della password, il connector deve avere accesso a una chiave privata autorizzata sull'host di destinazione.

Verifica: In Safes → scegliere Safe → Edit → Credentials, confermare che il tipo di credenziale sia impostato su SSH Key e che una chiave sia allegata. Verificare che la chiave pubblica corrispondente sia elencata in ~/.ssh/authorized_keys sull'host di destinazione per l'utente configurato.

Soluzione: Caricare la chiave privata corretta nel record delle credenziali oppure aggiungere la chiave pubblica del connector a authorized_keys sull'host di destinazione.

Passaggi di risoluzione

1. Aprire Connectors nella barra laterale e confermare che il connector assegnato al Safe di destinazione mostri Online. Se non è così, seguire My connector is offline prima di continuare.
2. Dalla macchina del connector, eseguire nc -zv <target-host> 22 per confermare che la porta TCP 22 sia raggiungibile. Se è bloccata, aggiornare la regola di firewall o del gruppo di sicurezza pertinente.
3. Aprire Safes → scegliere Safe → Edit → Credentials e verificare il nome utente. Correggerlo se non corrisponde all'account dell'host di destinazione.
4. Se l'errore menziona una mancata corrispondenza della chiave host, aprire Safes → scegliere Safe → Edit → Connection settings e fare clic su Reset host key, quindi riprovare la sessione.
5. Se il Safe utilizza l'autenticazione con chiave SSH, confermare che una chiave privata sia allegata al record delle credenziali e che la chiave pubblica corrispondente sia in ~/.ssh/authorized_keys sull'host di destinazione.
6. Dopo ogni modifica, riprovare la sessione facendo clic su Launch Session sul Safe.

Percorso di escalation

Se hai esaminato tutte e cinque le cause e la sessione continua a non riuscire:

1. Annotare il messaggio di errore esatto mostrato nel banner della sessione.
2. Sulla macchina del connector, raccogliere le ultime 100 righe del log del connector:
   • Docker: docker logs -n 100 vaultpam-connector
   • systemd: journalctl -u vaultpam-connector -n 100
3. Eseguire nc -zv <target-host> 22 dalla macchina del connector e includere l'output.
4. Aprire un ticket di supporto con: nome del connector, host di destinazione (mascherato se sensibile), messaggio di errore esatto, output del log e risultato di nc.

Articoli correlati

• My connector is offline
• Rotate a credential