"Nailed Up" SSH connection for Cisco devices

To all my fellow Cisco switch & router admins: have you ever been frustrated by the built-in, non-modifiable timeout for SSH support on the devices?

Well, there's a work-around that doesn't require tapping on the keyboard at least every 9:59...

The exec-timeout control for vty lines has no effect on SSH sessions; officially, you can't disable the timeout. Leave an SSH connection idle for 10:00 and it'll terminate from the remote (device) side. The alternative is to remote into your device using telnet; with that protocol, you can greatly extend or even disable the timeout.

But we don't like to use telnet, right? All data is sent in the clear, both keystrokes and screen paints, which includes authentication and logon credentials.

So how do we get the best of both worlds: secure, private connectivity of SSH with the extended, configurable (or disabled) timeout of telnet?

Answer: use both.

Seriously. Use both.

If you use SSH to remotely access a device, you'll get stuck with the 10:00 timer. But if you immediately telnet (or rlogin) back into the same device, you'll "mask" the SSH timeout with the telnet timeout (if one exists).

From the outside, this appears totally safe: all traffic going to and from the device is effectively encrypted by SSH. The telnet/rlogin session is happening "inside" the device where no man-in-the-middle or sniffer can see the traffic.

How does this work? Essentially, the timeout only measures idle time at an EXEC prompt; when you're using telnet (or SSH or rlogin, for that matter), the originating session is no longer in EXEC, it's running an operation.

One obvious negative to this is that you must keep telnet enabled as a valid transport for your device. A second negative is the practice of disabling timeouts on your vty lines. The fix for the first issue is to create a loopback interface for the express purpose of being a telnet endpoint; you then apply ACLs so that it is the only interface on your device that is permitted to accept connections on tcp/23. Assuming you build your ACLs so that telnet connections are only accepted when originated from the device itself, you will have effectively boxed in the insecure protocol inside the device. There's no real solution to the poor timeout choice, except making it long enough for most work without disabling it.