On Jun 2, 1:40am,
foodog@uswest.net wrote:
> Kevin Buettner wrote:
> ...snip
> > Two points:
> >
> > 1) It can't work because 192.168.X.Y are private network numbers.
> > (And you'll never be able to get a route to one of these numbers
> > from the outside.)
>
> Au contrair, dude. If you are God of your firewall or
> router you can do any number of goofy routing tricks. This
> may not be the best way, it's certainly not the only way,
> but it's the first thing that worked for me so far:
Yes, setting the display to the address of your firewall and then
portwarding (using "ipmasqadm portfw") it to one of your internal
machines will work, but it's not encrypted.
>
> > 2) Even if it could work, you wouldn't want to do things this
> > way because if you'd likely be sending the X protocol data
> > unencrypted.
>
> Since the session has been established via ssh I'm assuming
> for now that the traffic's encrypted - none of the raw
> packets I've looked at had anything recognizable anyway.
> Doing the same thing with TELNET instead of ssh I can see
> cleartext goodies in the packets.
Right. But in order to make use of the encryption, you must
make sure you don't go around it.
When you set your DISPLAY to anything other than the port on
the remote machine that's connected via ssh to your local
machine, you're going around the encryption. Sure, anything
you type into the shell is still encrypted, but the X clients
that are communicating with your display server are sending /
receiving packets in the clear. Fire up tcpdump to verify this
for yourself.
Kevin