There is a vendor using Linux based servers who has recently advised they are going to discontinue allowing direct Telnet Port 23 connections to their servers. They are moving to an SSH Port 22 only connection beginning mid-February. I have over 20 years of ProComm v-4.8 Aspect scripted solutions that we depend on heavily being placed at risk of having to be rewritten using solutions that appear to be less capable than our current Aspect solutions are. The vendor states the move is to prevent folks from intercepting clear text data packets by now running all signals over an encrypted protocol. I do not know what method of shutting off Telnet they are planning to use (block Port 23 native access, kill Telnet support within the servers, etc.). So I began to dig around for anyone who has successfully made a Telnet connection over an SSH connection - and found your article from the other year. I had a glimmer of hope. As an aside, I am trying to work on this project on a Win 7 Pro platform. I am not too worried about running it on a Win 10 platform (yet).
In reading through your approach it was apparent it is a more complex solution than I am used to working with. I am unfamiliar with anything more than the most basic of Linux or Unix system based solutions. So I dug some more and found where some folks resolved their Telnet connection via SSH issue by using PuTTY with an SSH connection through which Port Forwarding provided them the ability to establish a Telnet signal. The PuTTY PLINK (command line processor) command I ended up being able to use is:
PLINK -ssh -L 9091:198.249.28.129:23 198.249.28.129 -P 22 -l userid -pw password
This worked perfectly once I established the SSH connection, and after changing the ProComm Dialing Directory Telnet Port to 9091, of course. If this is essentially what your Cygwin based solution accomplishes, using Port Forwarding, there is no need for me to further pursue the Cygwin solution. But, if your Cygwin solution is establishing the SSH connection and then acting as a "proxy interpreter" for the Aspect scripted commands, then I would like to see how I can implement it. Here is what I am running into when attempting to follow your directions from 2014:
In the installation steps for the Net Section the "tcp-wrappers" is now named "tcp_wrappers" (easy to deal with).
In the installation for the Shell Section the "util-linux" is now in the Base Section (also easy to deal with).
After installing Cygwin I found for the /etc/inetd.config file edit how to use vi editor (yeah, that was a bit of a challenge at first for me <g>), and saving the change you recommended went fine.
Editing the /etc/xinetd.d/telnet file also went fine.
The /etc/passwd file does not exist, and the suggested mkpasswd –l >/etc/passwd command left me wondering what the heck to do next (yep, I am that much of a Linux/Unix novice).
From that point forward I was definitely in the deep end, and felt I had no business being there. It was at that time I decided to try to track you down to see if I can get some clarification/help, or to see if the PuTTY PLINK approach I already managed to work out is essentially a parallel solution to your Cygwin approach. If the Cygwin solution is indeed a different solution that is not using Port Forwarding I would still like to pursue it in case the vendor’s effort to kill Telnet also clips my current PuTTY PLINK solution.
So, that is my dilemma. I am willing, and able, to provide compensation for any effort made toward helping me hatch out the Cygwin solution. I mention this as what I think I need is more than a little nudge, and I want to be fair and reasonable – and not to become abusive of your time and skills. If you are willing and able to help with this project I would like to be able to reach out to you directly.
Thank you!