PuTTY mostra Connessione rifiutata : correggere il guasto

In PuTTY, il messaggio « Network error: Connection refused » indica che l’apertura della connessione TCP è stata rifiutata. Il client non ha ancora raggiunto la fase della password o della chiave SSH. Il rifiuto può provenire dalla macchina di destinazione, ma anche da un firewall, da un gateway o da un reindirizzamento configurato in modo errato: questo messaggio non prova quindi, da solo, che il server giusto ha risposto.

Procedete dal client verso il server: identificare la destinazione, controllare la porta, quindi verificare l’ascolto e il filtraggio da una console indipendente. Non riavviate il server e non modificate il firewall « per provare ». Se non avete una console di emergenza o un accesso già aperto, fermatevi prima di apportare qualsiasi modifica lato server e chiedete aiuto all’amministratore.

Confermare che si tratta effettivamente di un rifiuto TCP

Annotate il testo esatto visualizzato da PuTTY, l’ora del tentativo e la sessione utilizzata. Nel menu della finestra PuTTY, aprite l’Event Log e annotate l’host, la porta e l’eventuale presenza di un proxy. Nascondete i nomi interni e gli indirizzi prima di trasmettere queste informazioni. Il manuale PuTTY distingue esplicitamente Connection refused da Connection timed out.

• Connection refused: il tentativo TCP riceve un rifiuto, spesso un pacchetto RST. Il rifiuto può essere emesso dall’hôte o da un dispositivo intermedio configurato per rifiutare.
• Connection timed out: nessuna risposta utile arriva entro il termine. Un filtraggio silenzioso di tipo DROP, una rotta, un indirizzo errato o un dispositivo non disponibile possono portare a questo risultato. Non è la stessa diagnosi; il dettaglio del timeout è riservato a una guida separata.
• Server refused our key: la connessione SSH ha raggiunto la fase di autenticazione tramite chiave, ma il server non accetta questa chiave per questo account. Verificare quindi i parametri della chiave e l’account; consultare la guida per utilizzare una chiave SSH con PuTTY. Cambiare chiave non correggerà un rifiuto TCP iniziale.

Un ping non consente di decidere: ICMP e la porta TCP di SSH possono essere filtrati in modo diverso. Un ping senza risposta non dimostra quindi che SSH è non funzionante, e un ping riuscito non convalida la porta SSH.

Controllare l’hôte e la porta in PuTTY

In PuTTY, caricate la sessione interessata e confrontate i suoi campi con le informazioni fornite dall’host o dall’amministratore: Host Name deve contenere il nome o l’indirizzo, senza prefisso https://; il tipo di connessione deve essere SSH; la porta deve essere la porta SSH effettivamente pubblicata. Non presume che sia sempre la porta 22. Se corrite un valore, salvate la sessione solo dopo aver confermato la giusta destinazione. Per i parametri di base di una sessione, fate riferimento alla guida verificare i parametri della vostra sessione PuTTY.

Dal PowerShell di Windows, sostituire il nome e la porta di esempio con quelli della vostra sessione:

Resolve-DnsName server.example.net
Test-NetConnection -ComputerName server.example.net -Port 22 -InformationLevel Detailed

Resolve-DnsName mostra gli indirizzi associati al nome; confrontateli con la destinazione attesa. Test-NetConnection testa la porta TCP indicata: TcpTestSucceeded : True significa che questo test ha stabilito la connessione TCP, non che l’identità del server o l’autenticazione SSH siano convalidate. Un valore False non è sufficiente a distinguere tra rifiuto e timeout: conservare il messaggio PuTTY esatto. Se PuTTY utilizza un proxy o un VPN, questo test diretto può percorrere un altro percorso; i due risultati non sono quindi direttamente confrontabili.

Da un client Linux che siete autorizzati a utilizzare, potete anche testare solo la porta mirata, se netcat è installato:

nc -vz -w 3 server.example.net 22

Sostituisci i due valori. Le opzioni -z e -v richiedono un test di connessione senza scambio applicativo e un risultato leggibile; -w 3 limita l’attesa a tre secondi. Le varianti di netcat differiscono: se l’opzione non è riconosciuta, consultate nc -h e adattatevi alla versione installata, senza testare un intervallo di porte. Una connessione stabilita conferma l’accesso TCP da questo client; un rifiuto supporta la pista del rifiuto; un’attesa scaduta apre un altro ramo di diagnostica. Vedi anche la guida per testare una porta TCP con netcat.

Controllare il servizio da una console Linux

Questa fase viene eseguita nella console dell’host, della macchina virtuale o davanti al server, non nella sessione PuTTY che fallisce. Mantenete questa console e qualsiasi sessione di amministrazione già aperta: sono il vostro mezzo di ritorno se una modifica interrompe l’accesso. Il nome dell’unità varia a seconda della distribuzione e della modalità di avvio.

systemctl list-unit-files 'ssh*' --no-pager
sudo systemctl status ssh.service --no-pager
sudo systemctl status sshd.service --no-pager
sudo systemctl status ssh.socket --no-pager

Il primo comando inventaria le unità il cui nome inizia con ssh. Controllate poi l’unità realmente presente: ssh.service è comune su Debian e Ubuntu; sshd.service lo è spesso su Fedora e RHEL; alcuni sistemi utilizzano un’attivazione tramite ssh.socket. « Unit not found » indica solo che questo nome di unità non esiste su questa macchina. Un’unità attiva non prova che la porta richiesta ascolti sull’interfaccia giusta. Con attivazione tramite socket, systemd può accettare la connessione e avviare il servizio su richiesta. In un sistema senza systemd, utilizzare gli strumenti della sua distribuzione invece di trasporre questi comandi.

Se non è installato alcun server SSH, confermare prima con l’amministratore che questa macchina deve effettivamente fornire SSH. Installare un pacchetto server è giustificato solo in questo caso e secondo la procedura di distribuzione; non è una riparazione universale di una porta errata o di un rifiuto di rete.

Verificare la porta e l’indirizzo di ascolto effettivo

Sempre dalla console Linux, osservate le interfacce, le socket TCP in ascolto e la configurazione SSH:

ip -br address
sudo ss -ltnp
sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T

ip -br address mostra gli indirizzi locali; un server dietro un NAT generalmente non mostra il suo indirizzo pubblico. In ss -ltnp, -l limita l’output alle socket in ascolto, -t a TCP, -n mantiene le porte numeriche e -p indica il processo quando è disponibile. Individuate la porta attesa e il processo proprietario, che può essere systemd se il socket è attivato.

Interpretare l’indirizzo così come la porta. Un ascolto su 127.0.0.1:22 è limitato al loopback locale; un indirizzo LAN preciso non copre le altre interfacce. 0.0.0.0 designa tutte le interfacce IPv4; un ascolto su [::] riguarda IPv6 e non garantisce da sola l’accesso IPv4. Se nulla ascolta sulla porta alla quale il traffico arriva, non cominciate ad aprire il firewall: non c’è quindi alcun servizio su questa destinazione.

sshd -t verifica la sintassi e le chiavi host senza avviare o riavviare il servizio. Un’esecuzione valida normalmente non produce messaggi e restituisce un codice di successo; un messaggio di errore deve essere corretto prima di qualsiasi azione sul servizio. sshd -T mostra la configurazione effettiva dopo lettura e convalida, inclusi i valori di porta e indirizzo di ascolto. Non diffondete la sua uscita completa senza rileggerla e nascondere i dettagli sensibili. Il manuale ufficiale descrive le opzioni sshd(8) e le direttive Port e ListenAddress. Queste pagine documentano OpenSSH; i percorsi e le unità variano a seconda di Linux. Su una configurazione che utilizza ssh.socket, confrontate anche i risultati di ss con l’unità attiva: l’uscita di sshd -T da sola non prova ciò che la socket systemd espone realmente.

Modificate Port o ListenAddress solo dopo aver identificato una cattiva impostazione e salvato la configurazione pertinente. Confermare quale interfaccia deve essere accessibile; non ampliare l’ascolto a tutte le interfacce per impostazione predefinita. Prima di qualsiasi modifica o ricarica, tenere aperte la console di emergenza e l’accesso esistente. Ubuntu richiama le precauzioni legate alla configurazione del server nella sua documentazione OpenSSH Server.

Confrontare il filtraggio locale, la rete e il NAT

Se la porta ascolta sull’interfaccia giusta ma il test esterno è rifiutato, identificare prima il gestore del firewall realmente utilizzato e il percorso del traffico. I comandi qui sotto sono in sola lettura: eseguire solo quello che corrisponde al vostro sistema.

sudo ufw status verbose
sudo nft list ruleset
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=public --list-all

UFW, nftables e firewalld non sono intercambiabili. Un comando assente non prova che non ci sia alcun filtraggio. Con firewalld, public è solo un esempio di zona: identificate la zona associata all’interfaccia, quindi esaminate le regole, il loro ordine, il protocollo TCP, la porta, le fonti autorizzate e le azioni di rifiuto. Non combinare più gestori per applicare modifiche e non disattivare il firewall per testare.

Controllare poi, in sola lettura, le regole del firewall cloud o dell’host: porta pubblicata, protocollo e indirizzi fonti autorizzati. Se il server è dietro un router, controllare il reindirizzamento della porta esterna verso il corretto indirizzo privato e la porta realmente in ascolto. Ad esempio, un reindirizzamento concettuale della porta esterna 2222 verso la porta interna 22 implica che PuTTY si connetta alla porta 2222 da Internet, mentre ss visualizza la porta 22 sul server. Controllare anche che l’indirizzo privato della macchina non sia cambiato. Se è previsto un VPN o un bastione, privilegiate questo percorso invece di esporre SSH a tutto Internet.

Un test dalla stessa rete locale verso l’indirizzo pubblico dipende dal supporto del NAT loopback da parte del router; non sostituisce un test esterno autorizzato. L’assenza di risposta legata al routing, a un indirizzo pubblico o a CGNAT porta spesso al ramo del timeout: non provate ad aggirarlo aprendo porte senza convalida.

Applicare una sola correzione provata, quindi ritestare

• Host o porta errati nella sessione: correggere solo la destinazione client confermata dall’amministratore.
• Servizio assente mentre SSH deve essere fornito: far convalidare l’installazione e l’attivazione secondo la distribuzione.
• Servizio fermo, configurazione valida, unità corretta e accesso console assicurato: un avvio controllato può essere appropriato.
• Indirizzo di ascolto errato: correggere solo il bind confermato e verificare prima la configurazione.
• Regola di rifiuto dimostrata: chiedere o applicare una regola limitata alla porta SSH, al protocollo e alle fonti necessarie.
• Reindirizzamento errato: correggere la destinazione privata o la porta esterna dopo conferma del percorso atteso.

Per un servizio systemd realmente fermo, solo se il server deve fornire SSH, se sshd -t ha avuto successo, se l’unità è ben quella utilizzata e se la console di emergenza è accessibile, l’avvio controllato può essere:

sudo systemctl start ssh.service

Sostituire ssh.service con sshd.service se è l’unità presente; non avviare entrambi e non avviare un servizio in concorrenza con una socket di attivazione. Questo comando cambia lo stato della macchina: non deve servire come primo test. Dopo una modifica di configurazione, verificare prima il meccanismo di ricarica supportato dalla vostra distribuzione e la sua unità; non è raccomandato alcun riavvio automatico qui. La documentazione ufficiale di Ubuntu ricorda che una modifica SSH può bloccare l’accesso: mantenete quindi la sessione aperta e la console di emergenza durante il controllo.

Dopo ogni correzione, procedere separatamente: rileggere ss -ltnp lato server, quindi aprire una nuova finestra PuTTY verso l’host e la porta corretti. Se PuTTY presenta una nuova impronta dell’host, verificate attraverso un canale affidabile prima di accettarla. Raggiungere il banner SSH o la schermata di autenticazione significa che il rifiuto TCP è stato rimosso; non significa che l’account sia già autentificato. Mantenere l’accesso di emergenza fintanto che questa nuova connessione non è andata a buon fine.

Non utilizzare ufw disable, nft flush ruleset o iptables -F. Non aprire SSH globalmente senza restrizione della sorgente, non aggirare il problema attivando la connessione root e non indebolire né le autorizzazioni SSH né l’autenticazione multi-fattore.

Consultare i registri se il rifiuto persiste

Dal console Linux, scegliere l’unità realmente presente e esaminare una finestra recente attorno all’ora annotata in PuTTY:

sudo journalctl -u ssh.service -n 50 --no-pager
sudo journalctl -u sshd.service -n 50 --no-pager
sudo journalctl -u ssh.socket -n 50 --no-pager

Eseguire solo il comando corrispondente all’unità esistente. Cercare un errore di configurazione, un indirizzo non disponibile o una porta già occupata. A seconda della distribuzione e della sua registrazione, file come /var/log/auth.log o /var/log/secure possono integrare il registro; non sono presenti ovunque. Un rifiuto prima dell’instaurazione di SSH potrebbe non lasciare alcuna voce di autenticazione. Allo stesso modo, un rifiuto da parte di un router o di un firewall cloud potrebbe non apparire in journalctl: l’assenza di una riga non prova l’assenza di tentativo.

Se amministrate il server e disponete di tcpdump, una cattura molto corta può aiutare a localizzare il rifiuto. Sostituisci l’indirizzo di documentazione con l’indirizzo sorgente effettivamente visto sul server, che potrebbe differire dopo NAT; catturate solo su una macchina e una rete che siete autorizzati a diagnosticare.

sudo timeout 10 tcpdump -ni any -c 20 'tcp port 22 and host 192.0.2.10'

timeout 10 limita la cattura a dieci secondi; -c 20 la ferma dopo venti pacchetti al massimo; -n evita la risoluzione dei nomi e -i any ascolta le interfacce disponibili. L’esempio è indirizzato alla porta interna 22: adattate il filtro alla porta osservata. Un SYN in entrata seguito da un RST su questo punto di cattura rinforza un rifiuto in questo punto, senza identificare automaticamente il dispositivo responsabile. Nessun pacchetto catturato può anche derivare da una cattiva interfaccia, da un filtro errato o da un altro percorso di rete. Non catturare il contenuto con opzioni di decodifica del payload, non conservare un file di cattura permanente e nascondere indirizzi e orari prima di condividere i risultati.

Se non avete né console indipendente né autorizzazione per ispezionare il firewall, non continuate le modifiche da remoto. Trasmettete all’amministratore l’host e la porta mirati, l’ora, il messaggio PuTTY esatto e i test effettuati, dopo aver espurgato le informazioni interne.