Centro di Conoscenza DevOps
Centro di Conoscenza DevOps

Risolvere rapidamente gli errori di connessione SSH rifiutata

Incontrare un errore SSH "Connessione rifiutata" può bloccare la gestione del server remoto. Questa guida completa illustra la risoluzione dei problemi passo dopo passo, concentrandosi sulla diagnostica lato server critica. Impara a verificare lo stato del tuo demone SSH, controllare e configurare le regole del firewall (UFW, firewalld), ispezionare le impostazioni di `sshd_config` e utilizzare test di connettività di rete di base. Vengono forniti comandi pratici e consigli attuabili per risolvere rapidamente il problema e ripristinare l'accesso sicuro ai tuoi sistemi, assicurandoti di riprendere rapidamente il controllo.

47 visualizzazioni

Risolvere Rapidamente gli Errori di Connessione SSH Rifiutata

SSH (Secure Shell) è la spina dorsale della gestione remota dei server, consentendo una comunicazione sicura e crittografata tra la macchina locale e un server remoto. Tuttavia, incontrare un errore del tipo ssh: connect to host <INDIRIZZO_IP> port 22: Connection refused può essere un ostacolo frustrante, che impedisce l'accesso ai sistemi cruciali.

Questo articolo fornisce una guida completa, passo dopo passo, per diagnosticare e risolvere il comune errore 'Connection Refused'. Esploreremo le cause principali, dai daemon SSH inattivi ai firewall mal configurati e alle impostazioni del server errate, fornendoti le conoscenze e i comandi per riacquistare rapidamente l'accesso ai tuoi server.

Comprendere l'Errore 'Connection Refused'

Quando ricevi un errore Connection refused, significa che il tuo client SSH ha raggiunto con successo il server remoto, ma il server ha esplicitamente negato la connessione sulla porta specificata. Questo è diverso da un errore Connection timed out (dove il client non è riuscito a raggiungere il server affatto) o da un errore No route to host (dove il percorso di rete è interrotto).

Lo stato "refused" indica direttamente un problema lato server che impedisce attivamente al servizio SSH di accettare connessioni. Questo tipicamente comporta il daemon SSH non in esecuzione, un firewall che blocca la connessione, o una configurazione errata all'interno del servizio SSH stesso.

Cause Comuni di 'Connection Refused'

Diversi fattori possono portare al rifiuto di una connessione SSH. Comprendere questi fattori aiuta a restringere il processo di risoluzione dei problemi:

  • Daemon SSH (sshd) Non in Esecuzione: La causa più comune. Il processo del server SSH potrebbe essere crashato, essere stato fermato, o non essere riuscito ad avviarsi all'avvio.
  • Firewall che Blocca la Porta 22 (o porta personalizzata): Il firewall del server (es. UFW, firewalld, iptables) impedisce le connessioni in entrata sulla porta SSH.
  • Configurazione Errata del Daemon SSH: Il file sshd_config potrebbe essere mal configurato, portando il daemon SSH ad ascoltare su una porta diversa, un'interfaccia di rete sbagliata, o a rifiutare connessioni per utenti/metodi specifici.
  • Problemi di Connettività di Rete (Meno Comuni per 'Refused'): Sebbene meno probabile per un errore "refused", un problema di rete fondamentale potrebbe a volte manifestarsi inaspettatamente.
  • Restrizioni SELinux o AppArmor: Miglioramenti della sicurezza come SELinux o AppArmor potrebbero impedire a sshd di funzionare correttamente, specialmente dopo configurazioni personalizzate o modifiche di sistema.

Guida alla Risoluzione dei Problemi Passo Dopo Passo

Immergiamoci nei passaggi pratici per diagnosticare e risolvere l'errore 'Connection Refused'.

Passo 1: Verificare lo Stato del Daemon SSH sul Server

La prima cosa da controllare è se il daemon del server SSH (sshd) è effettivamente in esecuzione sulla macchina remota. Tipicamente avrai bisogno dell'accesso alla console (es. tramite la console di un provider cloud o una connessione fisica) per eseguire questi controlli se SSH è completamente inaccessibile.

  1. Verificare lo Stato del Daemon SSH:
    Sulla maggior parte delle distribuzioni Linux moderne (quelle che usano systemd come Ubuntu, CentOS 7+, Debian 8+):
    bash sudo systemctl status sshd
    Se sshd non è in esecuzione, l'output indicherà inactive (dead) o uno stato simile.

  2. Avviare il Daemon SSH:
    Se lo stato è inattivo, prova ad avviare il servizio:
    bash sudo systemctl start sshd

  3. Abilitare il Daemon SSH all'Avvio:
    Per assicurarti che SSH si avvii automaticamente dopo un riavvio, abilitalo:
    bash sudo systemctl enable sshd

  4. Controllare i Log del Daemon SSH:
    Se sshd non riesce ad avviarsi, i suoi log possono fornire indizi cruciali. Per i sistemi systemd:
    bash sudo journalctl -u sshd --since "10 minutes ago"
    In alternativa, controlla i log di autenticazione generali:
    bash sudo tail -f /var/log/auth.log # Oppure per RHEL/CentOS: sudo tail -f /var/log/secure

Passo 2: Controllare le Regole del Firewall

Un firewall lato server è spesso il responsabile dei rifiuti di connessione. Potrebbe bloccare la porta SSH predefinita (22) o una porta personalizzata che stai cercando di utilizzare. Devi assicurarti che il firewall consenta le connessioni in entrata sulla porta SSH.

  1. Identificare il Tuo Firewall:
    I firewall comuni includono:

    • UFW (Uncomplicated Firewall): Comune su Ubuntu/Debian.
    • firewalld: Comune su CentOS/RHEL 7+.
    • iptables: Il firewall sottostante per Linux, configurato direttamente o tramite front-end.

  2. Controllare lo Stato e le Regole del Firewall:

    • UFW:
      bash sudo ufw status verbose
      Cerca regole che consentano il traffico sulla porta 22 (o la tua porta SSH personalizzata). Se SSH è elencato, assicurati che sia ALLOWed (consentito).
    • firewalld:
      bash sudo firewall-cmd --list-all
      Controlla le sezioni services e ports per ssh o port 22/tcp.
    • iptables:
      bash sudo iptables -L -v -n
      Questo output può essere complesso. Cerca regole DROP o REJECT relative a tcp dpt:22 (o la tua porta personalizzata) nella catena INPUT.

  3. Consentire la Porta SSH tramite il Firewall:

    • UFW:
      bash sudo ufw allow ssh # Consente la porta 22 # Oppure, per una porta personalizzata (es. 2222): sudo ufw allow 2222/tcp sudo ufw enable # Se UFW è inattivo
    • firewalld:
      bash sudo firewall-cmd --permanent --add-service=ssh # Oppure, per una porta personalizzata (es. 2222): sudo firewall-cmd --permanent --add-port=2222/tcp sudo firewall-cmd --reload
    • iptables:
      Aggiungere regole iptables direttamente è più complesso e temporaneo a meno che non vengano salvate. Generalmente si raccomanda di usare firewalld o ufw se disponibili. Per un test rapido (non persistente):
      bash sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # Dovrai salvare queste regole se vuoi che persistano ai riavvii.

    Attenzione: Fai attenzione quando modifichi le regole del firewall, specialmente quando ti connetti via SSH a un server remoto. Regole errate possono bloccarti l'accesso in modo permanente. Verifica sempre che le tue modifiche funzionino prima di chiudere la sessione SSH corrente, se ne hai una aperta.

Passo 3: Verificare la Configurazione SSH (sshd_config)

Il file di configurazione del daemon SSH (/etc/ssh/sshd_config) detta il funzionamento del servizio. Errori di configurazione qui possono portare al rifiuto delle connessioni.

  1. Individuare sshd_config:
    Il file di configurazione principale si trova solitamente in /etc/ssh/sshd_config.

  2. Ispezionare le Impostazioni Chiave:
    Apri il file con un editor di testo (es. nano, vi):
    bash sudo nano /etc/ssh/sshd_config
    Cerca le seguenti direttive:

    • Port: Specifica la porta su cui sshd è in ascolto. Assicurati che corrisponda alla porta a cui stai cercando di connetterti dal tuo client. Se è commentata (#), il valore predefinito è la porta 22.
    • ListenAddress: Se presente, specifica su quali indirizzi IP sshd dovrebbe ascoltare. Se è impostato su un IP interno (es. 127.0.0.1) e ti stai connettendo da una rete esterna, rifiuterà la connessione. Per l'ascolto su tutte le interfacce, è spesso commentato o impostato su 0.0.0.0 o :: (per IPv6).
    • PermitRootLogin: Se impostato su no, non sarai in grado di accedere come root. Sebbene non sia un "rifiuto di connessione" nel senso più stretto (è spesso un permesso negato dopo la connessione), può impedire tentativi di accesso riusciti.
    • PasswordAuthentication: Se impostato su no, l'autenticazione tramite password è disabilitata, richiedendo l'autenticazione basata su chiave.

    Suggerimento: Dopo aver apportato modifiche a sshd_config, devi riavviare il servizio SSH affinché abbiano effetto:
    bash sudo systemctl restart sshd

Passo 4: Connettività di Rete (Controllo Base)

Sebbene un "rifiuto di connessione" significhi tipicamente che il server è stato raggiunto, è sempre bene confermare rapidamente la raggiungibilità di rete di base dalla macchina client all'indirizzo IP del server.

  1. Pingare il Server:
    Dalla tua macchina client, prova a pingare l'indirizzo IP o il nome host del server:
    bash ping <INDIRIZZO_IP_O_NOME_HOST_SERVER>
    Se il ping fallisce (100% di perdita di pacchetti), hai un problema di rete più fondamentale (es. IP errato, server offline, problema di routing di rete) che deve essere risolto prima di SSH.

  2. Usare nc o telnet (dal client):
    Per verificare se la porta è aperta e in ascolto dalla prospettiva del client:
    ```bash
    # Usando netcat (nc)
    nc -zv 22

    Usando telnet

    telnet 22
    `` SencmostraConnection refusedotelnet` esce immediatamente, conferma che il server sta attivamente rifiutando su quella porta, indicando nuovamente il daemon SSH o il firewall.

Passo 5: Controllare SELinux o AppArmor (Avanzato)

In alcuni ambienti rafforzati, o dopo configurazioni personalizzate, SELinux (Security-Enhanced Linux) o AppArmor potrebbero impedire a sshd di funzionare correttamente, specialmente se stai usando una porta SSH non standard.

  1. Controllare lo Stato di SELinux:
    bash sestatus
    Se SELinux è enforcing, potresti dover aggiustare le sue politiche per consentire a sshd su una porta personalizzata.
    Ad esempio, per consentire la porta 2222 per SSH:
    bash sudo semanage port -a -t ssh_port_t -p tcp 2222 sudo systemctl restart sshd
    (Installa semanage se non disponibile: sudo apt install policycoreutils-python-utils su Debian/Ubuntu, sudo yum install policycoreutils-python su CentOS/RHEL).

  2. Controllare lo Stato di AppArmor:
    bash sudo aa status
    Se AppArmor è enforcing, controlla i suoi log (/var/log/syslog o dmesg) per eventuali negazioni relative a sshd.

Passo 6: Rivedere i Log del Server (Ancora)

Dopo aver tentato i passaggi precedenti, controlla sempre di nuovo i log del server per eventuali nuovi messaggi di errore relativi a sshd. Questa è la tua fonte di verità definitiva per ciò che il server sta riscontrando.

  • sudo journalctl -u sshd
  • sudo tail -f /var/log/auth.log (o /var/log/secure)

Cerca messaggi che indicano perché il servizio potrebbe non avviarsi, perché le connessioni vengono interrotte o qualsiasi altra informazione rilevante.

Buone Pratiche per Prevenire Problemi Futuri

  • Aggiornare Regolarmente il Tuo Sistema Operativo: Mantieni aggiornati il sistema operativo e i pacchetti del tuo server, incluso openssh-server.
  • Testare le Regole del Firewall: Dopo aver implementato o modificato le regole del firewall, testale sempre immediatamente.
  • Eseguire il Backup di sshd_config: Prima di apportare modifiche a /etc/ssh/sshd_config, esegui un backup (sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak).
  • Usare una Console di Gestione: Per le istanze cloud, sappi come accedere alla console del server (es. AWS EC2 Serial Console, Google Cloud Console) per risolvere problemi di rete quando SSH non è disponibile.
  • Monitorare i Log: Rivedi regolarmente i log auth.log o secure per attività insolite o errori persistenti.

Conclusione

L'errore 'Connection Refused', sebbene frustrante, è solitamente semplice da risolvere controllando sistematicamente lo stato del daemon SSH, le regole del firewall e il file sshd_config. Seguendo i passaggi descritti in questa guida, puoi diagnosticare efficacemente la causa radice e ripristinare il tuo accesso remoto sicuro. Ricorda di applicare sempre le modifiche con cautela e verificare la funzionalità per evitare di bloccarsi fuori dal tuo server.

Con queste tecniche di risoluzione dei problemi, sarai ben equipaggiato per affrontare i problemi di connessione SSH e mantenere un controllo senza interruzioni sui tuoi sistemi remoti. Buon SSHing!