How to Install Telnet on Fedora Linux

Last updated Saturday, April 4, 2026 3:56 pm Joshua James 7 min read

It is faster to check whether a service answers at all before you open a full client or start digging through logs. To install Telnet on Fedora, the default telnet package gives you that quick TCP test, while the separate telnet-server package plus telnet.socket handles the rarer cases where this Fedora host must accept legacy inbound sessions.

Fedora ships both packages in the default repositories, so most readers only need to choose between client-only diagnostics and a legacy server kept on a trusted network. From there, the real work is testing a live connection, deciding whether port 23 should ever be reachable through firewalld, and removing the server again when the older system no longer needs it.

Telnet sends usernames, passwords, and session data in plain text. Keep it on trusted networks for diagnostics or legacy equipment, and move to SSH for routine remote administration.

Install Telnet on Fedora

Update Fedora and Check the Telnet Packages

Start with a normal package refresh so Fedora pulls the latest repository metadata and security fixes before you add the client or the legacy server.

sudo dnf upgrade --refresh

These commands use sudo for package management, socket activation, and firewall changes. If your account does not have sudo access yet, follow the guide to add a user to sudoers on Fedora first.

Check the current package state before you choose a client-only install or a full legacy server setup.

rpm -q telnet telnet-server
package telnet is not installed
package telnet-server is not installed

The package split is straightforward once you separate outbound diagnostics from inbound legacy access.

GoalPackagesFedora Behavior
Client onlytelnetInstalls /usr/bin/telnet for quick TCP checks to remote hosts and service ports.
Client and servertelnet telnet-serverAdds /usr/bin/in.telnetd, telnet.socket, and telnet@.service for inbound Telnet sessions on port 23.

Install the Telnet Client on Fedora

Use the client-only package when you want to test remote HTTP, SMTP, SSH, or other plain TCP listeners from the Fedora shell.

sudo dnf install telnet

RPM gives the clearest installed-state check on Fedora, especially because this Telnet build does not support telnet --version.

rpm -q telnet
telnet-0.17-95.fc43.x86_64

Install the Telnet Client and Server on Fedora

Install both packages only when this Fedora machine must accept inbound Telnet sessions from a lab network or older device that still depends on port 23.

sudo dnf install telnet telnet-server
rpm -q telnet telnet-server
telnet-0.17-95.fc43.x86_64
telnet-server-0.17-95.fc43.x86_64

Fedora does not use an inetd service name here. The server package ships telnet.socket for socket activation and a templated telnet@.service instance for each connection.

Enable the Telnet Socket on Fedora

After the server package is present, enable the listening socket so systemd starts accepting connections on TCP port 23.

sudo systemctl enable --now telnet.socket

Check the socket state right away so you know Fedora is actually listening for Telnet traffic.

systemctl status telnet.socket --no-pager | sed -n '1,8p'
● telnet.socket - Telnet Server Activation Socket
     Loaded: loaded (/usr/lib/systemd/system/telnet.socket; enabled; preset: disabled)
     Active: active (listening)
       Docs: man:telnetd(8)
     Listen: [::]:23 (Stream)
   Accepted: 0; Connected: 0;

That status confirms the socket is listening and waiting for inbound connections. Systemd starts the matching service instance only when a client actually connects.

Verify the Telnet Listener on Fedora

Use ss as the final local proof that port 23 is open before you test from another machine.

sudo ss -tlnp | grep ':23'
LISTEN 0      4096               *:23              *:*    users:(("systemd",pid=1,fd=132))

Seeing systemd on the listening socket is normal for a socket-activated service. The Telnet daemon itself starts only when a connection arrives.

Test Telnet Connections on Fedora

Once the client is installed, Telnet becomes a simple way to answer two questions fast: does a TCP port answer at all, and does a plaintext service return the banner or prompt you expect?

Test a Local Telnet Connection on Fedora

Start with the local host if you enabled telnet.socket on this Fedora machine.

telnet 127.0.0.1 23

Relevant output includes:

Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.

Press Ctrl+] to reach the local telnet> prompt, then type quit to close the session cleanly.

Test Remote Service Ports with the Telnet Client on Fedora

For remote diagnostics, give Telnet a host and port number. This is useful for quick checks against plaintext or banner-based services before you move on to a full application client.

# Test HTTP on port 80
telnet example.com 80

# Test SMTP on port 25
telnet mail.example.com 25

# Test SSH reachability on port 22
telnet 192.168.1.50 22

A reachable port prints Connected to. A closed local port usually returns Connection refused, while a filtered remote port often hangs until the connection times out.

Send a Simple HTTP Request Through Telnet on Fedora

Plain HTTP on port 80 is a good first-use example because you can see whether the server answers with real headers and content. HTTPS on port 443 is encrypted, so Telnet only proves the TCP connection there, not the application response.

telnet example.com 80

Once the connection opens, type a minimal request and press Enter twice after the final line.

GET / HTTP/1.1
Host: example.com
Connection: close

A normal web server answers with headers such as HTTP/1.1 200 OK or a redirect status, followed by the page body. That confirms both the TCP path and the application response on an unencrypted HTTP service.

Understand Telnet Security on Fedora

Fedora installs the software cleanly, but Telnet itself is still a legacy protocol with no encryption and no integrity protection. That changes how you should expose it.

Keep Telnet on Trusted Networks Only

Anything you type into a Telnet session, including usernames and passwords, crosses the network in plain text. Use it only on isolated lab segments, inside a trusted VPN, or for short-lived diagnostics against legacy systems that do not support a safer protocol.

Prefer SSH for Routine Remote Administration

When you need an everyday remote shell, encrypted file copy, or key-based access, move to install SSH on Fedora instead. For broader client-side usage after that, the SSH command guide for Linux covers the connection patterns Telnet cannot protect.

Configure Firewalld for Telnet on Fedora

Open port 23 only when this Fedora system must accept inbound Telnet sessions. Client-side tests to other hosts do not need a local Telnet firewall rule at all.

Fedora Workstation usually already includes firewalld. If firewall-cmd is missing on a Server or minimal install, follow the guide to install firewalld on Fedora first.

Check the Active Zone and Current Telnet Rule

Check the active zone first, then ask whether that zone already allows the built-in telnet service definition.

sudo firewall-cmd --get-default-zone
sudo firewall-cmd --query-service=telnet

On a Fedora Workstation install, the output can look like this:

FedoraWorkstation
no

Workstation often uses the FedoraWorkstation zone, while Server and minimal installs more often use public. The important line is no, which means firewalld still blocks inbound Telnet in the active zone.

Allow the Telnet Service on Fedora Only When Needed

If you really do need inbound Telnet on this Fedora host, add the built-in Telnet service rule permanently and reload firewalld.

sudo firewall-cmd --permanent --add-service=telnet
sudo firewall-cmd --reload
sudo firewall-cmd --query-service=telnet
yes

Using the service name is clearer than opening raw 23/tcp, and it keeps the rule aligned with firewalld’s own Telnet definition.

Remove the Telnet Firewall Rule When Testing Is Finished

If Telnet was only a temporary diagnostic step, remove the permanent rule as soon as the legacy test is complete.

sudo firewall-cmd --permanent --remove-service=telnet
sudo firewall-cmd --reload
sudo firewall-cmd --query-service=telnet
no

Troubleshoot Telnet on Fedora

Most Telnet problems on Fedora come down to three things: the client package is missing, the local socket is not listening, or the remote path is still blocked by the firewall.

Fix telnet Command Not Found on Fedora

If your shell reports telnet: command not found, the client package is not installed yet.

sudo dnf install telnet

Recheck the package afterward with rpm -q telnet so you know the client landed cleanly.

Fix Local Connection Refused Errors on Fedora

A refused connection against 127.0.0.1 usually means the server socket is not active, or you removed the server package after finishing earlier tests.

telnet: connect to address 127.0.0.1: Connection refused
Trying 127.0.0.1...

Check both the socket state and the listening port before you try the connection again.

systemctl is-active telnet.socket
sudo ss -tlnp | grep ':23'

If the socket is inactive, start it with sudo systemctl enable --now telnet.socket. If ss prints nothing, nothing is listening on port 23 yet.

Fix Remote Telnet Timeouts with Firewalld Checks

Remote timeouts usually point to a blocked path rather than a missing local client. Confirm the active zone and whether the Telnet service is allowed there.

sudo firewall-cmd --get-default-zone
sudo firewall-cmd --query-service=telnet

If the query still returns no, add the Telnet service to the correct zone or test from a trusted network that already permits the port. Also check for upstream filtering on the remote host or any firewall between the two systems.

Remove Telnet from Fedora

Remove the server first if you enabled it, then clean out whichever Telnet packages you no longer need.

Disable the Telnet Socket and Remove the Packages

If this Fedora system was accepting inbound Telnet sessions, stop the socket before you remove the packages.

sudo systemctl disable --now telnet.socket
sudo dnf remove telnet telnet-server

For a client-only cleanup, remove just the client package with sudo dnf remove telnet.

Verify Telnet Is Removed from Fedora

Use RPM one last time to confirm Fedora no longer has either package installed.

rpm -q telnet telnet-server
package telnet is not installed
package telnet-server is not installed

Telnet on Fedora FAQ

Is Telnet installed by default on Fedora?

No. Fedora does not guarantee either telnet or telnet-server by default across Workstation, Server, and customized images. Check with rpm -q telnet telnet-server on your own system before you add either package.

Do I need telnet-server to test remote ports from Fedora?

No. The telnet client package is enough for outbound checks to remote HTTP, SMTP, SSH, or other TCP ports. Install telnet-server only when this Fedora machine itself must accept inbound Telnet sessions on port 23.

Why does Telnet on Fedora use telnet.socket instead of an inetd service?

Fedora’s telnet-server package ships a systemd socket-activated setup. The listener lives in telnet.socket, and systemd starts the matching telnet@.service instance only when a client connects. That is why the main service check on Fedora uses the socket unit instead of an inetd daemon name.

Why does telnet –version fail on Fedora?

Fedora’s current Telnet client build still prints the traditional usage output instead of a version banner when you pass --version. Use rpm -q telnet for the installed-state check on Fedora instead of treating that missing flag as an installation problem.

Should I open port 23 in firewalld on Fedora?

Only when this Fedora host must accept inbound Telnet sessions from a trusted network. Client-side tests to other hosts do not need a local Telnet firewall rule. If you temporarily allow the built-in telnet service in firewalld, remove that rule again as soon as the legacy test is finished.

Conclusion

Telnet is now ready on Fedora as a quick TCP test tool, and the optional server path stays under your control through telnet.socket and firewalld. Keep port 23 limited to trusted networks, remove the firewall rule when the legacy check is done, and move to encrypted daily access with SSH instead.

Search LinuxCapable

Need another guide?

Search LinuxCapable for package installs, commands, troubleshooting, and follow-up guides related to what you just read.

Found this guide useful?

Support LinuxCapable to keep tutorials free and up to date.

Buy me a coffee Buy me a coffee

Before commenting, please review our Comments Policy.
Formatting tips for your comment

You can use basic HTML to format your comment. Useful tags currently allowed in published comments:

You type Result
<code>command</code> command
<strong>bold</strong> bold
<em>italic</em> italic
<blockquote>quote</blockquote> quote block

Got a Question or Feedback?

We read and reply to every comment - let us know how we can help or improve this guide.

Let us know you are human: