1

I have multiple installations with a specialized database framework (Intersystems Caché) that contains its own Telnet server running on port 23. Although the product does run on Windows Server 2008, AIX and Linux (RedHat Enterprise Linux, specifically), the installations that I support are solely utilizing the Windows Server 2008 OS. This is the only supported command line system for the product at this time; SSH or any other form of encrypted interface is not supported. The Telnet interface - depending on the size of the facility - can service up to several hundred users / sessions at a time. I am not comfortable with this unencrypted communication and I would like to set up an external (to the framework) system on the server to allow encryption.

What I would like to do is restrict Caché's telnet port to listen to port 23 solely on localhost (127.0.0.1) and set up an SSH server daemon on the server itself to answer all requests from the network at large on port 22 and forward those requests to port 23 on localhost, thereby allowing encrypted command line communication for the product even though it does not support it directly.

I have been researching this for several days both through standard Google searches (and I'm fairly good at speaking Google) and also here on serverfault/stackoverflow with no success. All of the examples that I have found either 1) do straight port forwarding without encryption for many users / sessions, or 2) only describe how to do SSH port forwarding / tunnelling for a single user / session.

Per #2 above, to try to set up hundreds of individual forwarded SSH tunnels would be an administrative nightmare; I need a server-side solution on a single port that will handle multiple sessions & users. For the research that I have done, setting up an OpenSSH server daemon on the windows server seems to be the best option (and I have attempted - unsuccessfully - configuring sshd_config to support this scenario) but if there is a better option I am open to all suggestions.

I had also considered setting up a small Linux virtual machine to do the translation but the facilities don't have anyone versed in Linux administration and we still have several facilities that are running the product in a physical (not virtual) environment so a secondary Linux virtual solution would not benefit those sites.

** I forgot to mention: as the Caché-based application has its own security system outside of the Windows server itself, many of the individual users of the application don't have Windows-based login credentials to the server. The SSH tunnel(s) shouldn't attempt to start a shell on the server itself, it should only encrypt/decrypt on the fly and create a tunnel to the Telnet port. I hope I've explained that well enough; if not please let me know and I'll try to explain it more clearly.

Any help at all would be greatly appreciated. Thanks for your time!

zmerch
  • 113
  • 4
  • The typical solution is the protocol itself doesn't support encryption is to add it on another layer, for instance by means IPSEC or another VPN solution. – HBruijn May 27 '15 at 06:32

1 Answers1

1

Since you primarily seem to be focused on having an encrypted telnet session, my suggestion for a alternative would be to use a tool like stunnel. Stunnel is a TLS proxy that allows you to add TLS/SSL on top of simple tcp protocols (like telnet). You get all the benefits of encryption, and authentication provided by certificates.

The challenge with stunnel would be that there aren't many TLS capable telnet clients. One way to solve that would be to install the stunnel on the client machines as well though. Stunnel can work in either direction. It can add or strip TLS. So your clients could connect to their local stunnel instance with their telnet client. Their local stunnel instance would build a TLS tunnel to your server, which would make a connection to database server.

Zoredache
  • 130,897
  • 41
  • 276
  • 420
  • I was hoping for a simple server-only solution - but a "not so simple" server only solution would have made me happy as well; convincing many of my sites that may not have much in the way of local IT staff to make changes to every workstation is not going to be easy -- and not something I can do remotely.
    However, as this was the most informative answer, I marked it as such and I think you very, very much for your insight! [[Edit due to my not knowing how to create a 2nd paragraph at first. ]]
    – zmerch Jun 15 '15 at 14:30