Risoluzione dei problemi comuni di SSH: Connessione rifiutata e accesso negato

I guasti SSH sono più facili da risolvere quando si separano i problemi di trasporto da quelli di autenticazione. Connessione rifiutata significa che il client SSH ha raggiunto un host, ma nessuno ha accettato la connessione TCP su quella porta. Permesso negato significa che il server SSH ha risposto, ma ha rifiutato il tuo login. Sono incidenti diversi, anche se entrambi sembrano "Non riesco ad entrare".

Mantieni una sessione SSH attiva mentre modifichi le impostazioni del server. La maggior parte dei dolorosi down di SSH si verifica quando qualcuno modifica /etc/ssh/sshd_config, riavvia il servizio, si disconnette e solo allora scopre che la nuova configurazione blocca ogni percorso di login.

Comprendere gli errori: Rifiutato vs. Negato

Leggi il messaggio esatto del client prima di modificare qualsiasi cosa:

Connessione rifiutata: l'host ha rifiutato attivamente la connessione TCP, di solito perché sshd non è in ascolto su quella porta o un firewall la sta rifiutando.
Connessione scaduta: i pacchetti vengono persi o il percorso di rete è interrotto. È più probabile che sia un firewall, una route, una VPN, un gruppo di sicurezza o un IP sbagliato.
Permesso negato (publickey): il server è raggiungibile, ma non ha accettato la tua chiave.
Permesso negato (publickey,password): il server ha provato uno o più metodi di autenticazione e li ha rifiutati.
Verifica della chiave host fallita: il tuo client non si fida dell'identità del server attualmente presentata per quel nome host o IP.

Parte 1: Risoluzione dei problemi di Connessione rifiutata

ssh: connect to host example port 22: Connection refused di solito indica l'host remoto o la porta. La macchina ha risposto, ma SSH non accettava connessioni lì.

1. Verifica lo stato del demone SSH (sshd)

La causa più comune del rifiuto è che il processo del server SSH non è in esecuzione o è andato in crash.

Passaggi attuabili (sul server remoto):

Su molte distribuzioni Linux il servizio si chiama sshd; su Debian e Ubuntu spesso si chiama ssh. Prova quello usato dal tuo sistema:

systemctl status sshd
systemctl status ssh

Se il servizio è inattivo o fallito, avvialo:

sudo systemctl start sshd
sudo systemctl enable sshd

Se sshd non si avvia dopo una modifica della configurazione, convalida la configurazione:

sudo sshd -t

Questo comando è uno dei controlli più sicuri che puoi eseguire prima di riavviare SSH.

2. Controlla la porta di ascolto e la configurazione

Per impostazione predefinita, SSH utilizza la porta TCP 22, ma molti server utilizzano una porta diversa. Se il server ascolta sulla 2222, il comando client deve includerla:

ssh -p 2222 [email protected]

A. Rivedi `sshd_config`

Esamina il file di configurazione SSH, tipicamente situato in /etc/ssh/sshd_config. Cerca la direttiva Port:

# /etc/ssh/sshd_config esempio
Port 2222  # Se non è 22, devi specificarlo lato client

Dopo aver modificato il file, esegui sudo sshd -t prima di ricaricare. Se la sintassi è valida, ricarica o riavvia il servizio. Il ricaricamento è di solito meno invasivo:

sudo systemctl reload sshd

B. Verifica i socket in ascolto

Usa ss per confermare che sshd è in ascolto:

sudo ss -tuln | grep 22

# Output previsto che mostra lo stato di ascolto:
# LISTEN 0      128    0.0.0.0:22               0.0.0.0:*

Se SSH ascolta solo su 127.0.0.1:22, i client remoti non possono connettersi. Se ascolta su 0.0.0.0:22 o su un indirizzo di interfaccia privata specifico, l'accesso remoto potrebbe essere possibile a seconda delle regole del firewall.

3. Controlli del firewall e della rete

Un firewall che elimina i pacchetti di solito causa un timeout. Un firewall che rifiuta i pacchetti può causare un rifiuto. Controlla sia il firewall dell'host che qualsiasi firewall di rete esterno all'host.

Comandi firewall comuni (UFW su Ubuntu/Debian):

Assicurati che il traffico SSH sia consentito:

# Controlla lo stato corrente
sudo ufw status

# Consenti traffico sulla porta predefinita 22
sudo ufw allow ssh
# OPPURE per numero di porta
sudo ufw allow 22/tcp

# Ricarica le regole del firewall
sudo ufw reload

I gruppi di sicurezza del cloud, le ACL di rete, le route VPN e i firewall aziendali possono bloccare SSH prima che il traffico raggiunga il server. Se sshd è in ascolto e il firewall dell'host è aperto, testa da una macchina all'interno della stessa rete privata. Questo ti dice se il problema è locale al server o da qualche parte lungo il percorso esterno.

Parte 2: Risoluzione dei problemi di Permesso negato

Se il server risponde con Permesso negato, il percorso di rete funziona. Concentrati su nome utente, metodi di autenticazione consentiti, chiavi, stato dell'account e permessi dei file.

1. Controlla nome utente e password

Questo è il controllo più semplice, ma spesso trascurato:

Nome utente: Le immagini cloud spesso usano utenti specifici come ubuntu, ec2-user, admin, debian o rocky. root potrebbe essere disabilitato.
Password: Se l'autenticazione tramite password è abilitata, controlla errori di battitura, blocco dell'account, password scadute e regole PAM.
Porta e host: Un numero sorprendente di fallimenti di autenticazione è causato dalla connessione al server sbagliato che casualmente esegue SSH.

Controllo lato client: Per vedere l'output di debug dettagliato, esegui il client con flag verbosi:

ssh -vvv user@hostname

Questo output mostrerà chiaramente quali metodi di autenticazione il client ha tentato e quali il server ha rifiutato.

2. Fallimenti dell'autenticazione basata su chiave

L'autenticazione tramite chiave fallisce quando il client offre la chiave privata sbagliata, il server non ha la chiave pubblica corrispondente, i permessi sono troppo aperti o sshd_config blocca il login.

A. Permessi errati sulla directory `.ssh`

SSH è estremamente severo riguardo ai permessi dei file per motivi di sicurezza. Se i permessi sono troppo aperti, il server ignorerà completamente il file della chiave.

Sul server remoto (Correzione dei permessi):

# I permessi della home directory dell'utente sono di solito ok, ma controlla la cartella .ssh
chmod 700 ~/.ssh

# Il file authorized_keys deve essere scrivibile solo dal proprietario
chmod 600 ~/.ssh/authorized_keys

Controlla anche la proprietà:

chown -R "$USER:$USER" ~/.ssh

Sul server, StrictModes è comunemente abilitato. Se la home directory, la directory .ssh o il file authorized_keys è scrivibile da altri utenti, sshd potrebbe ignorare la chiave.

B. Chiave non presente o formattata in modo errato

Assicurati che la chiave pubblica sia nel file ~/.ssh/authorized_keys dell'utente di destinazione, una chiave per riga. La chiave privata rimane sul tuo client. Non incollare la chiave privata in authorized_keys.

Dal client, forza una chiave specifica durante il debug:

ssh -i ~/.ssh/id_ed25519 -vvv [email protected]

Nell'output verboso, cerca le righe che mostrano quali chiavi sono state offerte e perché il server le ha accettate o rifiutate.

C. Configurazione del server che disabilita le chiavi

Controlla /etc/ssh/sshd_config sul server per assicurarti che l'autenticazione tramite chiave sia consentita:

PubkeyAuthentication yes

# Assicurati che l'autenticazione tramite password non sia disabilitata se fai affidamento sulle password
PasswordAuthentication yes

Se sono presenti AllowUsers, AllowGroups, DenyUsers o DenyGroups, possono sovrascrivere quella che sembra una configurazione valida della chiave. Un utente con la chiave giusta può comunque essere bloccato da queste direttive.

3. Indagine sui log lato server

I log del server di solito ti dicono la vera ragione di un rifiuto. Tieni un terminale aperto sul server e guarda i log mentre tenti un login dal client.

Posizioni comuni dei log:

Debian/Ubuntu: /var/log/auth.log
RHEL/CentOS/Fedora: /var/log/secure

Usa grep per filtrare i tentativi di connessione recenti:

# Su sistemi RHEL/CentOS
sudo grep 'Failed password' /var/log/secure

# Oppure cerca attività SSH generale
sudo tail -f /var/log/secure

Su sistemi con journaling systemd, questo è spesso più facile:

sudo journalctl -u sshd -f
sudo journalctl -u ssh -f

I messaggi di log possono mostrare "bad ownership or modes", "user not allowed", "invalid user", "authentication refused" o fallimenti dell'account PAM. Questi messaggi sono più affidabili che indovinare dal solo lato client.

Fallimenti di verifica della chiave host

Host key verification failed non è la stessa cosa di una password o chiave sbagliata. Significa che il tuo client ha un'identità del server salvata per quel nome host o IP, e il server sta ora presentando un'identità diversa. Questo può accadere dopo una ricostruzione, un riutilizzo dell'IP, un cambio di bilanciatore del carico o un vero rischio di man-in-the-middle.

Non eliminare ciecamente l'avviso in un ambiente di produzione. Verifica l'impronta digitale del server tramite la console cloud, la gestione della configurazione o un canale fidato esistente. Una volta che sai che il cambiamento è previsto, rimuovi la vecchia voce:

ssh-keygen -R example.com
ssh-keygen -R 192.0.2.10

Quindi riconnettiti e accetta la nuova chiave host solo se l'impronta digitale corrisponde a quella che ti aspetti.

Riepilogo delle migliori pratiche per un accesso SSH affidabile

Usa coppie di chiavi: Disabilita l'autenticazione tramite password solo dopo aver testato l'accesso tramite chiave in una seconda sessione.
Limita chi può accedere: Usa AllowUsers o AllowGroups quando appropriato, ma documentalo in modo che i futuri operatori non inseguano falsi problemi di permesso.
Usa PermitRootLogin no: Preferisci utenti normali con sudo.
Esegui il backup della configurazione: Prima di modificare /etc/ssh/sshd_config, copialo:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F) ``` 5. Convalida prima di ricaricare: Esegui sudo sshd -t. 6. Mantieni un percorso di emergenza: Per i server cloud, sappi come usare la console seriale, la modalità di ripristino, la funzione di connessione all'istanza o la gestione della configurazione se SSH si rompe.

Il percorso più breve attraverso la risoluzione dei problemi SSH è: identifica l'errore esatto, dimostra se il server è in ascolto, dimostra se il percorso di rete raggiunge quella porta, quindi leggi i log del server per i fallimenti di autenticazione. Indovinare di solito richiede più tempo che eseguire questi controlli in ordine.