Errori SSH su un VPS Ubuntu: come trovare la causa

Registra un tentativo e conserva l’accesso

Mantieni aperta la sessione funzionante e individua la console di recupero. I comandi client si eseguono sul computer in Linux, macOS o WSL; quelli server attraverso l’accesso esistente o la console autenticata. Non incollare comandi server nel terminale locale.

Sostituisci 203.0.113.10, ubuntu, porta 22 e percorso della chiave con i valori reali. L’indirizzo è riservato alla documentazione. Stampa le impostazioni effettive e prova una connessione nuova.

ssh -G -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10
ssh -v -S none -o ConnectTimeout=10 -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

Esamina hostname, user, port, identityfile e proxy. Il secondo comando disabilita la condivisione della connessione per quel tentativo. Annota ora ed errore finale; verifica ogni nuova impronta host con il procedimento sotto. Prima di condividere il debug rimuovi nomi, indirizzi e percorsi riservati. Non condividere chiavi private.

Scegli il controllo in base al punto di errore

Scorri la tabella per vedere le altre colonne →

Sono indizi, non la prova di un’unica causa. Se il debug ha già mostrato Connection established prima del timeout, controlla negoziazione SSH e log server invece di presumere che tutto il traffico sia bloccato.

Timeout: segui il percorso di rete previsto

Confronta la destinazione di ssh -v con l’indirizzo corrente nel pannello. Un DNS obsoleto o una destinazione IPv6 diversa può portare altrove. Verifica se il VPS richiede indirizzo pubblico, VPN o jump host.

Controlla che l’istanza sia attiva e che esista il routing necessario. Nelle regole del provider verifica la porta SSH effettiva e l’IP pubblico sorgente attuale: l’indirizzo domestico può cambiare mentre una regola /32 rimane invariata. Dalla console controlla anche il firewall guest.

In OCI contano security list, NSG, routing e firewall guest. Conserva le regole dell’immagine: installare UFW o svuotare iptables non è un passo diagnostico. La procedura Oracle descrive la rete. Un ping fallito da solo non prova che SSH sia indisponibile.

Connessione rifiutata: verifica il listener

Un rifiuto non autentica il destinatario come il tuo VPS. Conferma identità e porta, poi esegui sul server questi controlli in sola lettura dall’accesso esistente o dalla console.

systemctl status ssh.service ssh.socket --no-pager
sudo ss -lntp
sudo /usr/sbin/sshd -t
sudo journalctl -u ssh.service -u ssh.socket --since '15 minutes ago' --no-pager

Cerca un listener su indirizzo e porta previsti e confronta i log con l’ora del tentativo. Ubuntu può usare socket activation: ssh.service inattivo da solo non significa indisponibilità se ssh.socket è in ascolto.

sshd -t verifica configurazione e chiavi host senza avviare il demone. Il successo silenzioso non prova la raggiungibilità di rete. Se segnala un errore, identifica file o impostazione prima di valutare un reload; non riavviare alla cieca.

Chiave respinta: controlla account e identità offerta

Usa l’account iniziale del provider o quello creato da te. Nel debug trova l’impronta effettivamente offerta. Per limitare chiavi estranee dell’agente, riprova dal computer con:

ssh -v -S none -o IdentitiesOnly=yes -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

Le IdentityFile configurate possono ancora applicarsi: controlla ssh -G. Se la chiave privata locale non è leggibile o ha permessi troppo ampi, correggi quel file prima del server.

Sul server esamina l’account e le chiavi pubbliche autorizzate. Il percorso d’esempio è /home/ubuntu; sostituiscilo con la home mostrata da getent.

getent passwd ubuntu
sudo ls -ld /home/ubuntu /home/ubuntu/.ssh /home/ubuntu/.ssh/authorized_keys
sudo ssh-keygen -lf /home/ubuntu/.ssh/authorized_keys

Confronta le impronte autorizzate con quella offerta. Cerca nel journal problemi di proprietario, permessi o policy dell’account. Se il percorso standard non è usato, verifica AuthorizedKeysFile, file inclusi, regole Match e servizi di chiavi gestiti dal provider. Mantieni le chiavi esistenti; non disabilitare StrictModes o abilitare password per nascondere la causa.

Identità cambiata: verifica prima di collegarti

Una ricostruzione o un IP riassegnato può cambiare la chiave host; un cambiamento inatteso può anche indicare endpoint sbagliato o intercettazione. Conferma identificatore dell’istanza ed eventuale reinstallazione nel pannello autenticato.

Dalla console attendibile del guest controlla la chiave pubblica host dello stesso algoritmo mostrato dal client. Per Ed25519:

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256

Confronta l’impronta SHA256 con l’avviso. È la chiave del server, non quella dell’utente né del gateway console. Per una sostituzione verificata aggiorna soltanto la voce di quel server in known_hosts, facendo prima una copia e conservando le altre voci. Non eliminare tutto il file né saltare il controllo. Se la nuova identità resta inspiegata, interrompi la connessione.

Prova la correzione con una sessione nuova

Correggi l’indirizzo, l’utente, la chiave, la specifica regola di rete o l’impostazione individuata. Conserva un accesso indipendente e valida la configurazione SSH prima di applicare cambiamenti. Cambiare porta può richiedere attenzione a socket activation, non solo al servizio.

Ripeti il tentativo originale senza condivisione della connessione. Verifica account raggiunto e sudo necessario; una vecchia sessione ancora collegata non equivale a questa prova. Registra problema e correzione, poi torna alla configurazione del sito se era stata interrotta.

Domande e risposte