Risoluzione dei problemi comuni di SSH: Connessione rifiutata e negata

Secure Shell (SSH) è la base dell'amministrazione remota dei sistemi, fornendo comunicazioni crittografate per l'accesso ai server. Tuttavia, incontrare errori di connessione può bloccare immediatamente la produttività. I due errori più comuni e frustranti che gli utenti riscontrano sono "Connection Refused" (Connessione rifiutata) e "Permission Denied" (Permesso negato).

Questa guida ti accompagnerà attraverso un approccio sistematico per diagnosticare e risolvere questi problemi. Comprendendo le cause tipiche, che vanno dagli ostacoli di rete alle configurazioni di autenticazione errate, puoi ripristinare rapidamente l'accesso sicuro alle tue macchine remote. Tratteremo controlli essenziali, dalla verifica dello stato del server al debug dei meccanismi di autenticazione.

Comprensione degli Errori: Rifiutato vs. Negato

È fondamentale differenziare tra i due messaggi di errore principali, poiché indicano cause profonde molto diverse:

Connection Refused (Connessione rifiutata): Ciò significa solitamente che la connessione di rete ha raggiunto il server, ma nulla era in ascolto sulla porta specificata, o il sistema operativo ha attivamente rifiutato il tentativo di connessione.
Permission Denied (Permesso negato): Ciò implica che il servizio SSH (sshd) ha ricevuto correttamente la richiesta di connessione, ma il tentativo di autenticazione (password o chiave) è fallito in base alla configurazione del server.

Parte 1: Risoluzione dei problemi di Connection Refused (Connessione rifiutata)

"Connection Refused" (spesso visualizzato come ssh: connect to host <hostname> port 22: Connection refused) indica tipicamente un problema sul lato server che impedisce al demone di accettare connessioni in arrivo.

1. Verifica dello Stato del Demone SSH (sshd)

La causa più comune del rifiuto è che il processo del server SSH non è in esecuzione o si è arrestato in modo anomalo.

Azioni concrete (sul server remoto):

Verifica lo stato del servizio utilizzando systemctl (comune sulle moderne distribuzioni Linux):

systemctl status sshd

Se lo stato mostra inactive (inattivo) o failed (fallito), avvia il servizio:

sudo systemctl start sshd
# Abilitalo per avviarsi automaticamente all'avvio
sudo systemctl enable sshd

2. Verifica della Porta di Ascolto e della Configurazione

Per impostazione predefinita, SSH viene eseguito sulla porta TCP 22. Se la porta è stata modificata per migliorare la sicurezza, devi specificare la porta corretta durante la connessione o assicurarti che il server sia in ascolto sulla porta prevista.

A. Revisione di `sshd_config`

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

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

Se modifichi questo file, devi riavviare il servizio sshd affinché le modifiche abbiano effetto.

B. Verifica dei Socket di Ascolto

Utilizza ss o netstat per confermare che sshd sia attivamente in ascolto sull'interfaccia e sulla porta previste. Controlliamo la porta 22 qui:

# Usando ss (preferito sui sistemi moderni)
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 non compare nulla per la porta 22, il demone non è in esecuzione o è configurato per ascoltare su un indirizzo/porta diverso.

3. Controlli Firewall e di Rete

Un firewall che blocca il traffico prima che raggiunga il processo sshd spesso risulterà in un timeout, ma a volte può presentarsi come un rifiuto. È essenziale confermare le regole del firewall lato server.

Comandi Firewall Comuni (UFW su Ubuntu/Debian):

Assicurati che il traffico SSH sia consentito:

# Controlla lo stato attuale
sudo ufw status

# Consenti il 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

⚠️ Attenzione sui Firewall Esterni: Se ti stai connettendo da una rete remota, assicurati che eventuali dispositivi di rete intermedi, gruppi di sicurezza cloud (come i gruppi di sicurezza AWS o le NSG di Azure) o firewall hardware consentano esplicitamente il traffico sulla porta SSH.

Parte 2: Risoluzione dei problemi di Permission Denied (Permesso negato)

Se ti connetti con successo al server ma ricevi immediatamente "Permission denied (publickey,password)", il problema riguarda esclusivamente l'autenticazione.

1. Verifica Nome Utente e Password

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

Nome utente: Stai utilizzando il nome utente corretto per il sistema di destinazione? L'accesso come root potrebbe essere disabilitato.
Password: Se utilizzi l'autenticazione tramite password, verifica il blocco Maiuscole, gli errori di battitura e assicurati che l'account non sia bloccato.

Controllo Lato Client: Per visualizzare l'output di debug dettagliato, esegui il tuo client con flag di verbosità:

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 tramite Chiave

L'autenticazione tramite chiave è superiore, ma gli errori di configurazione sono cause frequenti di negazione.

A. Permessi errati sulla directory `.ssh`

SSH è estremamente rigoroso 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 directory home dell'utente sono solitamente corretti, ma controlla la cartella .ssh
chmod 700 ~/.ssh

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

B. Chiave non presente o formattata in modo errato

Assicurati che la tua chiave pubblica (id_rsa.pub o simile) sia correttamente aggiunta al file ~/.ssh/authorized_keys del server per l'utente di destinazione. Ogni chiave deve trovarsi su una riga separata, senza interruzioni di riga nel mezzo della stringa della chiave.

C. Configurazione del Server che Disabilita le Chiavi

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

PubkeyAuthentication yes

# Assicurati che l'autenticazione tramite password non sia disabilitata se ti affidi alle password
PasswordAuthentication yes

3. Indagine sui Log Lato Server

Quando l'autenticazione fallisce, i log del server sono la fonte definitiva della verità. Cerca messaggi relativi al tentativo di accesso fallito.

Posizioni Comuni dei Log:

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

Utilizza grep per filtrare i tentativi di connessione recenti:

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

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

I messaggi di log spesso indicano esplicitamente perché la chiave è stata rifiutata (ad esempio, opzioni errate, nessuna chiave corrispondente trovata o contesto utente errato).

Riepilogo delle Migliori Pratiche per un Accesso SSH Affidabile

Usa Coppie di Chiavi: Disabilita l'autenticazione tramite password (PasswordAuthentication no) in sshd_config una volta verificato l'accesso tramite chiave.
Cambia la Porta Predefinita: Spostare SSH fuori dalla porta 22 riduce il rumore delle scansioni automatiche.
Usa PermitRootLogin no: Forza l'accesso amministrativo tramite utenti standard, obbligando l'uso di sudo.
Backup della Configurazione: Prima di apportare modifiche significative a /etc/ssh/sshd_config, esegui sempre il backup del file originale:
bash sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F)
Testa Localmente: Dopo le modifiche alla configurazione, testa la connettività localmente sul server (se possibile) prima di disconnettere la sessione attiva per evitare di bloccarti fuori.

Controllando sistematicamente lo stato del servizio, il percorso di rete e i livelli di configurazione dell'autenticazione, puoi risolvere rapidamente i frustranti errori Connection Refused e Permission Denied intrinseci alla gestione dell'accesso remoto.