It's been a very long time since I've looked into this area. I have a
process that uses telnet to get into local servers. A client has a
remote Linux system with only SSH access. So unless that's changed I
believe I need to create an SSH tunnel where I can still telnet
locally and have the data transparently forwarded through to the other
side.

The client is Windows and the server is Linux. I believe that leaves
OpenSSH or Putty as likely tools for this. Anything else? (Cygwin
with *nix tools are not an option.)

What confuses me is that I'm not telnetting out and expecting the
server to receive telnet. This is telnet out (maybe to port 23) and
SSH in (through 22). Even though I'm using telnet, the Linux server
needs to see an SSH client, and I need to provide proper
authentication details. But I don't want to have to tweak anything on
the server to make this happen.

Thanks!
T

We have a commercial product that can do this (and also stuff like
connecting local serial ports on a PC to a telnet or SSH connection to
logon to a remote server - great for hooking serial devices up over a
VPN connection) --> not sure it would be cost effective for a one off
scenario for you though --> still, if you get stuck, you know where we
are :-)


Ross Ferris
Stamina Software
Visage -> Better by Design

On 11/15/2010 02:56 PM, Tony Gravagno wrote:
Be sure to check out Pageant as a front-end to Putty. If I recall
correctly, you open an SSH tunnel to the server, anchoring the client
end of it at a port of your choice, and then do a local telnet to
yourself (the client) to the port that you anchored the SSH tunnel to.
But it's been a couple years since I did this.
Art

On 2010-11-15 14:56:47 -0500, Tony Gravagno <nospam (AT) nospam (DOT) invalid> said:

Yes, you need to tunnel, or port forwarding, over SSH.

A much easier and far superior SSH client for windows is Tunnelier from
BitVise. Free for sites with less than 5 users.

http://www.bitvise.com/tunnelier

You won't have to tweak anything on the server, providing the server
allows client initiated port forwarding. Your SSH client will
establish the authenticated SSH connection. The SSH client will listen
for requests on user-specified ports (i.e. 23), and forward them over
the connection to the server; i.e.

Listen: 127.0.0.1/23 Forward: Localhost/23

Remember, the client is telling the SSH server where the request should
be forwarded. So, in your situation, the destination for such requests
should be localhost (the server). Conceivably, requests could be
forwarded to other computers on the network for which the SSH server is
merely acting as a secure access point into the network.

--
Kevin Powick

I have been working with Tunnelier as Kevin suggests. I took a look
at Pageant as Art suggests but that solution is a bit too rigorous.

Kevin Powick wrote:
That's the kicker. The telnetd is not running on the server.

I can start Tunnelier and get a connection into the remote server. If
I'm understanding this correctly that connection should be at Linux
shell when logged in.

I can also telnet to localhostort and connect to the local Tunnelier
server, which as above is connected to the remote server. So, so far,
we're end-to end.

On one hand I'll say I think there is still a mismatch between the
telnet client and the remote SSH server. The local telnet client (for
right now AccuTerm but that will change as soon as testing is
complete) doesn't get a response from the server. No data seems to be
flowing there.

On the other hand, I can't even do a local SSH and get a response from
the other side when the destination is 127.0.0.1/22.

I must be missing something in the config but I'm guessing this may
still not work with that telnet/ssh protocol difference.

Thoughts?
Thanks again!
T

"Tony Gravagno" <nospam (AT) nospam (DOT) invalid> wrote

I don't think there is any simple way to do that. All an ssh tunneling
connection will do is help your telnet client packets connect with the
{nonexistant} telnet server demon on the linux box. Or more
typically, with the xinetd demon which slaps an in.telnetd process on
each new connection to that port 23 of the linux server. Ssh just isn't
a protocol converter.

You can doublecheck your tunneling methodology by setting things up
to some other service on the linux box, like an email server or a web
page server, if they've got them... Often cups printing subsystem
provides a web page on the localhost 'nic' of linux, port 631 instead
of port 80. You'd have to research some basic introductory command
for each other protocol you tested with, like ehlo for email or get
for http, but beyond that telnet is pretty flexible for such testing.

Speaking of putty, I think there's a command-line switch that invokes
a certain saved 'session' line item....

The alternate spellings of the netcat command are nc ncat
on various platforms. Seems as handy as pick's tandem...

In redhat linux, you'd do netstat -nl to show what ports are open.

/etc/xinetd.d/telnet file is provided by the telnet-server rpm.
I say 'tunneling', but 'port forwarding' might be a better google target.

On Nov 16, 1:28*am, "Frank Winans" <fwin... (AT) sbcglobal (DOT) net> wrote:
Not sure if this helps but tunnelier has a way to port map (in both
directions) when it is connected

"c2s Fwding" tab
Add
Listen Interface: 127.0.0.1
Listen Port: 23 if you arent running a telnet server on your local
client ... or lets say 2300 for this example
Destination Host: 127.0.0.1 to connect to the remote ssh server but
this is rather pointless .. put the target host ip (say 11.22.33.44)
assuming that the ssh server can get to it
Dest.Port: 23 for the port.

Then in a console on the tunnelier client

telnet 127.0.0.1 2300

and it should actually connect (over ssh) to host 11.22.33.44 port 23

On Nov 16, 7:55*am, Tony Gravagno <nos... (AT) nospam (DOT) invalid> wrote:
Not sure if this helps but tunnelier has a way to port map (in both
directions) when it is connected

"c2s Fwding" tab
Add
Listen Interface: 127.0.0.1
Listen Port: 23 if you arent running a telnet server on your local
client ... or lets say 2300 for this example
Destination Host: 127.0.0.1 to connect to the remote ssh server but
this is rather pointless .. put the target host ip (say 11.22.33.44)
assuming that the ssh server can get to it
Dest.Port: 23 for the port.

Then in a console on the tunnelier client

telnet 127.0.0.1 2300

and it should actually connect (over ssh) to host 11.22.33.44 port 23

"Tony Gravagno" <nospam (AT) nospam (DOT) invalid> wrote

windows telnet server? {I seem to recall windows telnet is crippled to
only work with windows boxes at both ends of the link, but am not sure}
If so, then enable windows telnet server on the box the applet runs on,
and also install an ssh client there {I suppose openssh includes the client}
and have your applet telnet to localhost, then have the applet, as a
simulated user typing 'dos' commands inside that telnet session, issue an
ssh command to connect to the distant linux box. Maybe you can ease
the sticky parts by doing shared key ssh authentication instead of
password-based ssh authentication, and maybe you can do some kind of
windows profile magic {I can't} to issue the ssh command automatically
upon telnet logon. You may have to go to windows add/remove software
applet and install some optional windows component from the windows
install media to provide the telnet service on that winbox; I think it is
usually part of microsoft's IIS package...

If you cannot stomach a telnet server on the winbox, then plop in an
extra nic and a crossover cable to a spare linux box and make it accept
the telnet connection / ssh out to the originally-mentioned linux server.
Firewall that mini-me telnet server linux box so it only accepts telnet
packets on the nic with that crossover cable, and give it a 2nd nic to
use for the outbound ssh connection. Or make it a cdrom-based linux
and drop back to one network card and lighter security, as nobody's
going to ever hack a telnet server with no hard disk. Refer to
'linux on a floppy <leaf>' in google
{I admit I've never used such a thing; I just hope it can ssh out.}

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

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.


As Steve mentioned, you want to set-up your forwarding on the Tunnelier
C2S tab, not attempt it directly in your Telnet client. The settings
on this tab tell Tunnelier which interface/port combinations on which
to listen on the client side (ie 127.0.0.1/23) and forward them over
the SSH (port 22) tunnel to the appropriate server/port (ie
localhost/23) on the other side.

Also note that when connected via Tunnelier, you may have access to a
console session on the server. Allowing you check out configurations
settings there.

Not sure what you are trying to do, but don't try to use the SSH
features of a Telnet client if you are using a 3rd party SSH client
such as Tunnelier. I think you may be confused as to how SSH tunnels
(port forwarding) works.

--
Kevin Powick