VNC throiugh VPN or SSH

[jeff]

I've got a VNC server running on my home desktop Linux box, and I'd like
to be able to occasionally access it from a remote hotspot on a Windows
laptop. Doing this without encryption would be nuts, so I'm looking for
a reasonable approach, and the two that I've come up with use SSH or VPN
tunneling.

First question: If I enable Sonic's VPN on both the desktop and laptop,
will that ensure that my VNC session will be encrypted end-to-end? If so...

Second question: Is either of the two approaches markedly better from a
security point of view? (From a *simplicity* point of view, VPN would
be my first choice.)

Thanks for any insights!

Jeff

[(null)]

Post by jeff
I've got a VNC server running on my home desktop Linux box, and I'd like
to be able to occasionally access it from a remote hotspot on a Windows
laptop. Doing this without encryption would be nuts, so I'm looking for
a reasonable approach, and the two that I've come up with use SSH or VPN
tunneling.
First question: If I enable Sonic's VPN on both the desktop and laptop,
will that ensure that my VNC session will be encrypted end-to-end? If so...
Second question: Is either of the two approaches markedly better from a
security point of view? (From a *simplicity* point of view, VPN would
be my first choice.)

I would think ssh would be simpler. On the Linux box, firewall everything
except ssh and do everything via tunnels. If you use PuttySSH on Windows,
you can set the hostname, tunnels and pubkeys as one of the saved sessions
and have 1-click access.

But different strokes for different folks; if you can wrap your brain
around VPN better than ssh, then it may indeed be simpler.

To answer your two questions, VPN is encrypted from your Windows laptop
to your LAN. LAN to LAN-client could be unencrypted depending on where your
LAN-side VPN endpoint is located. Using ssh, you'd be encrypted from Windows
laptop to Linux box assuming a single ssh session. Just be sure to disallow
VNC connections from eth0, eth1, etc and only allow through lo.

-Dennis

[sidney]

Post by jeff
First question: If I enable Sonic's VPN on both the desktop and laptop,
will that ensure that my VNC session will be encrypted end-to-end? If

Using VNC on both would not be end-to-end encryption, but the only
unencrypted traffic would be on sonic.net's internal network, in the
subnet that contains the two ip addresses provided by the VPN
concentrator. In theory someone could be sniffing packets there, but I
think that would require physical access to sonic.net network
infrastructure. Unless you are super-paranoid that isn't something to
worry about.

On the other hand, you would have to set up something so that your
server advertises the external ip address that the VPN provides it so
that the laptop can find it. Perhaps you could do that using a dynamic
DNS service, but that sounds a lot more complicated than ssh tunneling.

Post by jeff
Second question: Is either of the two approaches markedly better from a
security point of view? (From a *simplicity* point of view, VPN would
be my first choice.)

I disagree about simplicity. SSH would be dead simple, and understanding
the security of the system would be easier. You configure the VNC server
to only allow connections from localhost (127.0.0.1). That immediately
closes off any vulnerability to someone connecting from outside without
having to set up any other special configuration. You run an ssh server
on your desktop. For extra security, have it listen on something other
than the standard port 22 so that people scanning for ssh servers to try
to guess passwords or any newly discovered exploits won't notice it.
For more extra security, set it up so that it only accepts key based
logins, not password based, and generate a public/private key pair to
let your laptop log in to it. That has the extra advantage that you can
have a script on your laptop do the login without you having to type a
password each time.

Then you ssh from your laptop to your desktop, using port forwarding to
forward the VNC port on localhost to the VNC port on the desktop's
localhost. With that running, you can run the VNC client on the laptop
to localhost and it will see the desktop machine.

In that configuration the connection is end-to-end encrypted, and the
security of the setup is that of an ssh login, which is well thought out
and debugged, better than any ad hoc double-VPN thing you might invent.

-- sidney

[(null)]

Post by sidney
For extra security, have it listen on something other
than the standard port 22 so that people scanning for ssh servers to try
to guess passwords or any newly discovered exploits won't notice it.

That'd be a pretty dumb port scanner to miss this screaming header:
$ telnet shell.sonic.net 22
Trying 208.201.242.19...
Connected to shell.sonic.net.
Escape character is '^]'.
SSH-1.99-OpenSSH_4.4_Sonic

BTW, if you want to dissuade brute force scanners, set up an iptables
rule that only allows x connections per y seconds from a given IP address.

-Dennis

[Wolfgang S. Rupprecht]

Post by (null)
BTW, if you want to dissuade brute force scanners, set up an iptables
rule that only allows x connections per y seconds from a given IP address.

This can come back to bite you if you ever try to use scp to copy a
handful of files to a machine protected this way.

(Its better to setup ssh to never allow password-based logins and only
allow RSA or DSA authenticated connections. That way you also don't
have to worry about someone using DDOS techniques to get around a
connection per IP limit.)

-wolfgang

[(null)]

Post by Wolfgang S. Rupprecht

Post by (null)
BTW, if you want to dissuade brute force scanners, set up an iptables
rule that only allows x connections per y seconds from a given IP address.

This can come back to bite you if you ever try to use scp to copy a
handful of files to a machine protected this way.

It's not a very hard bite. All you have to do is wait until y seconds
elapse after you realize that you should be copying all those small
files in a single session instead of opening/closing for each one.

Post by Wolfgang S. Rupprecht
(Its better to setup ssh to never allow password-based logins and only
allow RSA or DSA authenticated connections...

Agreed. (but sometimes that's not feasible...)

-Dennis

[Wolfgang S. Rupprecht]

Post by (null)
It's not a very hard bite. All you have to do is wait until y seconds
elapse after you realize that you should be copying all those small
files in a single session instead of opening/closing for each one.

Using one connection is, of course, the better way to work things.
The problem is (and I've done it myself plenty of times), the simple
act of hitting <CR> joggles the old brain cells and one remembers just
one more file one meant to sync up between the two systems. lather,
rinse, repeat.

-wolfgang

[(null)]

Post by Wolfgang S. Rupprecht
Using one connection is, of course, the better way to work things.
The problem is (and I've done it myself plenty of times), the simple
act of hitting <CR> joggles the old brain cells and one remembers just
one more file one meant to sync up between the two systems. lather,
rinse, repeat.

Yup, I've done it too. But like I said, if the timeout is set to something
reasonable, all you have to do is wait a few minutes and everything is
back to normal. This isn't something I'd do on a box with lots of users
like shell.sonic.net, but the original poster sounds like a single or few
user situation.

-Dennis

[sidney]

Well, it all adds up. My ssh daemon listens on a nonstandard port, so it
won't be found by someone hitting port 22 on blocks of ip addresses so
they can switch to dictionary attacks when they find an open ssh port;
It uses iptables to only allow ssh in from ip addresses that I use for
it which includes the shell.sonic.net so I can always get in from an
Internet cafe if I have to by going through sonic.net and then add the
cafe ip address if I want to; It only allows login using DSA or RSA
keys, no passwords, again with a key kept where I can get it into my
sonic.net shell directory so I can ssh in from shell.sonic.net and set
up a new key for a new machine if I have to when I am on the road.

-- sidney

[jeff]

Post by jeff
I've got a VNC server running on my home desktop Linux box, and I'd like
to be able to occasionally access it from a remote hotspot on a Windows
laptop. Doing this without encryption would be nuts, so I'm looking for
a reasonable approach, and the two that I've come up with use SSH or VPN
tunneling.
First question: If I enable Sonic's VPN on both the desktop and laptop,
will that ensure that my VNC session will be encrypted end-to-end? If so...
Second question: Is either of the two approaches markedly better from a
security point of view? (From a *simplicity* point of view, VPN would
be my first choice.)
Thanks for any insights!
Jeff

Some great insights from Dennis and Sidney - thanks to both.

I was thinking that VPN might be simpler only because I already use it
(on the laptop) for another app. And I spent a couple of hours last
night working through several Putty-SSH tutorials and blogs, without
much success, but - just for yucks - I'll revisit it today.

Jeff

[Simon Waddington]

I use OpenVPN with RDP to a Windows PC in bridged mode. I occasionally
see problems on some remote networks which I think are caused by UDP
packet size limits - I need to experiment with OpenVPN running over TCP
(less efficient).

Using VNC over OpenVPN may work better - open VPN is probably about as
simple to set up as SSH (IMHO), but allows more flexibility because you
can have access to all ports on your box and visa versa once you're on
the VPN. I expect SSH may be a tad more efficient (especially compared
to OpenVPN bridged mode).

Simon

Post by jeff

Post by jeff
I've got a VNC server running on my home desktop Linux box, and I'd
like to be able to occasionally access it from a remote hotspot on a
Windows laptop. Doing this without encryption would be nuts, so I'm
looking for a reasonable approach, and the two that I've come up with
use SSH or VPN tunneling.
First question: If I enable Sonic's VPN on both the desktop and
laptop, will that ensure that my VNC session will be encrypted
end-to-end? If so...
Second question: Is either of the two approaches markedly better from
a security point of view? (From a *simplicity* point of view, VPN
would be my first choice.)
Thanks for any insights!
Jeff

Some great insights from Dennis and Sidney - thanks to both.
I was thinking that VPN might be simpler only because I already use it
(on the laptop) for another app. And I spent a couple of hours last
night working through several Putty-SSH tutorials and blogs, without
much success, but - just for yucks - I'll revisit it today.
Jeff

[(null)]

Post by jeff
I was thinking that VPN might be simpler only because I already use it
(on the laptop) for another app. And I spent a couple of hours last
night working through several Putty-SSH tutorials and blogs, without
much success, but - just for yucks - I'll revisit it today.

At PuTTY Configuration (startup), enter the hostname, port 22, ssh.
Click on Connection->SSH->Tunnels. For "Source Port", enter "5901".
For "Destination", enter "localhost:5901". Options are "Local" and "Auto".
Click "Add". Click "Open". Enter username/passwd (assuming you
are set up for passwd login, the typical default). From Linux shell,
type "vncserver :1", if vnc isn't already running on screen 1.

On Windows machine, start VNC Viewer and open a connection to "localhost:1".

If you don't have a native VNC viewer installed, forward
port 5801 to localhost:5801 start a java enabled browser
and open URL to "http://localhost:5801".

-Dennis

[jeff]

Post by (null)

Post by jeff
I was thinking that VPN might be simpler only because I already use it
(on the laptop) for another app. And I spent a couple of hours last
night working through several Putty-SSH tutorials and blogs, without
much success, but - just for yucks - I'll revisit it today.

At PuTTY Configuration (startup), enter the hostname, port 22, ssh.
Click on Connection->SSH->Tunnels. For "Source Port", enter "5901".
For "Destination", enter "localhost:5901". Options are "Local" and "Auto".
Click "Add". Click "Open". Enter username/passwd (assuming you
are set up for passwd login, the typical default). From Linux shell,
type "vncserver :1", if vnc isn't already running on screen 1.
On Windows machine, start VNC Viewer and open a connection to "localhost:1".
If you don't have a native VNC viewer installed, forward
port 5801 to localhost:5801 start a java enabled browser
and open URL to "http://localhost:5801".
-Dennis

Already got that working a short time ago - next step is to setup
public/private keys. The thing that makes all of this so difficult,
BTW, is that I don't do it on a regular basis, so, whenever it comes up,
I have to reconstruct everything I did/knew from scratch. Yup, keeping
notes helps some, but I still hope that in my next lifetime, our species
has evolved enough so that we don't need all of this crap.

Jeff

(Thanks for your concise summary... I'll definitely hold onto that.)

[Brad Allen]

Since I already have my own experience with this, I skipped the other
responses so you can know what I know simply enough. Useful comments
appreciated.

In article <453cfe9b$0$88705$***@news.sonic.net>,
jeff <***@spam.invalid> wrote:
" I've got a VNC server running on my home desktop Linux box, and I'd
" like to be able to occasionally access it from a remote hotspot on a
" Windows laptop. Doing this without encryption would be nuts, so I'm
" looking for a reasonable approach, and the two that I've come up
" with use SSH or VPN tunneling.
"
" First question: If I enable Sonic's VPN on both the desktop and
" laptop, will that ensure that my VNC session will be encrypted
" end-to-end? If so...

Nope. Sonic.net's VPN is only between you and Sonic. Between Sonic
and whereever else, it is not encrypted. This includes from
Sonic.net's VPN to your host machine, even if just via the Public
Switched Network's ATM cloud (all of which is assembled in big spy
databases run by untrustworthy entities, so quite the opposite of
secure).

OTOH if you VPN from both hosts to Sonic.net's VPN computer, the only
connection unencrypted would be from the VPN computer at Sonic.net to
the VPN computer at Sonic.net, then back again in the other direction.
The benefit there is that that connection is most likely pretty short
(although that's not guaranteed??) and should be harder to hack.

" Second question: Is either of the two approaches markedly better
" from a security point of view? (From a *simplicity* point of view,
" VPN would be my first choice.)

Odd. I found SSH easier. I already had it configured and knew how it
worked, so that probably made a big difference.

VPN is REALLY easy to accidentally do insecurely: simply forget, or if
VPN shuts off, it just reverts to no VPN without much (or any) notice
at all. SSH will kill your connection along with the tunnels you are
depending on, thus causing security within the connection to be
preserved almost no matter what. (That's why I do alwaysshared so
that I can simply reconnect again whenever the connection goes away,
and my session is saved, much like "screen -xRR" in tty sessions.)

" Thanks for any insights!
"
" Jeff

vncserver :1 -geometry 1000x740 -alwaysshared -httpport 8080

A second sshd with sshd_config line "Port 80" helps to get around many
library port filters.

U.ARIZONA.EDU

your.ip.number.or.host.name:80
login
password

Options -- encryption
Options -- SSH2
Options -- compression
Options -- simple forwardings ... 5901:127.0.0.1:5901
Options -- simple forwardings ... 8080:127.0.0.1:8080

New window: 127.0.0.1:8080

PASSWORD PROTECT YOUR VNC!!!! There is a flaw here: if you have bad
passwords, that can be broken sometimes, but not always.


All you need is JAVA in your Browser -- gets around filters, and is
encrypted. COULD BE HACKED by libary personnel, though, since your
security is in the library computer. (This is why bringing your own
laptop is good.)


Ok, let's say you have your own computer with XP, and you can install
your own programs. Putty SSH. Options: SSH2, compression, forwarding
5901:127.0.0.1:5901 or 5903:127.0.0.1:5903 or whatever. You can
usually do something like 5905:127.0.0.1:5902. Connect and log in.
(Sounds like put pot on oven and cook.)

Then, get the XP version of VNC (look for Google VNC download XP). Do
VNC Viewer, e.g., :1. :1 is alias for 127.0.0.1:1. Of course that
goes via SSH tunnel.

Security ideas: only allow connections from local host, since SSH is
the only protocol going interhost. You only allow from local host in
both VNC (server) and SSH (both sides since doing forwarding). Read
both documents for how to do this, as well as /etc/hosts.allow and
/etc/hosts.deny. Use all methods, and TEST each breach method (both
before and after to see what it does).




VPN? That would also work. What I know is SSH since it's so easy.

[drcean at sonic]

Post by jeff
I've got a VNC server running on my home desktop Linux box, and I'd like
to be able to occasionally access it from a remote hotspot on a Windows
laptop. Doing this without encryption would be nuts, so I'm looking for
a reasonable approach, and the two that I've come up with use SSH or VPN
tunneling.
First question: If I enable Sonic's VPN on both the desktop and laptop,
will that ensure that my VNC session will be encrypted end-to-end? If so...
Second question: Is either of the two approaches markedly better from a
security point of view? (From a *simplicity* point of view, VPN would
be my first choice.)
Thanks for any insights!
Jeff

I have a couple of cents to add to all the many replies:

1) From the command line, I use: "ssh -L 5900:<ip>:5900 <ip>" (This is
for screen 0 on the server and client--add screen number for other
screens.) Then I connect to localhost:0 from the client using vncviewer.

2) x11vnc allows you to access an already running X session so you don't
need the overhead of an additional VNC server.

--
Daniel