Question

I am developing for a system that has an interactive telnet management console. Requirements dictate that we disable telnet access and add SSH instead. Changing the management console into a stand-alone program that we can use for SSH login would require a vendor to get involved. I was thinking of a less expensive solution that would be something like this:

1. Block the telnet management console from outside access but leave it running available for localhost connections.

2. Write a login shell (in C++, or maybe something as simple as this if I’m lucky) that acts as a proxy. The login shell will telnet to localhost and send all commands it receives from the user over telnet, and send all displays and prompts it receives from the telnet server back to the user.

3. Change /etc/passwd to launch this proxy shell when the user logs in over ssh.

Is what I’m thinking possible? Are there horrible pitfalls that I’ll get stuck on? Are there better alternatives? I’m using OpenSSH as the ssh daemon.

Answer 1

Restricting Telnet to local connections sounds like a good plan, especially if you don’t want to touch the code. Steps 2 and 3 are unnecessary, though. You can simply invoke the “telnet” command in the remote shell once you’ve established the connection. This can be done automatically by creating a .ssh/rc script in the user’s home directory.

BUT, one potential problem with this approach is that Telnet control sequences might not pass through correctly. So an alternative is to tunnel the Telnet connection through the secure SSH connection using port forwarding. With this strategy, you’ll continue to run Telnet on your client and server, but the connection is encrypted using SSH. To set that up, invoke the SSH client like this:

ssh -L 23:localhost:23 user@host

Replace “user@host” with the user/host of the SSH server. The effect of this command is that port 23 (telnet) on the client box will be opened. And connections made to it will be forwarded to port 23 on the server via SSH. So on your client, you’d Telnet to localhost and the connection will be forwarded to the Telnet server running on the same box as the SSH daemon.

Note that you can change the first “23” to something else (e.g. 1123) if security settings on the client prevent you from using port 23 there. In that case, you’d point your Telnet client to localhost:1123 or whatever and it will be forwarded to port 23 on the remote system. Red Hat Magazine has a good tutorial on using SSH port forwarding for use cases like this.