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.
Start with read-only checks; nothing here needs elevated privileges:
$ command -v telnet
/usr/bin/telnet
$ telnet --version
telnet (GNU inetutils) 2.5The 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.
Checkpoint: make sure you are testing the intended binary and know its version before comparing output against this guide.
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 2323These pin IPv4 or IPv6. They do nothing to make an insecure TELNET exchange safe.
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-timeThe 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.
Some TELNET servers respond to protocol probes, some do not. From the client prompt, send an Are You There request:
telnet> send aytThe 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.
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 modeReach 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.
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 2323The short form is -c. It skips local startup commands, but does nothing to constrain the remote service or make the connection trustworthy.
Warning: do not turn tracing on casually. --trace TRACE_FILE records trace information, and the netdata, options and termdata toggles can expose protocol or terminal data. If you created a trace file, check it before removing it:
$ less -- TRACE_FILE
$ rm -- TRACE_FILEThat 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.
Return to the telnet> prompt with Ctrl-], then close the remote session and exit:
telnet> close
telnet> quitquit 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-].
sudo: ordinary telnet connections need no elevated privileges.Ctrl-] as a control character, not the two typed characters caret and right bracket. If you changed the escape character, use that value instead.status, display and mode. The peer may not support LINEMODE, or local echo may need adjusting. Avoid entering secrets while you are diagnosing it.telnet> prompt.