NetStacksNetStacks
by NetStacks Team
TerminalConsoleProduct

Telnet in 2026: console servers, lab gear, and why we kept it

Nobody should run Telnet across a network. Plenty of us still have to talk to it. How NetStacks handles Telnet, console servers and legacy SSH without making the modern path worse.

Every so often someone asks why a terminal built in 2026 supports Telnet at all. The short answer is that the console server in the rack next to you does, and the fifteen-year-old switch in the branch office does, and the lab full of virtual routers definitely does.

Where it shows up

Console servers. A terminal server maps each serial line to a TCP port, and the way you reach it is Telnet to that port, sometimes SSH to the server first. NetStacks models this directly: a session has an optional console host, port and protocol alongside its normal host, so the same device record can be reached in-band over SSH or out-of-band over the console when in-band is what broke.

Lab gear. Virtual routers in a lab expose their consoles over Telnet ports. If you are testing a change before a window, that is where you are typing.

Old hardware. Devices that predate SSH, or that shipped with SSH implementations modern clients refuse to talk to. For the second group, NetStacks offers the older key exchange and cipher algorithms alongside the modern ones, and negotiation picks the strongest set both sides support.

What the Telnet client does

Option negotiation for echo, terminal type and window size, so the device knows how wide your terminal is and resizes with you. Automatic login when the device prompts for a username or password, using the credential profile, so the password is not sitting in a script somewhere. Everything after that is the same terminal as SSH: same clipboard handling, same AI context, same recording and logging.

What it does not do

Pretend to be secure. Telnet is clear text end to end. The credential sanitiser still redacts secrets from anything sent to a model, but nothing can redact them from the wire.

Why keep it in the same app

Because the alternative is two terminals. The person who has to reach a device over its console during an outage is the same person who needs the device's incident history, the runbook and the assistant right then. Splitting the protocols across tools splits the context too.

If you never use Telnet, you will never see it; SSH is the default for every new session and the protocol field is one dropdown.