Choose a Telnet client

Start by checking whether a Telnet client is already installed:

telnet

If you see a telnet> prompt, you have a client. Type quit and press Enter to leave. If the shell answers command not found, you need to install one.

Some operating systems include one. Others make it an optional package. macOS stopped bundling a Telnet client, and many Linux distributions leave it out of the default install:

# macOS
brew install telnet

# Debian / Ubuntu
sudo apt install telnet

Use the package supplied by your operating system, or a maintained client you can verify. This is a diagnostic tool that touches your network traffic. Don’t grab a random binary from the web.

Two rules for this course

First, connect only to loopback services you start yourself or systems you are authorized to inspect. Poking at other people’s ports is at best rude and at worst illegal.

Second, do not send a password through a plaintext Telnet session. Not once, not “just to check”. Every byte you type crosses the network readable.

Why a Telnet client at all

The client is useful beyond remote login because it lets you type into a TCP connection and read the response. That is the whole trick. You see the exact bytes a text protocol exchanges, with no library hiding them.

It is not the only tool for this. Netcat is often a better raw TCP tool, because it sends exactly what you type and nothing else:

nc 127.0.0.1 2323

A Telnet client may inject protocol negotiation bytes into the stream. Netcat never does. We will use that difference deliberately in a later lesson.

When the service requires TLS, neither tool helps on its own. OpenSSL is the right starting point there:

openssl s_client -connect example.com:443

It performs the TLS handshake, then gives you the same type-and-read session on the decrypted stream.

My advice is to have all three installed. Telnet for this course, netcat for raw TCP work, openssl s_client for anything encrypted.