In the U2 forum someone wants to use a .NET Telnet component to get
into U2/Linux, but do it securely. I keep encountering similar
requirements and I'd like to get this one nailed down. I believe
others here have done something similar so I'm hoping someone can
provide the required detail.

In the typical scenario, a socket is listening and expecting plain
text exchanges. This might be the QMClient server on port 4243, or
MVSP on port 9000, or the D3 ODBC server on 1603, or it could be a
nailed telnet session listening to something like 31023 where we can't
use SSH. I want to create a secure pipe across the internet, connect
into the system, switch to plain text, then connect into the socket.

So I'm considering using Tunnelier or another socket proxy utility to
bridge the internet connection securely, then attach to the exposed
Linux socket after the secured connection is established.

For example, rather than connecting from myPC to myHost on port 23,
we'd connect to myPC:9023 (arbitrary port), have that go securely
(SSH) across to myHost:9123 (again arbitrary), and then route from
9123 to 23 on what is now the Linux localhost.

Doing the local connection is easy, and again Tunnelier is a great
free tool for securing a local outbound connection. But on the Linux
side I'm not sure about what to do to wire the inbound SSH connection
to the actual target.

I believe in Linux we would use a command similar to this:
ssh -L :9123:localhost:23
The intention there is to say "accept SSL transactions on 9123, and
pass the decrypted payload to 23". At that point the Linux service
should get the transaction and process it as though it the encryption
never happened. And of course data flowing in the other direction is
similarly encrypted.

I am hoping someone here can verify, correct, or completely replace
this with something we can all use.

Thanks.
T

On 2011-08-02 12:07:07 -0400, Tony Gravagno
<tony_gravagno (AT) nospam (DOT) invalid> said:

You shouldn't have to do anything on the Linux target.

A port forwarding request is made by Tunnelier. If the SSH service
being provided by your Linux box supports such Client to Server port
forwarding requests, it should just work. Note that there may be
permission issues on the Linux side with which you have to contend, but
there should not be any special configuration for SSH port forwards on
the server.

So, using fictitious ports:

Tunnelier Listen Forward To
127.0.0.1 / 23 -----> localhost / 8023

Tunnelier is a great product, so is WinSSH, the server-side component
from BitVise for providing SSH on Windows.

Another good SSH client for Windows is MyEnTunnel. It's free, less
sophisticated than Tunnelier, but does a nice job. I provide it to my
clients so they aren't "distracted" by all Tunnelier has to offer.

--
Kevin Powick

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

Am I correct to understand that the SSH server automatically does the
port forwarding on that side? So telnet into port 23 on the client
and the transaction is encrypted on the wire. The SSH service gets
it, then forwards to port 23 on the localhost/server. So the port
used to receive the data on the client is passed in the payload?

Wow, that would be very simple indeed.

How close are we?

Thanks!
T

On 2011-08-03 00:23:16 -0400, Tony Gravagno
<tony_gravagno (AT) nospam (DOT) invalid> said:

I think you've got it, but I'll elaborate in case anyone else is
following along.

Yes, as long as the request was valid/allowed. Note that the
forwarding could even be to another box and not just "localhost (the
server)".


Yes, over the established tunnel. All data is actually sent over the
SSH connection (port 22), regardless of the forwarding destination.


I don't believe so. I think that the tunnel is preconfigured based on
the port forwarding request made by the client. If when logging on
with Tunnelier you watch the info messages scroll by during the
connection phase, you will see each port forward request being
established as a tunnel during that phase. Though, I could be mistaken
on this technical detail.

The problem most people run into when dealing with port forwarding is
conceptualizing what's happening at both ends. The idea of listen on
localhost and forward to localhost does not seem to make sense because
the user tends to view everything from where they are, at the
client/localhost. They must think it of in terms of both sides of the
equation:

* SSH client should listen on my machine (localhost) for data going to
ports for which I have requested port forwarding from the SSH service.
Such port-specific data will be sent over the wire (port 22) to the SSH
server.

* At the server, the SSH service will forward that request as
previously requested/defined. In most cases this is to a port on
localhost, the server itself, but could even be to a different server.
So, the following is possible.

Client Listens on: SSH service forwards to:
1) localhost: 8023 localhost: 23
2) localhost: 80 192.168.1.115: 80

Example 1. - Client listens for local requests on port 8023. SSH
Server/service forwards that request to port 23 on the server itself.
One could assume this is telnet data.

Example 2. - Client listens for local requests on port 80. SSH
server/service forwards those requests to port 80 on a different
server. One could assume this is HTTP/web traffic.

Again, and saying it in another way, the SSH client listens for
requests on a specific interface (127.0.0.1 = Localhost) for specific
ports. It sends that data over the established SSH connection (port
22) to the SSH service. It is the SSH service that forwards the data
to a specific server & port. This is usually localhost, the server
where SSH is actually running, but can be another box.

HTH someone because the first time I ran into it, I found it confusing as well.

--
Kevin Powick

That could be handy; we've got a camera on our lan that
we want to have email snapshots off-site from, but our
ISP blocks outbound connections on port 25 {smtp} for
security reasons. We could set up an ssh connection from
a lan linux box to an offsite ssh server that isn't under that
constraint, and request a port forwarding so the camera
can send the email to the lan linux box to reach the email
server out in the cloud.

That reminds me, redhat doesn't seem to care, but I notice
cygwin ssh server won't let you connect from an ssh client
at an ip address that doesn't have both normal and reverse
dns entries; that is, our isp hands us a leased ip address
that you can convert to a dns name {which reflects the name
of isp and region of country} but they're too lazy to put in
dns entries that let you convert that dns name back to an ip
address. The 'paranoid' line in cygwin's /etc/hosts.allow
file {I think} blocks the ssh connection as being a probable
spoofed ip address. We have to ask the admin to stick our
ip address in a prior line there to let us in... something to
look into if you cannot get an ssh link to form.

On 2011-08-03 09:15:38 -0400, "Frank Winans" <fwinans (AT) sbcglobal (DOT) net> said:

For Windows SSH services, check out WinSSHD from bitvise

http://www.bitvise.com/

It's a really nice product with a lot of capabilities and easy administration.

--
Kevin Powick

Kevin, thank you VERY much for clearly explaining what has always been
a mystery to me, not well explained in whatever I've read, and what
could open doors for a lot of us. As time permits I'll experiment
with this and share the experience.

As simple as this now sounds I'm wondering why secured communications
traditionally has been regarded as difficult or impossible with just
some of these products with which I've worked:
- D3 nailed telnet
- UO.NET
- QMClient
- mv.NET
- DesignBais (local HTTP and various Win/DBMS comms)
- MVSP
- ODBC

In very recent discussions TigerLogic maintains that MVSP cannot be
secured but that they will implement security in an upcoming D3
update. Why bother?

Now I'm waiting for someone in CDP to insist that Federal Express is a
much better way to transport data than SSH. *sigh*

T

On 2011-08-03 11:41:31 -0400, Tony Gravagno
<tony_gravagno (AT) nospam (DOT) invalid> said:

The issue with some of the items you mentioned is likely that the
communication method may not be strictly based on TCP/IP communication
over a single port. Also, some applications likely rely on services
such as netBIOS, COM, Windows RPC services, etc., where it is
difficult, or impossible, to modify the application's TCP ports for
these services. This being the case, if you defined your SSH client to
listen for data on one of these "well-known" service ports, you would
find *all* of your traffic going over the SSH link. This would be
undesirable.

--
Kevin Powick

PUTTY is another SSH client that supports tunneling and is free. You
can use the PLINK command to automate the tunnel setup, similar to the
Linux ssh command line.

On the server side for Windows hosts, which do not have built-in sshd
support, an idea that I have been toying with is to run a stripped
down Linux virtual machine to act as the ssh server, then forward
connections to the local Windows machine hosting the VM.

Thanks,

Peter Schellenbach

On 2011-08-10 11:45:37 -0400, pschellenbach <pjs (AT) asent (DOT) com> said:

I guess if you have the time and skill to set up and manage this, it
might be a neat DIY solution, but I would rather opt for a decent
product such as WinSSHD from BitVise. Not expensive either.

--
Kevin Powick