我使用专门的数据库框架（IntersystemsCaché）进行了多个安装，其中包含运行在端口23上的Telnet服务器。虽然该产品在Windows Server 2008，AIX和Linux（特别是RedHat Enterprise Linux）上运行，但是我支持的安装完全利用Windows Server 2008操作系统。 这是目前该产品唯一支持的命令行系统; 不支持SSH或任何其他forms的encryption接口。 Telnet界面 – 根据设备的大小 – 一次最多可以处理数百个用户/会话。 我不熟悉这个未encryption的通信，我想在服务器上build立一个外部（到框架）系统来允许encryption。
我想要做的就是限制Caché的Telnet端口只监听本地主机（127.0.0.1）上的端口23，并在服务器本身设置一个SSH服务器守护进程，以回应所有来自networking22的端口上的请求，请求本地主机上的端口23，从而允许encryption的命令行通信的产品，即使它不直接支持它。
我一直在通过标准的Googlesearch（我相当擅长于Google）研究这个问题几天，而且在这里serverfault / stackoverflow没有成功。 我发现的所有例子1）对许多用户/会话都进行直接端口转发而不encryption，或者2）仅描述如何为单个用户/会话执行SSH端口转发/隧道。
上面的＃2，试图build立数百个单独的转发SSH隧道将是一个pipe理的噩梦; 我需要一个端口上的服务器端解决scheme来处理多个会话和用户。 对于我所做的研究，在Windows服务器上设置一个OpenSSH服务器守护进程似乎是最好的select（我试图 – 不成功 – configurationsshd_config来支持这种情况），但如果有更好的select，我打开所有的build议。
我也考虑过build立一个小的Linux虚拟机来进行翻译，但是这个设施没有任何人熟练使用Linuxpipe理，而且我们仍然有几个设备在物理（而不是虚拟）环境中运行这个产品，所以第二个Linux虚拟解决scheme不会使这些网站受益。
**我忘了提及：因为基于Caché的应用程序在Windows服务器本身之外有其自己的安全系统，所以许多应用程序的个人用户没有基于Windows的login凭据到服务器。 SSH隧道不应该尝试在服务器本身上启动一个shell，它应该只能在运行时encryption/解密，并创build一个到Telnet端口的隧道。 我希望我已经解释得很好， 如果不是，请让我知道，我会尽力解释得更清楚。
任何帮助都将不胜感激。 谢谢你的时间！
由于你主要是专注于encryption的telnet会话，所以我的build议是使用像stunnel这样的工具。 Stunnel是一个TLS代理，允许您在简单的tcp协议（如telnet）之上添加TLS / SSL。 您可以获得encryption的所有好处，以及证书提供的身份validation。
stunnel面临的挑战是没有太多支持TLS的远程login客户端。 解决这个问题的方法之一就是在客户机上安装stunnel。 Stunnel可以在任何方向工作。 它可以添加或删除TLS。 所以你的客户可以通过telnet客户端连接到本地的stunnel实例。 他们的本地stunnel实例将build立一个TLS隧道到您的服务器，这将连接到数据库服务器。