telnet
Connect to a remote host/port over unencrypted Telnet
By CMD Script Team · 4 min read · Last updated
telnet [OPTIONS] host [port]Options
| Flag | Description |
|---|---|
host | Hostname or IP address of the remote system or service to connect to |
port | TCP port to connect to (defaults to 23, the Telnet service port) |
-l | Specify the username to log in as on the remote host |
-e | Set the escape character used to get back to the telnet prompt |
-4 | Force IPv4 only |
-6 | Force IPv6 only |
Distribution compatibility
- Ubuntu (telnet package, not preinstalled)
- Debian (telnet package)
- Fedora (telnet package)
- Arch (inetutils)
- macOS (not preinstalled; install via Homebrew)
What it does
telnet opens a connection to a remote host on a given TCP port using the Telnet
protocol, historically used for remote terminal login. The protocol transmits all data
— including login credentials — completely unencrypted, which is why it has been
almost entirely replaced by ssh for remote login. Despite that, the telnet client
survives as a handy, minimal tool for manually testing whether a raw TCP port is open
and for eyeballing the banner or initial response of plain-text protocols like HTTP,
SMTP, or POP3.
Beginner examples
telnet example.com 80— open a raw TCP connection to port 80 to check if a web server is listeningtelnet example.com— connect to the default Telnet port (23), which is rarely running a real service on modern systemstelnet mail.example.com 25— connect to an SMTP server and view its greeting banner- Type
quitafter pressing the escape character (Ctrl+]) to close the session
telnet example.com 80
Advanced examples
- Manually issue an HTTP request to inspect raw server behavior:
telnet example.com 80 GET / HTTP/1.1 Host: example.com - Check whether a database port is reachable from an application server before
debugging a connection-refused error:
telnet db-host 5432 - Force IPv4 or IPv6 explicitly when diagnosing dual-stack connectivity issues:
telnet -6 example.com 443 - Specify a login username for a legacy telnet daemon (rare today):
telnet -l alice legacyhost
telnet -4 internal-service.local 8080
Common mistakes
- Using
telnetfor actual remote login/administration on a production system — credentials sent this way are trivially sniffable on any shared network segment. - Assuming a "Connection refused" means the host is down, when it usually just means nothing is listening on that specific port (the host itself may be perfectly reachable).
- Forgetting the escape sequence (
Ctrl+]) and trying to Ctrl+C out of a hung connection, which can leave the session in a weird state. - Testing HTTPS ports with
telnet host 443and being confused when it "hangs" — telnet can open the TCP connection but doesn't speak TLS, so it can't complete a real HTTPS handshake.
Tips
telnet host portis one of the fastest ways to answer "is this port open and something listening" without installing extra tools.- If
telnetisn't installed (increasingly common by default),nc -zv host portorcurl -v telnet://host:portcan serve the same raw-connectivity-check purpose. - Watching the initial banner text a service sends back over telnet can quickly reveal its software and version, which is useful during troubleshooting (and during security assessments).
Best practices
- Never use telnet for interactive remote login or administration — always use
ssh, which encrypts the entire session. - Disable and uninstall the
telnetdserver on any system that doesn't have an explicit, isolated reason to run it. - When using the telnet client purely for port/connectivity testing, treat it as a read-only diagnostic tool, not a way to authenticate to anything.
Try it yourself
A simulated shell with a sample home directory — experiment freely, nothing leaves your browser. Type help to list supported commands.
Real-world use cases
- Quickly confirming a firewall rule or security group change actually opened the
intended port:
telnet new-server 8443. - Manually inspecting a plain-text protocol's handshake (SMTP, POP3, HTTP/1.1) during debugging, by typing protocol commands directly into the session.
- Diagnosing "works from my machine, not from the server" issues by testing raw TCP reachability from the affected host itself.
Common interview questions
- Why shouldn't you use telnet for remote administration? Because it transmits everything, including credentials, in plain text, making it trivial to intercept on any network segment between client and server.
- What's a legitimate modern use for the telnet client? Testing raw TCP port connectivity and viewing plain-text service banners (SMTP, HTTP, etc.), not logging into systems.
- What replaced telnet for remote login, and why?
ssh, because it provides the same interactive remote-session functionality but encrypts the entire connection and supports strong key-based authentication.
Frequently Asked Questions
Is it safe to use telnet for remote login?
No. Telnet sends everything, including usernames and passwords, in plain text, so anyone on the network path can capture credentials. For remote login and shell access, use ssh instead.
Why do people still use telnet at all?
Mostly as a quick, dependency-free way to test raw TCP connectivity to a specific port, e.g. telnet mailserver 25 to check if an SMTP port is open and see the service's banner, without needing a protocol-specific client.
What's the difference between telnet and nc (netcat) for port testing?
Both can open a raw TCP connection, but telnet is more universally preinstalled historically and shows a connection banner clearly, while nc is more flexible for scripting, UDP testing, and sending arbitrary data.
How do I exit a telnet session?
Type the escape character (Ctrl+] by default) to get back to the telnet> prompt, then type quit — or if the remote service has its own logout command (like QUIT for SMTP), use that.
Cheat sheet
Download a quick-reference cheat sheet for telnet.