l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
April 21: Google Glass
Next Installfest:
TBD
Latest News:
Mar. 18: Google Glass at LUGOD's April meeting
Page last updated:
2001 Dec 30 17:11

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] X, SSH across Internet through NAT
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] X, SSH across Internet through NAT



I already did get it to work.  Not much to write up:

1) Download latest version (development) of putty
2) Launch putty (no install, because the download is an executable)
3) Under session fill in the box labeled "host name or IP"
4) Under connection fill in the box labeled "user id"
5) Under tunnels check "Enable X11 forwarding"

Jay

----- Original Message -----
From: <speck@blkmtn.org>
To: <vox-tech@franz.mother.com>
Sent: Tuesday, October 16, 2001 4:32 PM
Subject: Re: [vox-tech] X, SSH across Internet through NAT


> Jumping in late.
>
> I successfully used cygwin, with the XFree86 port on my WinNT4 work
system.  I would launch XFree into in X Window session, then from the
terminal window I would type
> ssh -X -l username domain.com
>
> The -X exports it across the connection and the -l is for the logon with
this name.  This worked fine for me.  I need to write this up for the lugod
faqs section.  Write up your method when you get it to work with putty.
>
> -sp
>
> On Fri, 12 October 2001, "Jay Strauss" wrote:
>
> >
> > Yippee, it works.  I needed to download the latest (development) version
of
> > putty.  It supports X11 Forwarding.  I just got an xterm on from my
machine
> > at home, Pretty cool.
> >
> > Thanks ME
> > Jay
> > ----- Original Message -----
> > From: "ME" <dugan@passwall.com>
> > To: <vox-tech@franz.mother.com>
> > Sent: Friday, October 12, 2001 2:22 PM
> > Subject: Re: [vox-tech] X, SSH across Internet through NAT
> >
> >
> > > On Fri, 12 Oct 2001, Jay Strauss wrote:
> > > > Is this possible, I have (crappy) linksys dsl router/NAT devices set
up
> > > > on other sides of the internet.  Behind one is my SSH client, behind
the
> > > > other is my SSH server (on my deb box):
> > >
> > > It can be done if you can establish an ssh session from the source
NAT-ed
> > > host to the destintaion NAT-ed host.
> > >
> > > > SSH                                  SSHd
> > > > Client                               Debian
> > > > (putty)                              192.168.5.102
> > > > 192.168.5.100
> > > >      |                                  |
> > > >      |                                  |
> > > >      |                                  |
> > > >      |               internet           |
> > > > 192.168.5.254   ===================  192.168.5.254
> > > > Linksys                              Linksys
> > > > NAT                                  NAT
> > > > xxx.xxx.xxx.xxx                      yyy.yyy.yyy.yyy
> > >
> > > Cool ASCII Drawing. (ME likes it)
> > >
> > > > I am able to SSH from the client to the server, but when I try to
start
> > an
> > > > xterm:
> > >
> > > Whoah! Dejavu!
> > >
> > > > 192.168.5.102:jstrauss> xterm -display xxx.xxx.xxx.xxx
> > >
> > > In this case, you are probably trying to tell the remote machine to
use an
> > > X $DISPLAY that would try to connect to the NAT-ed IP address and
there is
> > > no service on the NAT linksys router to perform this by default. Also,
the
> > > remote host does not know how to get to your reserved network IP
address
> > > used in the NAT LAN at "home".
> > >
> > > By default most new ssh clients/servers seem to be shipping with
disabled
> > > X forwarding by default due to security conerns with X.
> > >
> > > > It just hangs.  Now I figure I can't really send the display to the
> > linksys
> > > > device in front of my client, but where
> > > > else can I send it?  I can't send it to 192.168.5.100, cause it will
try
> > to
> > > > route to it's local LAN.  Is what I'm trying impossible?  I thought
you
> > > > could run X through (some sort of encrypted tunnel) ssh all the way
back
> > to
> > > > the client.
> > >
> > > You can generally offer X updates/draw through an ssh session, but
there
> > > are security implications with this. If you have one of the newer ssh
> > > varients (openssh or ssh2) then check the options when starting ssh.
For
> > > one, I think you can add "-X" and the other you can add "-x" to
explicitly
> > > state you want to tunnel X through SSH. (Not exactly sure, which is
which
> > > ans which one uses "-X" for enable, but one seems to use -x for
disable,
> > > so check your man pages to be sure.)
> > >
> > > Once you have enabled X through SSH, you will/should have a new env
var on
> > > the remote machine called $DISPLAY. echo $DISPLAY in the shell on the
> > > remote machine to see if it is set. It will probably be a local high
port
> > > like "yourhostname:11.0"
> > >
> > > You should be able to then start X apps on the remote location and
have
> > > them appear on your local screen automagically.
> > >
> > > The cost of X through ssh is you will take a processor hit, and smooth
> > > graphics and video won't be so smooth. You will/should notice more lag
> > > than when you compare it to a non-encrypted session. If you are going
from
> > > one NAT-ed host to another NAT-ed host, using an ssh session is the
> > > easiest way to get the stuff to yourself, but with the cost of speed
and
> > > the X security issue.
> > >
> > > > One more thing, when I'm pick up my laptop and bring it home (onto
the
> > LAN
> > > > where my sshd is located).  I'm able to get an xterm sent sent
locally,
> > but
> > > > how do I know its even using the ssh tunnel and not just sending it
> > clear
> > > > text?
> > >
> > > Use a sniffer. :-) Or you can examine your env variable $DISPLAY to
see if
> > > it is set to send to the remote host, or is using the localhost and
then
> > > SSH.
> > >
> > > Also, I just noticed that you mention "putty" as your client side.
Most of
> > > the above (-X flag for enabling X session stuff) is/was for the
> > > openssh/fsecure ports of client ssh. I have not used this client
(putty),
> > > so you should check to see if it offers X11 forwarding/redirection. If
it
> > > does, then make sure you have enabled this option. If this is on
Windows
> > > (Win32) then you need to have an X11 Server for windows (or if on the
mac,
> > > then one for the mac).
> > >
> > > If you do not have an X-Server for your windows/mac machine, i think
you
> > > can get one for trial for Mac or Windows called MI/X
> > > http://tnt.microimages.com/www/html/freestuf/mix/
> > > I used that before (or at least an earlier one) and it seemed to work
for
> > > most of the things I wanted to use at the time. It was rather feature
> > > limited, but the price at the times sounded right.
> > >
> > > There was one out there called Hummingbird Exceed or soemthing like
that
> > > but I think it co$t a bit more. People that have used said they liked
it,
> > > but what do people know anyway? They are only human. ;-)
> > >
> > > Others here may have more up-to-date suggestions on W32 based XServers
> > > that are fresh on the menu.
> > >
> > > -ME
> > >
> > > P.S. Just found from from putty docs:
> > > http://www.tartarus.org/~simon/puttydoc/output.txt
> > > 3.16.1 X11 forwarding
> > >
> > >        If your server lets you run X Window System applications, X11
> > >        forwarding allows you to securely give those applications
access to
> > >        a local X display on your PC.
> > >
> > >        This feature will only be useful if you have an X server on
your
> > PC,
> > >        such as Exceed or XWin32.
> > >
> > >        To enable X11 forwarding, check the `Enable X11 forwarding'
box. If
> > >        your X display is not the primary display on your local machine
> > >        (which it almost certainly will be unless you have deliberately
> > >        arranged otherwise), you need to enter its location in the `X
> > >        display location' box.
> > >
> > > Which really answers your last Q more more directly.
> > > That options should set the env var $DISPLAY on the remote machine.
Check
> > > echo $DISPLAY to see if it does.
> > >
> > > -----BEGIN GEEK CODE BLOCK-----
> > > Version: 3.12
> > > GCS/CM$/IT$/LS$/S/O$ !d--(++) !s !a+++(-----) C++$(++++) U++++$(+$)
> > P+$>+++
> > > L+++$(++) E W+++$(+) N+ o K w+$>++>+++ O-@ M+$ V-$>- !PS !PE Y+ !PGP
> > > t@-(++) 5+@ X@ R- tv- b++ DI+++ D+ G--@ e+>++>++++ h(++)>+ r*>? z?
> > > ------END GEEK CODE BLOCK------
> > > decode: http://www.ebb.org/ungeek/ about:
> > http://www.geekcode.com/geek.html
> > >      Systems Department Operating Systems Analyst for the SSU Library
> >
> >
> > _________________________________________________________
> > Do You Yahoo!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
>


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.