Securing telnet connections with stunnel

Telnet is a client-server protocol that connects to a remote server through TCP over port 23. Telnet does not encrypt data and is considered insecure and passwords can be easily sniffed because data is sent in the clear. However there are still legacy systems that need to use it. This is where stunnel comes to the rescue.

Stunnel is designed to add SSL encryption to programs that have insecure connection protocols. This article shows you how to use it, with telnet as an example.

Server Installation

Install stunnel along with the telnet server and client using sudo:

sudo dnf -y install stunnel telnet-server telnet

Add a firewall rule, entering your password when prompted:

firewall-cmd --add-service=telnet --perm
firewall-cmd --reload

Next, generate an RSA private key and an SSL certificate:

openssl genrsa 2048 > stunnel.key
openssl req -new -key stunnel.key -x509 -days 90 -out stunnel.crt

You will be prompted for the following information one line at a time. When asked for Common Name you must enter the correct host name or IP address, but everything else you can skip through by hitting the Enter key.

You are about to be asked to enter information that will be
incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
Country Name (2 letter code) [XX]:
State or Province Name (full name) []:
Locality Name (eg, city) [Default City]:
Organization Name (eg, company) [Default Company Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:
Email Address []

Merge the RSA key and SSL certificate into a single .pem file, and copy that to the SSL certificate directory:

cat stunnel.crt stunnel.key > stunnel.pem
sudo cp stunnel.pem /etc/pki/tls/certs/

Now it’s time to define the service and the ports to use for encrypting your connection. Choose a port that is not already in use. This example uses port 450 for tunneling telnet. Edit or create the /etc/stunnel/telnet.conf file:

cert = /etc/pki/tls/certs/stunnel.pem
sslVersion = TLSv1
chroot = /var/run/stunnel
setuid = nobody
setgid = nobody
pid = /
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
accept = 450
connect = 23

The accept option is the port the server will listen to for incoming telnet requests. The connect option is the internal port the telnet server listens to.

Next, make a copy of the systemd unit file that allows you to override the packaged version:

sudo cp /usr/lib/systemd/system/stunnel.service /etc/systemd/system

Edit the /etc/systemd/system/stunnel.service file to add two lines. These lines create a chroot jail for the service when it starts.

Description=TLS tunnel for network daemons

ExecStartPre=-/usr/bin/mkdir /var/run/stunnel
ExecStartPre=/usr/bin/chown -R nobody:nobody /var/run/stunnel


Next, configure SELinux to listen to telnet on the new port you just specified:

sudo semanage port -a -t telnetd_port_t -p tcp 450

Finally, add a new firewall rule:

firewall-cmd --add-port=450/tcp --perm
firewall-cmd --reload

Now you can enable and start telnet and stunnel.

systemctl enable telnet.socket stunnel@telnet.service --now

A note on the systemctl command is in order. Systemd and the stunnel package provide an additional template unit file by default. The template lets you drop multiple configuration files for stunnel into /etc/stunnel, and use the filename to start the service. For instance, if you had a foobar.conf file, you could start that instance of stunnel with systemctl start stunnel@foobar.service, without having to write any unit files yourself.

If you want, you can set this stunnel template service to start on boot:

systemctl enable stunnel@telnet.service

Client Installation

This part of the article assumes you are logged in as a normal user (with sudo privileges) on the client system. Install stunnel and the telnet client:

dnf -y install stunnel telnet

Copy the stunnel.pem file from the remote server to your client /etc/pki/tls/certs directory. In this example, the IP address of the remote telnet server is

sudo scp myuser@

Create the /etc/stunnel/telnet.conf file:

cert = /etc/pki/tls/certs/stunnel.pem

The accept option is the port that will be used for telnet sessions. The connect option is the IP address of your remote server and the port it’s listening on.

Next, enable and start stunnel:

systemctl enable stunnel@telnet.service --now

Test your connection. Since you have a connection established, you will telnet to localhost instead of the hostname or IP address of the remote telnet server:

[user@client ~]$ telnet localhost 450
Trying ::1...
telnet: connect to address ::1: Connection refused
Connected to localhost.
Escape character is '^]'.

Kernel 5.0.9-301.fc30.x86_64 on an x86_64 (0)
server login: myuser
Password: XXXXXXX
Last login: Sun May  5 14:28:22 from localhost
[myuser@server ~]$
For System Administrators Using Software


  1. Paul Gresham

    Thank you Curt. This and other articles in the Fedora Magazine are outstanding.

  2. Einer

    I guess I don’t see the point of this because:
    1) I would not use the telnet server
    2) If I am going to put something in an encrypted tunnel, I would just use SSH

    • Hi Einer,
      There are a lot of legacy systems that still need to use telnet.
      The point of the article is to show you how to make your telnet sessions more secure if you are in a situation where you need to use it.

      • Einer

        Hi Curt 🙂

        I am not so sure I agree with you. Here’s why:
        1) let’s say its a Cisco router

        2) can only use telnet to get a console session on the router via the network

        1) you can’t install stunnel on that Cisco router

        == no way to encapsulate the telnet session in SSL/stunnel== wasted effort 🙂

        same applies to an old Unix system that has no support for stunnel

        Bottom line is that BOTH ends of the conversation/session must be able to support stunnel ……. if you can’t install on one end or the other (most likely due to age of one of the endpoints) …………
        see where I’m going? 🙂

      • Supersonic Tumbleweed

        You can very much use telnet with ssh, ssh with telnet, and any combination of those you can think of… so it’s an additional layer of configs.
        But also an additional layer of abstraction for programs that have telnet invocation hardcoded into them, that allows to work with those programs securely too, so that’s nice.

      • Supersonic Tumbleweed

        Actually, scratch that, it just opens a tunnel.

        Yeah, that can be done pretty easily without an additional tool. Nice for managing keys.

      • The title is misleading. The point is to illustrate how to use stunnel with something simple like telnet. The point is that you can add security to any TCP service with stunnel. Telnet is just a simple example. Did you build a simple tcp service in python? Don’t want to deal with adding SSL support for use over the public internet? Use stunnel!

  3. Radosław

    I see several issues with this article, assuming that it is aimed towards beginners.

    There’s little point in generating insecure, self-signed certificates, when Let’s Encrypt is available and well integrated in Fedora. I strongly believe that recommending self-signed certificates is harmful. The article should be updated to reference certbot or at least explain why is it a terrible idea to use self-signed certs.

    Also, when you’re using stunnel for a single, local service that you want to provide as encrypted, I’d say it is much better idea to use systemd socket activation. This way it won’t be necessary to restart stunnel service every time you update the certificate (because it will be started on-demand by systemd every time when the incoming connection arrives).

    The encrypted-telnet.socket file could look like:


    And the appropriate encrypted-telnet@.service:
    ExecStart=/usr/bin/stunnel /etc/stunnel/telnet.conf


    The stunnel server telnet.conf file would also be much simpler:
    cert = /etc/letsencrypt/live/
    key = /etc/letsencrypt/live/
    connect = localhost:450

    Much easier, yes?

    • Radosław

      And of course I made a mistake in the example above, as connect should be done to local port 23, so:

      connect = localhost:23

      • Bob

        Using self-signed certificates are no more or less secure than certificates signed by a CA like Let’s Encrypt. The purpose of the CA is to help us trust other certificates more easily. By trusting a CA you trust all certificates issued by it. If you’re building an STunnel connection and are in control of both sides of the connection and the certificates in use their is no reason not to trust the self-signed certificates you generate.

    • Thanks for your feedback. I appreciate it!

    • varesa

      Self-signed certificates can be quite useful in self contained internal systems. Unless you can/want to use certificate pinning, it can even be more secure as then nobody but you (unlike for example a third party CA) can issue certificates to impersonate your secure connection.

      Useful for web services? Not really. Useful for internal secure tunneling (VPNs, etc.)? Yes

  4. ss

    I wouldn’t personally use Stunnel+telnet as the other commenter wrote but it is still useful for securing of any TCP service – maybe POP3 server or some embedded REST clients. I usually use SSH or ncat –ssl for quick security but If I ever need a certificates issued by a trusted CA, stunnel would probably do the job

  5. Ed H.

    That’s a lot of configuration tweaks. Why not just use secure shell (ssh)?

  6. wsanders

    Best way to handle telnet:

    yum erase telnet

    I haven’t installed it in years. If you need to test a TCP connection use nc.

    • wsanders

      However, to edit that remark, stunnel is useful.

Comments are Closed

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat. Fedora Magazine aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. The Fedora logo is a trademark of Red Hat, Inc. Terms and Conditions