Use GNU Telnet for a Controlled Interactive TCP Session

telnet opens a raw TCP session so you can watch exactly what a service negotiates, byte for byte. These examples match GNU Inetutils telnet 2.5, supplied by package inetutils-telnet version 2:2.5-3ubuntu4.2.

Allow about fifteen minutes. You need a shell, the telnet command, a hostname or address you are authorised to test, and a known TELNET service port. TELNET sends application data with no modern transport confidentiality: do not use it for passwords or administration over an untrusted network, and use SSH instead when the service supports it.

1. Confirm the installed client

Start with read-only checks; nothing here needs elevated privileges:

$ command -v telnet
/usr/bin/telnet
$ telnet --version
telnet (GNU inetutils) 2.5

The package also installs the canonical inetutils-telnet name on this system. telnet is the familiar interface, and both names report the same GNU Inetutils version here. If your output differs, treat the installed manual page as the contract for that host.

2. Open a service deliberately

A direct invocation performs an open. Put the host and port in obvious placeholders, and start with a service you control:

$ telnet TELNET_HOST 2323
Trying 192.0.2.20...
Connected to TELNET_HOST.
Escape character is '^]'.

Swap in real values for TELNET_HOST and 2323. Port 23 is the conventional TELNET port, but the manual page allows an explicit port for another service, and the exact address and connection messages vary. A refusal, timeout or name-resolution error just means the network path or service is unavailable, not that the client is broken.

Use the address-family options when the result needs to be reproducible:

$ telnet --ipv4 TELNET_HOST 2323
$ telnet --ipv6 TELNET_HOST 2323

These pin IPv4 or IPv6. They do nothing to make an insecure TELNET exchange safe.

3. Keep the escape character visible

While connected, press Ctrl-] to reach the client's own command prompt. The default escape character shows when the connection opens:

telnet>

That prompt is local, not something coming from the remote host. Keeping that straight avoids a common mistake: typing a client command into the remote application, or typing remote credentials into the client by accident.

From the prompt, inspect the session:

telnet> status
Connected to TELNET_HOST.
Operating mode: character-at-a-time

The exact wording depends on the negotiated options and the remote implementation. status reports the peer and current mode; reach for display when the local option and special-character state is confusing you.

If Ctrl-] is inconvenient, choose a different initial escape character with -e, or turn escape recognition off entirely with -E. Only disable it once you already have another way to kill the process: it removes your ordinary route back to the client prompt.

4. Test a protocol response without changing the service

Some TELNET servers respond to protocol probes, some do not. From the client prompt, send an Are You There request:

telnet> send ayt

The remote side may answer, ignore it, or send back something service-specific. Silence is not proof the connection is dead. For a more useful application test, type whatever the service documentation actually specifies, and treat any returned prompt as untrusted input.

send also supports ip for Interrupt Process, ao for Abort Output, ec for Erase Character, el for Erase Line, nop for No Operation, and getstatus for a status request when the server supports it. These are TELNET protocol sequences; nothing guarantees the remote program actually honours them.

5. Make terminal behaviour predictable

GNU telnet tries to negotiate LINEMODE right after connecting. If the peer cannot offer it, the client falls back to character-at-a-time or old line-by-line operation, which is why a typed character can appear instantly in one session but wait for Return in another.

Check the current state before changing anything:

telnet> display
telnet> mode
telnet> help mode

Reach for mode character or mode line only when the service actually requires a particular input style. In old line-by-line mode, local echo matters, especially at a password prompt: a remote password prompt is no proof that echo is safely suppressed. Do not type a real password over plain TELNET.

For binary data, start a fresh session with --binary, or use toggle binary at the client prompt. --binary-output only changes output negotiation. None of these touch encryption.

6. Avoid startup surprises and sensitive traces

On connecting, the client may read ~/.telnetrc, which can contain machine-specific commands processed as though you had typed them yourself. For a clean diagnostic session, use:

$ telnet --no-rc TELNET_HOST 2323

The short form is -c. It skips local startup commands, but does nothing to constrain the remote service or make the connection trustworthy.

$ less -- TRACE_FILE
$ rm -- TRACE_FILE

That removal is irreversible, though it needs no elevated privilege for a file you own. Do not run it against a path you did not create or inspect yourself.

7. Close the session cleanly

Return to the telnet> prompt with Ctrl-], then close the remote session and exit:

telnet> close
telnet> quit

quit also closes an open session on its own. Use the remote application's own logout command first if it has one. In rlogin mode the escape character defaults to tilde instead, so a line starting ~. disconnects and ~^Z suspends the client: do not rely on those in ordinary mode, where the escape character is normally Ctrl-].

Common failure points

• Connection refused. Check the host, port and service listener. Do not add sudo: ordinary telnet connections need no elevated privileges.
• Can't reach the client prompt. Press Ctrl-] as a control character, not the two typed characters caret and right bracket. If you changed the escape character, use that value instead.
• Characters echo strangely. Check status, display and mode. The peer may not support LINEMODE, or local echo may need adjusting. Avoid entering secrets while you are diagnosing it.
• Connects but login fails. TELNET transport success only proves something accepted the TCP connection. Authentication, application protocol and remote policy are all separate checks.