Drop telnet for OpenSSL

Telnet's lack of encryption makes OpenSSL a safer option for connecting to remote systems.
79 readers like this.

JanBaby, via Pixabay CC0.

The telnet command is one of the most popular network troubleshooting tools for anyone from systems administrators to networking hobbyists. In the early years of networked computing, telnet was used to connect to a remote system. You could use telnet to access a port on a remote system, log in, and run commands on that host.

Due to telnet's lack of encryption, it has largely been replaced by OpenSSL for this job. Yet telnet's relevance persisted (and persists in some cases even today) as a sort of intelligent ping. While the ping command is a great way to probe a host for responsiveness, that's all it can do. Telnet, on the other hand, not only confirms an active port, but it can also interact with a service on that port. Even so, because most modern network services are encrypted, telnet can be far less useful depending on what you're trying to achieve.

OpenSSL s_client

For most tasks that once required telnet, I now use OpenSSL's s_client command. (I use curl for some tasks, but those are cases where I probably wouldn't have used telnet anyway.) Most people know OpenSSL as a library and framework for encryption, but not everyone realizes it's also a command. The s_client component of the openssl command implements a generic SSL or TLS client, helping you connect to a remote host using SSL or TLS. It's intended for testing and, internally at least, uses the same functionality as the library.

Install OpenSSL

OpenSSL may already be installed on your Linux system. If not, you can install it with your distribution's package manager:

$ sudo dnf install openssl

On Debian or similar:

$ sudo apt install openssl

Once it's installed, verify that it responds as expected:

$ openssl version
OpenSSL x.y.z FIPS

Verify port access

The most basic telnet usage is a task that looks something like this:

$ telnet mail.example.com 25
Connected to example.com.
Escape character is '^]'.

This opens an interactive session with (in this example) whatever service is listening on port 25 (probably a mail server). As long as you gain access, you can communicate with the service.

Should port 25 be inaccessible, the connection is refused.

OpenSSL is similar, although usually less interactive. To verify access to a port:

$ openssl s_client -connect example.com:80
140306897352512:error:1408F10B:SSL [...]

no peer certificate available

No client certificate CA names sent

SSL handshake has read 5 bytes and written 309 bytes
Verification: OK

New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)

This is little more than a targeted ping, though. As you can see from the output, no SSL certificate was exchanged, so the connection immediately terminated. To get the most out of openssl s_client, you must target the encrypted port.

Interactive OpenSSL

Web browsers and web servers interact such that traffic directed at port 80 is actually forwarded to 443, the port reserved for encrypted HTTP traffic. Knowing this, you can navigate to encrypted ports with the openssl command and interact with whatever web service is running on it.

First, make a connection to a port using SSL. Using the -showcerts option causes the SSL certificate to print to your terminal, making the initial output a lot more verbose than telnet:

$ openssl s_client -connect example.com:443 -showcerts
    0080 - 52 cd bd 95 3d 8a 1e 2d-3f 84 a0 e3 7a c0 8d 87   R...=..-?...z...
    0090 - 62 d0 ae d5 95 8d 82 11-01 bc 97 97 cd 8a 30 c1   b.............0.
    00a0 - 54 78 5c ad 62 5b 77 b9-a6 35 97 67 65 f5 9b 22   Tx\.b[w..5.ge.."
    00b0 - 18 8a 6a 94 a4 d9 7e 2f-f5 33 e8 8a b7 82 bd 94   ..j...~/.3......

    Start Time: 1619661100
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0
read R BLOCK

You're left in an interactive session. Eventually, this session will close, but if you act promptly, you can send HTTP signals to the server:

GET / HTTP/1.1
HOST: example.com

Press Return twice, and you receive the data for example.com/index.html:

    <h1>Example Domain</h1>
    <p>This domain is for use in illustrative examples in documents. You may use this
    domain in literature without prior coordination or asking for permission.</p>
    <p><a href="https://www.iana.org/domains/example">More information...</a></p>

Email server

You can also use OpenSSL's s_client to test an encrypted email server. For this to work, you must have your test user's username and password encoded in Base64.

Here's an easy way to do this:

$ perl -MMIME::Base64 -e 'print encode_base64("username");'
$ perl -MMIME::Base64 -e 'print encode_base64("password");'

Once you have those values recorded, you can connect to a mail server over SSL, usually on port 587:

$ openssl s_client -starttls smtp \
-connect email.example.com:587
> ehlo example.com
> auth login
##paste your user base64 string here##
##paste your password base64 string here##

> mail from: noreply@example.com
> rcpt to: admin@example.com
> data
> Subject: Test 001
This is a test email.
> quit

Check your email (in this sample code, it's admin@example.com) for a test message from noreply@example.com.

OpenSSL or telnet?

There are still uses for telnet, but it's not the indispensable tool it once was. The command has been relegated to "legacy" networking packages on many distributions, but without a telnet-ng or some obvious successor, admins are sometimes puzzled about why it's excluded from default installs. The answer is that it's not essential anymore, it's getting less and less useful—and that's good. Network security is important, so get comfortable with tools that interact with encrypted interfaces, so you don't have to disable your safeguards during troubleshooting.

What to read next
Seth Kenlon
Seth Kenlon is a UNIX geek, free culture advocate, independent multimedia artist, and D&D nerd. He has worked in the film and computing industry, often at the same time.


I've replaced telnet mostly with netcat e.g nc -v <host> <port> as a quick way to see if a host is listening on a port. It's probably not as informative as the s_client but I can see where s_client certainly would be more useful for troubleshooting an encrypted connection. Thanks for reminding me about it!

As a sys-admin, I find myself on systems on which I can only use tools that are pre-installed (with the os-installation) and I do need to check the connection to an other system.
First shot: `ping`. That shows the route to the remote system is there and icmp is not blocked by any firewall in between.

Now I need to check if the service on a port at the remote side is available. Therefor I neet a tool that I can give the remote side and the port number and it shows there is life at the other side.

Give me any other tool than telnet that can do this for me. Be noted: The restrictoins include: Available straight after os-installation.

What distro are you using that has telnet installed upon boot? I can't name names because I haven't been tracking the data but it seems like I'm having to install telnet myself these days, and OpenSSL comes installed by default.

That said, your use-case is exactly the kind of scenario I had in mind when I wrote that telnet does still have its uses. If you're not dealing with an encrypted protocol, then telnet is great to have.

In reply to by C. Beerse

Telnet is absolutely essential for working with certain classes of equipment that were created to be used via serial ports and have some kind of ethernet-to-serial adapter that gets them on a network. In most of these situations there isn't even a computer.

For example, I work with LED signs, think the ones over the highway or in a gas station; a lot of these were built and installed in the 90s and at some point they gained network capability to remove the need to run out with a laptop to reprogram a sign in the middle of a thunderstorm. There are programs that make sending the commands easier (but still don't provide any form of encryption because again the sign won't know anything about it), but at the end of the day telnet is the most versatile tool for sending and receiving info about a sign that may be hundreds of miles away.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.