>_cmd.script

telnet

Connect to a remote host/port over unencrypted Telnet

Networking

By CMD Script Team · 4 min read · Last updated

SYNTAX
telnet [OPTIONS] host [port]

Options

Command options and flags
FlagDescription
hostHostname or IP address of the remote system or service to connect to
portTCP port to connect to (defaults to 23, the Telnet service port)
-lSpecify the username to log in as on the remote host
-eSet the escape character used to get back to the telnet prompt
-4Force IPv4 only
-6Force 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 listening
  • telnet example.com — connect to the default Telnet port (23), which is rarely running a real service on modern systems
  • telnet mail.example.com 25 — connect to an SMTP server and view its greeting banner
  • Type quit after 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 telnet for 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 443 and 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 port is one of the fastest ways to answer "is this port open and something listening" without installing extra tools.
  • If telnet isn't installed (increasingly common by default), nc -zv host port or curl -v telnet://host:port can 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 telnetd server 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.