Come usare il comando telnet su Linux

Il comando telnet su Linux non è lì per fare da client “sicuro”: oggi lo si usa soprattutto per verificare connettività TCP, leggere un banner, capire se una porta risponde e isolare problemi su DNS, firewall, load balancer o servizio applicativo. In pratica è uno strumento da troubleshooting, non un protocollo da adottare per amministrare sistemi esposti in rete.

Se stai cercando di capire perché un sito, un SMTP, un Redis o un database non risponde, telnet resta comodo per una prova secca: apri una connessione verso una porta e osservi se il three-way handshake va a buon fine. Se la sessione si apre, il layer TCP è raggiungibile; se fallisce, il problema è a monte o sul servizio stesso. Da lì si passa ai log, ai firewall e alle metriche. La regola è semplice: prima osserva, poi cambi qualcosa.

Quando telnet è utile davvero

Su Linux telnet è utile in tre casi principali. Primo: testare la raggiungibilità di una porta TCP, ad esempio 25 per SMTP, 80 e 443 per HTTP, 143 per IMAP, 3306 per MySQL, 5432 per PostgreSQL. Secondo: leggere un banner o una risposta iniziale del servizio, quando il protocollo la espone. Terzo: interagire con servizi testuali molto semplici o legacy, dove un input manuale basta per verificare il comportamento base.

Non è il primo strumento che userei per tutto, però è ancora un buon “coltellino” da diagnostica. Per molte verifiche oggi è più comodo nc, curl o openssl s_client, ma telnet resta diffuso proprio perché fa una cosa sola e la fa in modo immediato: prova ad aprire una connessione TCP.

Installazione su Linux e verifica del binario

Su molte distribuzioni telnet non è installato di default. Il pacchetto può chiamarsi semplicemente telnet oppure essere separato tra client e server. Prima di usarlo, conviene verificare se il binario è presente e quale versione è disponibile.

Controllo rapido:

which telnet
 telnet -h 2>&1 | head

Se il comando non esiste, l’installazione dipende dalla famiglia della distro. Su Debian e Ubuntu:

sudo apt update
sudo apt install telnet

Su RHEL, AlmaLinux, Rocky o CentOS compatibili:

sudo dnf install telnet

Su Arch Linux:

sudo pacman -S inetutils

Su alcune distribuzioni il client telnet arriva nel pacchetto inetutils. Se il sistema è minimale, containerizzato o pensato per hardening, potresti non volerlo installare in modo permanente: in quel caso usalo solo su host di troubleshooting o in una sessione temporanea di manutenzione.

Sintassi base del comando telnet

La forma elementare è questa:

telnet host porta

Esempio verso un web server:

telnet example.com 80

Se la connessione riesce, vedrai qualcosa di simile a una connessione aperta con eventuale banner. Se fallisce, i casi tipici sono: connection refused se la porta è chiusa o il servizio non ascolta, no route to host se il routing o il filtro blocca, timed out se il pacchetto non riceve risposta. Questi tre esiti già ti dicono molto sul layer da guardare.

Un esempio più utile in diagnostica è verificare una porta SMTP su un mail server:

telnet mail.example.net 25

Se la sessione parte, spesso il server risponde con un banner del tipo 220. Da lì puoi digitare manualmente comandi SMTP come EHLO, MAIL FROM, RCPT TO. Non è il modo migliore per testare un flusso complesso, ma è perfetto per capire se il server parla proprio sulla porta giusta.

Cosa osservare quando la connessione fallisce

Il valore di telnet non sta nel “funziona/non funziona”, ma nel distinguere rapidamente il tipo di guasto. Se la porta rifiuta la connessione, di solito il servizio non è in ascolto o un firewall sta facendo reject. Se va in timeout, più spesso hai un drop a livello di rete, security group, ACL o un host spento. Se la connessione si apre e poi si chiude, il problema può essere applicativo: il servizio accetta TCP ma fallisce subito dopo l’handshake.

Per separare il problema di rete da quello di applicazione, conviene affiancare telnet a un controllo del socket in ascolto sul server. Sul nodo origin, per esempio:

ss -ltnp | grep ':80\|:443\|:25\|:3306\|:5432'

Se la porta non compare nell’output, il servizio non sta ascoltando. Se compare ma telnet dall’esterno fallisce, il colpevole è spesso il firewall locale, un security group cloud, un ACL di rete o un bilanciatore configurato male. In produzione non è una differenza accademica: cambia completamente il punto in cui intervenire.

Telnet come test rapido per HTTP, SMTP, IMAP e database

Con HTTP si può usare telnet per inviare una richiesta manuale molto semplice. È un test grezzo, ma utile quando vuoi vedere se il server risponde davvero a livello applicativo e non solo TCP.

telnet example.com 80
GET / HTTP/1.1
Host: example.com
Connection: close

La riga vuota finale è importante: chiude gli header HTTP e induce il server a rispondere. Se ricevi una pagina o un codice di stato, il percorso fino all’app è vivo almeno in quel punto. Se invece la sessione si blocca o si chiude subito, il problema può essere sul reverse proxy, sul virtual host o sul backend.

Per SMTP la sequenza è ancora più naturale. Dopo la connessione su porta 25, il server espone spesso un banner e puoi testare il dialogo base:

telnet mail.example.net 25
EHLO test.local
MAIL FROM:<sender@example.net>
RCPT TO:<dest@example.org>
DATA
Subject: test

messaggio di prova
.
QUIT

Questo non sostituisce un test completo di consegna, ma chiarisce subito se il server accetta il canale e se il path SMTP base è aperto. Per IMAP o POP3 il principio è simile: connessione, banner, comando di saluto, eventuale autenticazione test. Anche qui, però, telnet non gestisce cifratura, autenticazione moderna o flussi complessi in modo elegante.

Per database e servizi di backend, telnet serve soprattutto a stabilire se la porta è raggiungibile. Non ti dice se il database è sano, se l’utente è valido o se il motore è sotto carico; ti dice solo che il socket risponde. Per questo è utile come primo filtro, non come diagnosi finale.

Telnet e TLS: dove si ferma lo strumento

Qui c’è un punto che genera confusione. Telnet non negozia TLS. Se provi a usarlo su una porta che richiede cifratura nativa, come 443 o 993, vedrai al massimo che la porta è aperta, ma non riuscirai a parlare il protocollo in chiaro. Questo non è un bug: è il limite dello strumento.

Per testare servizi TLS usa invece strumenti adatti, per esempio:

openssl s_client -connect example.com:443 -servername example.com

Se l’obiettivo è verificare il certificato, il SNI, la catena o la negoziazione del protocollo, telnet non è il mezzo giusto. Può però restare utile per vedere se la porta TCP è aperta prima ancora di passare alla fase TLS.

Uso pratico nel troubleshooting di un sito giù

Quando un sito è irraggiungibile, telnet entra bene nel primo giro di verifica. Se il client non raggiunge neppure la porta del web server, il problema non è PHP, non è il CMS e spesso non è nemmeno il database. Prima di inseguire errori applicativi, conviene capire se l’origin risponde davvero.

Flusso minimo ragionato:

1. Verifica DNS con dig o host per assicurarti che il nome punti all’IP atteso.
2. Prova la porta con telnet host 80 o telnet host 443 per distinguere tra reachability e problema applicativo.
3. Se la porta risponde, passa a curl -I o a un controllo più specifico del protocollo.
4. Se la porta non risponde, verifica firewall, security group, load balancer, stato del servizio e ascolto locale con ss -ltnp.

Questo approccio evita il classico errore di saltare subito al livello applicativo. In un’infrastruttura ben fatta, i guasti si leggono dal layer più basso disponibile. Telnet aiuta proprio a non confondere un problema di rete con un problema di codice.

Limiti operativi e alternative più moderne

Telnet ha limiti evidenti. Non supporta TLS in modo nativo, non gestisce bene protocolli complessi, non è pensato per autenticazioni moderne e non offre il livello di ergonomia di strumenti più recenti. Inoltre, su host esposti o hardenizzati, installarlo senza motivo aumenta la superficie software, anche se in modo marginale.

Le alternative più usate sono:

• nc o ncat per test generici su porte TCP e UDP.
• curl per HTTP e HTTPS con più controllo sugli header e sul TLS.
• openssl s_client per servizi cifrati.
• ssh per amministrazione remota, quando il caso d’uso è autenticato e sicuro.

Detto questo, telnet ha ancora un vantaggio: è quasi universale nella cultura operativa. Molti tecnici lo riconoscono al volo, la sintassi è immediata e il comportamento è facile da interpretare. In un ticket urgente, questa semplicità vale più di una suite più ricca ma meno immediata.

Debug di servizi testuali con telnet: esempi concreti

Un caso classico è il controllo di un relay SMTP dietro firewall. Se il server accetta connessioni solo dalla rete interna, puoi testare dal nodo applicativo o da un host di jump. La connessione con telnet ti dice subito se la porta è aperta, mentre i comandi SMTP successivi ti dicono se il server accetta il dialogo almeno fino a un certo punto.

Altro esempio: un monitoraggio esterno segnala timeout su una porta custom, ad esempio 8080 o 9000. Prima di aprire ticket al team applicativo, fai un test semplice:

telnet app.example.net 8080

Se la connessione parte ma il servizio non manda banner, può essere normale: non tutti i servizi parlano per primi. In quel caso, la verifica corretta è provare una richiesta del protocollo atteso o usare lo strumento dedicato. Il punto è che telnet ti ha già detto se la porta è viva.

Per i team che gestiscono ambienti misti, telnet torna utile anche come test di rete “a basso attrito” da un host all’altro. Non richiede preparazione, non dipende da librerie applicative e non ti costringe a installare un agente o a cambiare il codice. In scenari di emergenza, questa neutralità è un vantaggio.

Buone pratiche operative e sicurezza

Usa telnet come strumento di diagnosi, non come metodo di amministrazione remota. Il protocollo trasmette tutto in chiaro: credenziali, comandi, dati. Su reti non fidate è una scelta sbagliata. Se ti serve accesso interattivo, usa SSH. Se ti serve testare un servizio cifrato, usa un client compatibile con TLS.

Dal punto di vista della sicurezza operativa, il consiglio è semplice: installa telnet solo dove serve, rimuovilo se non è più necessario e non aprire porte telnet server verso Internet. In un ambiente moderno il server telnet non dovrebbe essere esposto; il client può servire localmente per troubleshooting, ma va considerato un tool temporaneo e non un componente base dell’host.

Un’altra abitudine utile è registrare sempre il contesto del test: host, porta, ora, esito, IP risolto, eventuale NAT o CDN davanti. Senza questi dati, un “telnet non va” è poco più di un’impressione. Con quei dettagli, invece, puoi capire se il problema è nel DNS, nel bilanciatore, nel firewall o nel servizio stesso.

Workflow consigliato quando vuoi usare telnet bene

Se vuoi usarlo in modo professionale, tieni un flusso standard. Prima identifica il target e la porta. Poi esegui il test TCP con telnet. Se la porta risponde, passa al protocollo reale con lo strumento giusto. Se non risponde, risali di un livello alla volta: socket locale, firewall, rete, bilanciatore, DNS. Questo evita diagnosi affrettate e riduce il tempo perso su falsi colpevoli.

In pratica, telnet è utile perché fa emergere una verità semplice: la rete arriva o non arriva. Tutto il resto viene dopo. In ambienti Linux, dove spesso la complessità non manca, avere un test minimale e leggibile è ancora un vantaggio operativo concreto.

Se lo usi con questa mentalità, telnet resta un comando valido anche oggi: non per sostituire gli strumenti moderni, ma per fare da primo spartiacque tra problema di trasporto e problema applicativo. Ed è spesso proprio quel confine a fare la differenza durante un intervento urgente.