Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

ProComm and SSH, KXBoy CygWin solution

Status
Not open for further replies.

mrgmhale

Programmer
Aug 8, 2002
3
US
Several years ago KXBoy wrote a How To article on how to connect ProComm to a target server via SSH (Procomm Plus and SSH, thread448-1731185). I have no experience using CygWin, and tried to follow the instructions. But apparently there have been some changes within CygWin and the directions provided do not correlate to how CygWin is responding to me in some areas. I am interested to see if anyone has any more recent information on his solution. Of course, I would be fine with communication with KXBoy directly as well.
 
Hello,

I just reviewed the steps and compared them to my notes and they seem correct. However, it has been a couple of years since I installed Cygwin and configured it to use telnet. It is possible that the Cygwin packages may have changed, or some of the prompts may be different. I did notice that in the install instructions, the util-linux package is now in the base section and no longer in the system section.

Can you give some additional details on what your issues are? Also, when I set this up on my PC, I used Windows 7. I've not tried this on Windows 10, the procedures maybe a little different
 
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!

 
Hello,

I'm not sure that your plink command will still work after the telnet is disabled on the remote server. Because with this part "-L 9091:198.249.28.129:23" you are setting up port 9091 at IP 198.249.28.129 to forward to port 23 on the same server. Essentially, you are telling the server to forward port 9091 to port 23. Since telnet is port 23, when the telnet service is disabled, this connection will no longer work. Or to put it another way, you can now telnet to 198.249.28.129 using port 9091. But it is still telnet, and not the secure ssh that we are trying to use.

In addition, you can't create a tunnel with a source protocol (port 23 telnet) and have it terminate in a different protocol (port 22 ssh) they are not compatible with each other. With that said, the cygwin setup is different in that you are setting up a secure ssh connection from your PC to the remote server. The telnet part is internal to your PC.

Back to the /etc/password file. This file has the user login info for the cygwin application on your PC. You will need that to allow a login using telnet. Basically what the mkpasswd command is doing is creating the /etc/passwd file from the existing windows accounts that exist on that PC. Once this file is created, you will have a line similar to the text below.

joeuser:*:1167651:1049089:U-TX23\joeuser,S-1-5-21-243278911-345624895-1234564286-111015:/home/joeuser:/bin/zsh

The first field is the user name "joeuser" the stuff in the middle is some windows account/password info. Then the /home/joeuser is the default directory when logging in, followed by the default user shell. In this example it is /bin/zsh

The default user shell is /bin/bash. But I found that it does not always display the text properly, that is why I suggest in the instructions to use /bin/zsh.

One thing to note with this cygwin setup, is that if you do something wrong, it is easy to remove cygwin and start over.
 
Greetings KXBoy!

As for your explanation re: the Port Forward approach, yeah, I was concerned the Telnet to server Port 23 would end up botching me, and that there was some "real magic" within the Cygwin solution beyond my little SSH white magic.

Thank you!

Gil
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top