When you install Telnet on Ubuntu, you gain a network protocol that provides command-line access to remote systems over TCP/IP networks. Common use cases include testing SMTP server availability on port 25, verifying HTTP responses on port 80, debugging network service connectivity, and accessing legacy equipment like routers and switches that don’t support SSH. However, Telnet transmits all data in plain text, including passwords, making it unsuitable for production environments where security matters. As a result, modern administrators use Telnet primarily for local network troubleshooting and testing scenarios where encrypted alternatives like SSH aren’t available or necessary.
Ubuntu includes Telnet in its default repositories, making installation straightforward through APT. By the end of this guide, you’ll have the Telnet client installed and verified with practical examples for testing remote services, troubleshooting network connectivity issues, and optional UFW firewall rules to secure incoming Telnet server connections. Additionally, you’ll learn how to verify mail server availability, test HTTP responses, debug custom application ports, and resolve common connection problems.
Prerequisites: Update System Packages
Before installing Telnet, first update your Ubuntu system to ensure you have the latest package versions and security patches:
sudo apt update && sudo apt upgradeRunning apt update refreshes your package index, while apt upgrade installs available updates. This ensures Telnet and its dependencies install correctly without version conflicts.
Install Telnet Client and Server on Ubuntu
Ubuntu includes Telnet packages in the default repository. Most users only need the Telnet client to test remote services; however, you can install both client and server if you need to accept incoming Telnet connections:
sudo apt install telnet telnetdThe telnet package provides the client for connecting to remote systems, while telnetd installs the Telnet server daemon (inetd) that listens for incoming connections. If you only need to test remote services, install just the client with sudo apt install telnet.
Ubuntu 24.04 LTS uses
inetutils-telnetdandinetutils-inetdas the actual server packages, whiletelnetdis a transitional dummy package that depends on them. Ubuntu 22.04 LTS usestelnetdfrom the netkit-telnet package as the actual server, withopenbsd-inetdproviding the inet daemon. The installation command works identically on both versions—APT automatically installs the correct dependencies for your Ubuntu release.
Verify Telnet Client Installation
After installation completes, verify the Telnet client is accessible by checking the installed package version:
apt-cache policy telnetExpected output on Ubuntu 24.04 LTS:
telnet: Installed: 0.17+2.5-3ubuntu4 Candidate: 0.17+2.5-3ubuntu4
The version number confirms the Telnet client is installed and ready to use. Ubuntu 22.04 LTS shows version 0.17-44build1, while Ubuntu 24.04 LTS uses version 0.17+2.5-3ubuntu4.
Meanwhile, if you installed the Telnet server (telnetd), check the service status. On Ubuntu 24.04 LTS, use:
systemctl status inetutils-inetdExpected output on Ubuntu 24.04 LTS:
○ inetutils-inetd.service - GNU Network Utilities internet superserver
Loaded: loaded (/usr/lib/systemd/system/inetutils-inetd.service; enabled)
Active: inactive (dead)
Condition: start condition unmet
Docs: man:inetutils-inetd(8)
On Ubuntu 22.04 LTS, the service uses a different name:
systemctl status openbsd-inetdExpected output on Ubuntu 22.04 LTS:
○ openbsd-inetd.service
Loaded: loaded (/lib/systemd/system/inetd.service; enabled)
Active: inactive (dead)
Condition: start condition unmet
The inetd service shows as inactive by default because it only starts when services are configured in
/etc/inetd.confor/etc/inetd.d/. This is normal behavior and does not affect Telnet client functionality. The service automatically starts when you add Telnet server entries to the configuration files.
For most users testing remote services, the Telnet client works immediately without requiring the server to be active. Therefore, only configure and start the inetutils-inetd service if you need to accept incoming Telnet connections on your system.
Practical Telnet Command Examples
With Telnet installed and verified, you can now test connectivity to remote services and debug network issues. The following examples demonstrate real-world troubleshooting scenarios using Telnet from the command line.
Test HTTP Server Availability
Connect to a web server on port 80 to verify HTTP service availability and manually send HTTP requests:
telnet example.com 80Expected output when the connection succeeds:
Trying 93.184.215.14... Connected to example.com. Escape character is '^]'.
Once connected, then type the following HTTP GET request followed by pressing Enter twice:
GET / HTTP/1.1
Host: example.comExpected output showing the HTTP response:
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Date: Tue, 10 Dec 2025 15:30:00 GMT
Server: Apache/2.4.52 (Ubuntu)
<!doctype html>
<html>
<head>
<title>Example Domain</title>
...
The server responds with HTTP headers and HTML content, confirming the web service is operational. Press Ctrl+] then type quit to exit the Telnet session.
Test SMTP Server Connectivity
Similarly, verify mail server availability by connecting to the SMTP port (25):
telnet mail.example.com 25Expected output showing the SMTP banner:
Trying 192.0.2.50... Connected to mail.example.com. Escape character is '^]'. 220 mail.example.com ESMTP Postfix (Ubuntu)
A successful connection displays the SMTP banner showing the mail server software and version. This confirms the mail server accepts connections on port 25. Use QUIT to disconnect gracefully.
Test Custom Application Ports
In addition, test whether a custom application port is open and accepting connections:
telnet 192.168.1.100 8080Expected output if the connection succeeds:
Trying 192.168.1.100... Connected to 192.168.1.100. Escape character is '^]'.
If the port is closed or filtered by a firewall, the connection times out or displays “Connection refused.”
Use IPv4 or IPv6 Explicitly
Force Telnet to use IPv4 when connecting to dual-stack hosts:
telnet -4 example.com 80Alternatively, force IPv6 connections with the -6 flag:
telnet -6 example.com 80This is useful when troubleshooting connectivity issues related to specific IP protocol versions.
Bind to Specific Local Address
When your system has multiple network interfaces, you should specify which local IP address to use for the outbound connection:
telnet -b 192.168.1.50 example.com 80The -b flag binds the connection to the specified local address, which helps when testing routing configurations or firewall rules tied to specific interfaces.
Restrict Telnet Access with UFW Firewall Rules
Since Telnet transmits data in plain text, restricting access using Ubuntu’s UFW firewall reduces exposure to unauthorized connections. By allowing Telnet only from trusted IP addresses or subnets, you limit the attack surface while maintaining functionality for legitimate testing and troubleshooting. For comprehensive UFW configuration guidance, see our complete UFW firewall guide for Ubuntu. Additionally, for systems requiring mandatory access controls beyond firewall rules, consider enabling AppArmor on Ubuntu to enforce security policies at the application level.
Verify UFW Status
First, check whether UFW is installed and active on your system:
sudo ufw statusExpected output if UFW is inactive:
Status: inactive
Ubuntu includes UFW by default on desktop and server installations. If the firewall is inactive, you’ll enable it in the next step after configuring default policies.
Before enabling UFW, ensure SSH access is allowed to prevent remote lockout. If you manage the server remotely, run
sudo ufw allow OpenSSHbefore enabling the firewall.
If UFW is inactive, enable it with the following command:
sudo ufw enableExpected output:
Firewall is active and enabled on system startup
Once enabled, UFW begins enforcing the configured rules immediately.
After enabling UFW, configure the default policies to deny incoming connections while allowing outgoing traffic:
sudo ufw default deny incoming
sudo ufw default allow outgoingThese defaults block unwanted inbound connections while permitting your system to initiate connections to external services. Most Ubuntu systems already use these defaults, but setting them explicitly ensures consistent behavior.
Configure Telnet Firewall Rules
The following examples demonstrate practical Telnet firewall configurations for common scenarios. Choose the rule that matches your security requirements.
Allow Telnet from Trusted IP Address:
sudo ufw allow from 192.168.1.10 to any port 23This restricts Telnet access to a single trusted IP address, suitable for one-to-one administration scenarios.
Allow Telnet from Local Subnet:
sudo ufw allow from 192.168.1.0/24 to any port 23This permits Telnet connections from any device on your local network (192.168.1.0-192.168.1.255), ideal for internal lab environments.
Block Telnet from Specific IP:
sudo ufw deny from 203.0.113.50 to any port 23This explicitly denies Telnet access from a specific address, useful for blocking known malicious hosts while allowing broader access.
Allow Telnet Globally (Not Recommended):
sudo ufw allow 23/tcpThis allows Telnet from any IP address. Only use this for temporary testing on isolated networks—never on production systems or internet-facing servers.
After adding rules, verify the configuration with sudo ufw status numbered to review active rules and their priority order.
Expected output example:
Status: active
To Action From
-- ------ ----
[ 1] 22/tcp ALLOW IN Anywhere
[ 2] 23 ALLOW IN 192.168.1.10
[ 3] 22/tcp (v6) ALLOW IN Anywhere (v6)
The numbered list shows each rule’s position, making it easier to identify and manage specific firewall entries.
Troubleshoot Telnet Connection Issues
If Telnet connections fail or behave unexpectedly, the following troubleshooting steps help identify and resolve common issues.
Connection Refused Error
If you see “Connection refused” when attempting to connect, the remote service is not listening on the specified port.
Error message:
Trying 192.168.1.100... telnet: Unable to connect to remote host: Connection refused
Verify the service is running on the remote host:
ssh user@192.168.1.100 'systemctl status servicename'Alternatively, use nmap to scan the target port and confirm whether it’s open. If Nmap isn’t installed, follow our Nmap installation guide for Ubuntu:
nmap -p 23 192.168.1.100Expected output if the port is closed:
PORT STATE SERVICE 23/tcp closed telnet
If the port shows as closed, start the service on the remote system or verify you’re connecting to the correct port number.
Connection Timeout
Connections that hang without responding typically indicate firewall blocking or network routing issues.
Check local firewall rules:
sudo ufw status numberedExpected output:
Status: active
To Action From
-- ------ ----
[ 1] 22/tcp ALLOW IN Anywhere
[ 2] 23/tcp DENY OUT Anywhere (out)
[ 3] 22/tcp (v6) ALLOW IN Anywhere (v6)
Verify whether UFW blocks outbound connections to the target port. If necessary, allow outbound Telnet temporarily for testing:
sudo ufw allow out 23/tcpVerify network connectivity:
ping -c 4 192.168.1.100If ping succeeds but Telnet times out, the remote firewall likely blocks port 23. Contact the remote system administrator to allow your IP address through their firewall.
Telnet Service Not Starting
If the inetd service fails to start after configuration, check the systemd logs for error details. On Ubuntu 24.04 LTS:
sudo journalctl -u inetutils-inetd -n 50On Ubuntu 22.04 LTS:
sudo journalctl -u openbsd-inetd -n 50Expected output showing recent log entries:
Dec 10 15:30:00 ubuntu systemd[1]: Condition check resulted in inetutils-inetd.service being skipped. Dec 10 15:30:00 ubuntu systemd[1]: inetutils-inetd.service: Unit cannot be reloaded because it is inactive.
Common causes include port conflicts (another service already using port 23) or misconfigured /etc/inetd.conf. Verify no other service is bound to port 23:
sudo ss -tlnp | grep :23Expected output if port 23 is in use:
LISTEN 0 128 0.0.0.0:23 0.0.0.0:* users:(("inetd",pid=1234,fd=5))
If another service occupies the port, stop that service or reconfigure Telnet to use an alternate port in /etc/inetd.conf.
Remove Telnet From Ubuntu
If you no longer need Telnet, remove both the client and server packages with the following command:
sudo apt remove --purge telnet telnetdThe --purge flag removes configuration files along with the packages. This stops the inetutils-inetd service and uninstalls the Telnet daemon completely.
Next, remove orphaned dependencies that are no longer required:
sudo apt autoremoveThis removes the actual server packages (inetutils-telnetd and inetutils-inetd on Ubuntu 24.04, or openbsd-inetd on Ubuntu 22.04) that were automatically installed as dependencies.
If you configured UFW rules for Telnet, remove them after uninstalling:
sudo ufw status numberedExpected output showing Telnet rules:
Status: active
To Action From
-- ------ ----
[ 1] 22/tcp ALLOW IN Anywhere
[ 2] 23 ALLOW IN 192.168.1.10
[ 3] 22/tcp (v6) ALLOW IN Anywhere (v6)
Identify the rule number(s) associated with port 23, then delete them. For example, to remove rule 2:
sudo ufw delete 2Expected output:
Deleting: allow from 192.168.1.10 to any port 23 Proceed with operation (y|n)? y Rule deleted
Next, refresh the APT cache to ensure verification reflects the current state:
sudo apt updateFinally, verify the packages are removed:
apt-cache policy telnet telnetdExpected output:
telnet: Installed: (none) Candidate: 0.17+2.5-3ubuntu4 telnetd: Installed: (none) Candidate: 0.17+2.5-3ubuntu4
Both packages showing “Installed: (none)” confirms complete removal.
Conclusion
You now have the Telnet client installed and verified on Ubuntu, with practical troubleshooting techniques for testing HTTP server responses, verifying SMTP connectivity, and debugging custom application ports in development environments. If you installed the Telnet server, you can optionally secure incoming connections using UFW firewall rules that restrict access to trusted IP addresses. However, for production remote access and server management, you should migrate to SSH, which encrypts all traffic and supports key-based authentication. See our SSH installation and hardening guide for Ubuntu to set up secure remote access with modern encryption standards.
