Skip to content
telnety

Telnet Guide

Telnety includes a Telnet client for one reason only: there are still routers, switches, and serial-bridged industrial devices that speak nothing else. Every byte of a Telnet session — username, password, every command — travels the network in plaintext. Treat it that way.

Security warning: Telnety always shows a red banner above a Telnet session and never stores Telnet credentials in the vault encrypted-at-rest tier. If the device supports SSH, configure SSH and stop using this protocol.

When Telnet is acceptable

  • Lab and isolated networks: air-gapped management VLANs where you control every hop.
  • Initial setup of legacy hardware: some Cisco/HP/Aruba devices ship with Telnet enabled and no SSH host key generated yet.
  • Console servers / terminal servers: reverse-Telnet to TCP ports 2000–2100 on devices like Cisco 2511 / Opengear / Lantronix.

Configuring a Telnet connection

When creating a new host, choose Telnet as the protocol:

  • Hostname: IP address or FQDN of the target.
  • Port: 23 by default. Use 2001–2100 for reverse-Telnet console servers.
  • Encoding: UTF-8 by default. Use Latin-1 for older Cisco IOS / pre-1990s gear.
  • Line mode: Off by default — local echo handled by the remote. Enable for half-duplex serial bridges.

Session recording

Telnet sessions can be recorded in Asciicast v2 format like any other terminal session. Because Telnet credentials travel in the clear, recordings will capture them too — Telnety strips obvious password prompts, but you should treat any Telnet recording as sensitive and store it accordingly.

Migrating to SSH

On most network gear, enabling SSH is a four-line config:

# Cisco IOS example
ip domain-name lab.local
crypto key generate rsa modulus 2048
line vty 0 15
transport input ssh

Once SSH is up, delete the Telnet host in Telnety and recreate it as SSH. See the SSH guide for key management and TOFU host-key pinning details.