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
sudofor 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.
| Goal | Packages | Fedora Behavior |
|---|---|---|
| Client only | telnet | Installs /usr/bin/telnet for quick TCP checks to remote hosts and service ports. |
| Client and server | telnet telnet-server | Adds /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-96.fc44.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-96.fc44.x86_64 telnet-server-0.17-96.fc44.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, Telnet’s default daemon port.
sudo systemctl enable --now telnet.socket
Check the socket state right away so you know Fedora enabled the socket and started it successfully.
systemctl is-enabled telnet.socket
systemctl is-active telnet.socket
enabled active
The enabled result confirms the socket will start after reboots, and active confirms it is running now. 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 -tln 'sport = :23'
State Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 4096 *:23 *:*
The *:23 listener confirms Fedora is accepting Telnet connections locally. 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.
Use Telnet for one quick TCP probe. For broader host or port discovery, install Nmap on Fedora and use a scanner built for multi-port checks.
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 query the zone that protects the network interface you expect Telnet clients to reach. If more than one active zone appears, set zone manually to the zone for the interface you are testing.
sudo firewall-cmd --get-active-zones
zone=$(sudo firewall-cmd --get-active-zones | awk 'NR == 1 {print $1}')
sudo firewall-cmd --zone="$zone" --query-service=telnet
On a Fedora Workstation install, the output can look like this. Use the active zone printed for your own interface; on Server or minimal installs, that may be public instead.
FedoraWorkstation (default) interfaces: ens160 no
The important line is no, which means firewalld still blocks inbound Telnet in the selected 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 to the selected zone permanently and reload firewalld.
zone=$(sudo firewall-cmd --get-active-zones | awk 'NR == 1 {print $1}')
sudo firewall-cmd --permanent --zone="$zone" --add-service=telnet
sudo firewall-cmd --reload
sudo firewall-cmd --zone="$zone" --query-service=telnet
success success 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.
zone=$(sudo firewall-cmd --get-active-zones | awk 'NR == 1 {print $1}')
sudo firewall-cmd --permanent --zone="$zone" --remove-service=telnet
sudo firewall-cmd --reload
sudo firewall-cmd --zone="$zone" --query-service=telnet
success success 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 -tln 'sport = :23'
If the socket is inactive, start it with sudo systemctl enable --now telnet.socket. If the ss output does not include *:23, 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-active-zones
zone=$(sudo firewall-cmd --get-active-zones | awk 'NR == 1 {print $1}')
sudo firewall-cmd --zone="$zone" --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
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.


Formatting tips for your comment
You can use basic HTML to format your comment. Useful tags currently allowed in published comments:
<code>command</code>command<strong>bold</strong><em>italic</em><a href="https://example.com">link</a><blockquote>quote</blockquote>