Telnet from Windows, SSH in to Linux

#11

On 2010-11-16 09:52:13 -0500, "Frank Winans" <fwinans (AT) sbcglobal (DOT) net> said:

Quote:

And there the wheels fall off the wagon, because the linux server at
11.22.33.44 is by admin fiat not running a telnet server to listen on
port 23.

Yes, I believe TG said there was no Telnet server daemon running on the
Linux server. In that case, I think he's SOL for Telnet access to that
box.

Quote:

I'm glad tunnelier is so handy, but the little I've tinkered with ssh port
forwarding seems to show that any linux ssh client could request about
the same features, and at first blush the putty client seems to, also. The
linux ssh server is doing most of the port forwarding 'heavy lifting'
here...

Tunnelier is just a very user-friendly SSH client for Windows (not
Linux), nothing more. Yes, much of the same could be accomplished with
the putty client as well. Tunnelier does have some nice pre-configured
tools, such as SFTP, remote console and, for Windows hosts, remote
Desktop (RDP). It also can act as an administrative console for
BitVise's other product, WinSSH; A really nice SSH server for Windows.

--
Kevin Powick

#12

On 2010-11-16 09:57:27 -0500, Kevin Powick <nospam (AT) spamless (DOT) com> said:

Quote:

On 2010-11-15 22:55:27 -0500, Tony Gravagno <nospam (AT) nospam (DOT) invalid> said:

That's the kicker. The telnetd is not running on the server.

Well, I expect that would be a problem. Essentially, regardless of
SSH, the server is not capable of handling the Telnet protocol. If you
require Telnet access for your process to work, then I think your out
of luck.

Ack! Cant' believe I put "your" where "your're" should have been used.
I *hate* that mistake.

--
Kevin Powick

#13

Continuing the same train of thought that Frank suggests, you could
run a small Linux virtual machine in Windows that just handles the
telnetd -> ssh client translation. Telnet to the IP address of the
virtual machine, which then uses a profile to launch ssh to the remote
host.

#14

"Kevin Powick" wrote

Quote:

Yes, I believe TG said there was no Telnet server daemon running on the
Linux server. In that case, I think he's SOL for Telnet access to that
box.

I'm considering a situation of very low probability here, but could TG have

erred, expecting a ps -ef entry that bore the string 'telnetd'
when in actuality the xinetd demon is accepting telnet connections instead?
Doing netstat -nl | grep 23 is the definitive test for 'does this box accept
telnet connections?' {The similar command on winboxes is netstat -na }

Under the 'rose by any other name' dept, after long persuasion the linux
sysadmins may accept a telnet service that runs on some other below-1024
port if security is beefed up to lie and say that is not the right password
when it _means_ 'I do not like the source ip address / telnet userid combo'
as adjusted in the /etc/pam.d/login & /etc/security/access.conf files.
See /usr/share/doc/pam*/html/sag-pam_access.html
and man pam_access To review pam effects, more /var/log/secure
{take time to learn what normal looks like; these pam log entries are odd}
Caution -- /etc/pam.d/login file also applies to console & serial logins.

Or perhaps they would accede to telnet with 'port knocking' security,
of a sort -- only open the telnet service up on the linux box just after an ssh
connection to a dedicated linux account? Ssh tunneling would mean they
still only have to admit telnet connections on the lan, not advertised to the
general internet...

Random thought; telnet having such a bad reputation might really frustrate
the pick sales & marketing departments...

#15

"Kevin Powick" <nospam (AT) spamless (DOT) com> wrote

Quote:

On 2010-11-16 09:57:27 -0500, Kevin Powick <nospam (AT) spamless (DOT) com> said:

On 2010-11-15 22:55:27 -0500, Tony Gravagno <nospam (AT) nospam (DOT) invalid> said:

That's the kicker. The telnetd is not running on the server.

Well, I expect that would be a problem. Essentially, regardless of SSH,
the server is not capable of handling the Telnet protocol. If you
require Telnet access for your process to work, then I think your out of
luck.

Ack! Cant' believe I put "your" where "your're" should have been used. I
*hate* that mistake.

...."your're?" How about "you're?" :-)

Ed

Quote:

--
Kevin Powick

#16

I thank you all sincerely for your consideration here. There are lots
of good comments, but it looks like the conclusion is that this is not
do-able without a hefty bit of workaround. Anything is possible, but
is it practical? Maintainable? I think not in this case. So I
decided to go off the menu. Rather than trying to telnet in to an SSH
server I decided to avoid telnet.

I dug up some code for a SSH client, substituted that for my original
telnet-based interface. Now I'm getting to Linux shell with SSH using
code like:

ssh.Connect(host,user,psw)

Rather than scripting a login to D3 I'm using the shell interface. So
my input is:
PICKUSER="phone"; export PICKUSER
PICKMD="prod"; export PICKMD
d3tcl SHOW.INV1 B3448-S

and I'm passing that and getting a response using the equivalent of:

rsponse = ssh.Send(cmd)

The output is either data or an error, with delimiters used to wrap
and separate fields. The SSH client parses that into a business
object which is returned to the calling interface exactly like it
would have been if I was using telnet or some other mechanism.

So this is pretty much done.

Thanks again,
T

#17

On 2010-11-16 13:37:21 -0500, "Ed Sheehan" <NOedsSPAM (AT) xmission (DOT) com> said:

Quote:

"Kevin Powick" <nospam (AT) spamless (DOT) com> wrote in message
news:ibu8fp$nco$1 (AT) speranza (DOT) aioe.org...
On 2010-11-16 09:57:27 -0500, Kevin Powick <nospam (AT) spamless (DOT) com> said:

On 2010-11-15 22:55:27 -0500, Tony Gravagno <nospam (AT) nospam (DOT) invalid> said:

That's the kicker. The telnetd is not running on the server.

Well, I expect that would be a problem. Essentially, regardless of SSH,
the server is not capable of handling the Telnet protocol. If you
require Telnet access for your process to work, then I think your out of
luck.

Ack! Cant' believe I put "your" where "your're" should have been used. I
*hate* that mistake.

..."your're?" How about "you're?" :-)

LOL. Wow. What a bad day I'm having.

--
Kevin Powick

#18

"Kevin Powick" <nospam (AT) spamless (DOT) com> wrote

Quote:

On 2010-11-16 13:37:21 -0500, "Ed Sheehan" <NOedsSPAM (AT) xmission (DOT) com> said:

"Kevin Powick" <nospam (AT) spamless (DOT) com> wrote in message
news:ibu8fp$nco$1 (AT) speranza (DOT) aioe.org...
On 2010-11-16 09:57:27 -0500, Kevin Powick <nospam (AT) spamless (DOT) com> said:

On 2010-11-15 22:55:27 -0500, Tony Gravagno <nospam (AT) nospam (DOT) invalid
said:

That's the kicker. The telnetd is not running on the server.

Well, I expect that would be a problem. Essentially, regardless of
SSH,
the server is not capable of handling the Telnet protocol. If you
require Telnet access for your process to work, then I think your out
of
luck.

Ack! Cant' believe I put "your" where "your're" should have been used.
I
*hate* that mistake.

..."your're?" How about "you're?" :-)

LOL. Wow. What a bad day I'm having.

Aftor "Cant'" I figgerd the mispellings we're intentionel.

--
frosty