I'm kinda new to VNC, VPN, and running X apps over SSH. Actually, not kinda new. Totally new.

What's the best way to set it up and do it?

I used these and have never had any problems:

http://docs.slackware.com/howtos:security:sshkeys
http://docs.slackware.com/howtos:security:ssh

It can be quite handy to run sessions in screen.

In case it isn't clear, after you have remote access to the terminal via ssh (as described in the links above), you need to run a vnc server on the host and a vnc client on the client. (or a non-vnc rfb server, if you prefer) There are a number of choices, with advantages and disadvantages. Not all of the vnc server programs are completely interchangeable with all of the client programs. The latest version of the binary proprietary VNC program, in particular, doesn't allow older VNC protocols supported by the open source versions.

Next you have to forward some of your ports. I use the following on my client:
where the host has the remote port opened through your router or firewall.

Then I run a VNC program, eg. ./VNC-Viewer-5.1.1-Linux-x86 for the binary blob.

If you're using Windows as the client, then it's up to you, I use putty, then the VNC program for Windows.

If you're interested in just a users point of view:

I have only played with vncs so I'm sure my adives will be no were as good as others will have.

For personal vpn use i would just go for openvpn (their documentation is extremely easy to follow and a good read.. Headups if you're completely new have a look at a tun vs tap comparison): https://openvpn.net/index.php/open-s...ion/howto.html

And of course you might wanna scim through:
http://docs.slackware.com/howtos:net...rvices:openvpn

For ssh[d] man pages for the binaries and configs are sufficent.
If still confused about your specific question this is a bit easier to follow and should cover what you're trying to do and more:

http://serverfault.com/questions/530...itional-server

If you want to learn more about the internals google knows all about it.

You can use same port for listening and forwarding with ssh tunnel?

Yep client forward its local port 5900, to server own local port 5900 (127.0.0.1 is server localhost)

Don't forget to enable the "X11 forwarding" option of your sshd service

This is one of the ways I do it (SSH command simplified):

Once I have logged in to the remote machine I start a VNC server session. Since I use TightVNC as the server I don't need to have X running on the remote host, although I do need X installed. Just run vncserver to start the server session. TightVNC will then start a virtual X session at display :1 for the first session opened, :2 for the second, and so on. Then it's just a matter of opening a VNC client at your end and connecting to address 127.0.0.1:55901. Since SSH is forwarding port 55901 on localhost to 5901 on remote host, the VNC client will connect to the VNC server you just opened on remote, and the entire VNC session will be tunnelled through the secure channel. If you open a second vncserver session the display will automatically increment to :2 and you will need to adapt your SSH command and VNC client accordingly. In other words, for a second remote session, connect to 5902 instead.

With OpenVPN set up you don't need SSH. You can just connect directly to the VNC server. There are two ways of running OpenVPN - one with Tun and one with Tap. Tap might be marginally slower but it is easier in many ways because once you connect to your OpenVPN server the server and the machines at the remote end are all part of the same subnet created by the OpenVPN connection. In other words, if you use the Tap method and use 192.168.87.0/24 as your OpenVPN subnet all hosts connected to the VPN will be on that subnet, which means you can connect to your remote host as though it were on the LAN.

I realise I've repeated what others have said here but sometimes saying it a slightly different way clears things up a bit more.

1 members found this post helpful.

Another way of doing it, often overlooked, is XDMCP, which is particularly good on fast local networks. X, of course, was designed with networking in mind, and XDMCP is native X just doing what it was engineered to do: running X server and X client on the same physical host or on separate hosts.

Eric has instructions here.

A third way of doing it is to enable X forwarding on your SSH server, and then to run your SSH command as follows, so that X clients are forwarded from remote host to local X server:

This opens a SSH session to remote, with X forwarding and compression turned on. Then all you have to do is start a X client at remote in the terminal you have opened:

Now run uname -a in the xterm that has just opened and you will see that this particular xterm belongs to remote host. Of course you can start a window manager or complete desktop environment this way if you want.

I tried that but it didnt work I got:
Invalid MIT-MAGIC-COOKIE-1 keyxterm Xt error: Can't open display: localhost:10.0

A quick google showed to use also the -Y option. So with the line:
It worked out.

There's more info about -X vs. -Y in the ssh man page as well as in ssh_config man page and the part of the xauth man page under description for the generate command. -X tries to use the X security extension: http://www.x.org/wiki/Development/Do...tion/Security/ https://duckduckgo.com/l/?kh=-1&uddg...2Fsecurity.pdf

You may want to skim over some of that and give a little thought about whether security is a concern for you. Do you trust this remote server well enough to be sure of the programs they're running, that they won't read through all your other open X application screens or inject key presses in other applications in interesting ways?

You may also want to experiment with whether -C (compression) is faster or slower. I seem to remember something recently recommending against it. Oh yeah, it was in the man page:
"Compression is desirable on modem lines and other slow connections, but will only slow down things on fast networks. The default value can be set on a host-by-host basis in the configuration files; see the Compression option."

Case Study #1: X over ETHERNET (local LAN). Slackware's X have native support to run a remote X desktop. But, expect a relative huge data traffic, acceptable under local LAN. Also, VNC will help to reduce the data traffic.

Case Study #2: X over INTERNET. You can use only two solutions: VNC or NoMachine's NX, for saving the data traffic requirement. NX have better performances, offering a better compression and data management (i.e. use caching, etc).