Unencrypted Telnet Server is a Nessus and Greenbone/OpenVAS finding that means a host accepts Telnet logins, so usernames, passwords and commands cross the network in cleartext. Fix it by disabling Telnet and using SSH: on Cisco IOS generate an RSA key, set ip ssh version 2 and transport input ssh; on Linux remove telnetd; on appliances, switch Telnet off.
What the scanner is actually detecting
Both scanners connect to a port, recognise a Telnet server and check whether the session is encrypted. They do not need to log in, so a positive result tells you that the service is listening and reachable from the scanner, not that someone has used it.
| Scanner | Finding title | Notes |
|---|---|---|
| Nessus 42263 | Unencrypted Telnet Server | Tenable rates it Medium (CVSS v3 6.5). It builds on Nessus’s Telnet server detection and a START_TLS support check, and Tenable’s solution text is simply to disable Telnet and use SSH instead. |
| Greenbone/OpenVAS (OID 1.3.6.1.4.1.25623.1.0.108522) | Telnet Unencrypted Cleartext Login | Same exposure: a Telnet service that allows logins over an unencrypted connection. |
Check the port column in the report. The finding is raised on whatever port the scanner identified as Telnet, which is usually TCP 23 but can be a vendor-specific management port.
Real-world risk
Telnet has no encryption at all. Tenable’s description is direct: logins, passwords and commands are transferred in cleartext, so an attacker in the network path can capture credentials and can also modify traffic between client and server. On switches, routers, UPS cards and printers, the account typed into a Telnet prompt is very often a privileged administrative account, so one captured session can hand over the device.
Stay proportionate. Exploiting the cleartext weakness requires the attacker to see the traffic, for example from a compromised host on the same segment or a device in the path. A Telnet port reachable from the internet is urgent, because it also invites password guessing. One reachable only from a locked-down management VLAN is lower priority, but still worth closing.
There is also the daemon itself. Debian’s security tracker lists CVE-2026-24061, a remote authentication bypass in the telnetd from GNU Inetutils through version 2.7. Plugin 42263 does not test for that flaw, but it is a good reason to remove telnetd rather than just firewall it.
How to confirm it on the host
Start from a different machine on the scanner’s side of the network:
nmap -Pn -sV -p23 <host>
# If the report listed another port, scan that port insteadOn a Linux host, find what owns the listener:
ss -tlnp 'sport = :23' # systemd shows as the owner if socket-activated
systemctl list-units --all 'telnet*' # RHEL/Fedora: telnet.socket
rpm -q telnet-server # RHEL family
dpkg -l | grep -i telnetd # Debian/Ubuntu
grep -n telnet /etc/inetd.conf # inetd-based installs
grep -n disable /etc/xinetd.d/telnet # xinetd-based installsOn Cisco IOS or IOS XE, look at every vty section, not just the first one:
show running-config | section line vty
show ip sshA vty block with no transport input line, or with transport input telnet or all, accepts Telnet. On Cisco NX-OS, run show telnet server.
How to fix it
On every platform, get SSH working and test a login before you turn Telnet off. Keep console or out-of-band access available while you work on network devices.
Cisco IOS and IOS XE switches and routers
Cisco’s SSH configuration guide requires a hostname and a domain name before you can generate RSA keys, and recommends a 2048-bit modulus or higher where the platform supports it. As a safety net, schedule an automatic reload first so a lockout reverts to the saved configuration:
reload in 15Then configure SSH and restrict the vty lines:
configure terminal
hostname SW1
ip domain name example.local
crypto key generate rsa modulus 2048
ip ssh version 2
username netadmin privilege 15 secret <strong-password>
line vty 0 15
login local
transport input ssh
endNotes:
- Older releases spell the domain command ip domain-name.
- Run show line to see how many vty lines exist. Some platforms only have line vty 0 4, while many switches have 0 to 15. If the running config shows separate line vty 0 4 and line vty 5 15 sections, make sure both end up with transport input ssh.
- If you already use AAA with TACACS+ or RADIUS, keep your existing login method instead of login local.
- Cisco’s guide also shows restricting management access with an ACL applied by access-class under the vty lines, which is worth adding.
Open a new SSH session to confirm it works, then cancel the scheduled reload and save:
reload cancel
copy running-config startup-configCisco NX-OS (Nexus)
Cisco documents Telnet as disabled and SSH as enabled by default on NX-OS, so a finding here means someone turned Telnet on:
configure terminal
feature ssh
no feature telnet
end
show telnet server
show ssh serverLinux: systemd socket (RHEL, Fedora and derivatives)
The telnet-server package uses systemd socket activation through telnet.socket:
systemctl enable --now sshd # confirm SSH first
systemctl disable --now telnet.socket
dnf remove telnet-server # yum on RHEL/CentOS 7Stopping the socket blocks new connections. Check who for Telnet sessions that were already open and close them.
Linux: xinetd (older releases)
Set disable = yes in /etc/xinetd.d/telnet (or delete the file), then restart xinetd:
systemctl restart xinetd # or: service xinetd restartLinux: inetd (Debian and Ubuntu)
On Debian 12, telnetd is a transitional package for inetutils-telnetd, which runs under an inetd superserver. Disable the entry, then remove the packages:
update-inetd --disable telnet
apt purge telnetd inetutils-telnetd
systemctl restart openbsd-inetd # or inetutils-inetd, whichever is installedIf nothing else uses inetd, disable the superserver too. Removing the telnet client package is not required for this finding.
Printers, UPS/PDU cards and other appliances
Embedded devices usually expose Telnet as a management option. Open the device’s web management interface, find the network protocol or services settings, turn Telnet off and turn SSH or HTTPS on if the firmware offers it. Menu names differ by vendor, so follow that vendor’s hardening guide. If the firmware cannot disable Telnet, update it, or move the device onto a management VLAN that only admin hosts can reach and record it as a documented exception. Our guide to scanning fragile OT devices and printers covers how to rescan these without knocking them over.
How to verify the fix and rescan
- From a remote host, run nmap -Pn -p23 <host> (plus any non-standard port from the report). The port should show closed or filtered.
- On Cisco IOS, show ip ssh should report SSH enabled with version 2.0, and every vty section should show transport input ssh.
- On Linux, ss -tlnp ‘sport = :23’ should return nothing, and systemctl is-enabled telnet.socket should not say enabled.
- Log in over SSH with the account your team actually uses, including privilege escalation.
- Rescan with the same scanner from the same source address, since ACLs and firewalls can give different answers to different sources.
What can break and how to roll back
- Lockout on network devices: no local user, a missing RSA key or an ACL that excludes your jump host leaves you with console access only. The scheduled reload in reverts to the saved config if you lose the session.
- Scripts and monitoring: backup jobs, config collectors and old NMS tools that log in over Telnet will fail. Move them to SSH before the change window.
- Old clients and firmware: very old SSH clients or device firmware may not share algorithms with each other. Update the client or firmware rather than re-enabling Telnet.
- Serial console servers: reverse Telnet to console ports is a separate feature on terminal servers. Plan it as its own change.
To roll back on Cisco IOS, set transport input telnet ssh under the vty lines, fix the SSH problem, then set it back. On Linux, reinstall the package and re-enable the socket or inetd entry. Treat any rollback as temporary.
Common false positive reasons
This finding is rarely wrong, because a Telnet banner either answers or it does not. What looks like a false positive is usually one of these:
- A different device answered. NAT, a port forward or a load balancer sent the connection somewhere other than the host in the report.
- Partial vty fix. line vty 0 4 was changed but line vty 5 15 still allows Telnet, so the port stays open.
- Stale result. The report predates the change, or the socket or inetd service was not restarted.
- A device nobody owns. Telnet often lives on hardware that never made it into the inventory, the problem described in assets your inventory never listed. The finding is real; it just needs an owner.
FAQ
Is Telnet ever acceptable?
Only as a documented exception, for a device that cannot run SSH, on an isolated management network with access limited to admin hosts. Plan to replace or upgrade the device.
Is transport input ssh on Cisco enough on its own?
Only if every vty line has it. If any vty line still permits Telnet, the device keeps accepting Telnet connections and the finding remains, so check all vty sections.
What RSA key size should I use for SSH on a Cisco switch?
Cisco recommends 2048 bits or higher when the platform supports it, and 4096 where supported and performance allows.
Do I need to uninstall the telnet client too?
No. The finding is about a listening Telnet server. The client does not open a port, so removing telnetd or telnet-server is what closes it.
Tracking this finding across many hosts
Telnet tends to show up on a scattered mix of switches, Linux servers and appliances. SITEY can launch Nessus and OpenVAS scans or import their results (Nessus via an uploaded .nessus export), and for Linux and Windows endpoints running its agent it can draft a host-specific fix that runs only after human approval, then re-test Nessus findings to confirm closure. Duplicates are merged per scanner, not across scanners, so a host flagged by both tools appears once for each.