So, you just want to connect to a REAL X session. That is, user "foo" is running an X session, and another one is logging remotely to that session as "foo".
The other option is connecting remotely to a virtual X session. That session will not display the running applications and processes in the real display (the real is usually "display :0", the first virtual one "display :1" and so on - while if noone is logged in locally, the first virtual session will be at "display :0", the second one at "display :1" and so on.
Apparently, you are after the first option.
Here's what I do. I have a remote machine which is running XFCE4, and when powered one it automatically logs user "foo" in, and runs the XFCE4 desktop, plus a couple of applications (for that I use the xfce4 startup manager).
1. Install x11vnc. IMHO it's the best server for managing real X displays- way faster and more stable than krfb or vino.
2. Create a vnc password, if you don't have one already:
CODE
x11vnc -storepasswd
This will create the password file ~/.vnc/passwd
Now, create an x11vnc initialization file. Open a console as user "foo" and
CODE
nano /home/foo/.x11vncrc
Add in there
CODE
forever
rfbauth /home/foo/.vnc/passwd
display :0
Save, exit, and make it executable:
CODE
chmod +x /home/foo/.x11vncrc
In all of the above, replace "foo" with the actual username.
Now, you can simply add
CODE
x11vnc -noncache
to be executed when the desktop is loading (easy ro figure out how, or not?). However, I find it safer to have it shut down, and trigger it remotely via ssh. I simply log in via ssh as "foo", and start the vnc server using the same command:
CODE
x11vnc -noncache
Then, just minimize the ssh console, and use your vnc client to log to the remote desktop. I prefer the realvnc client to the tightvnc one- for me it's more stable, but use whatever works best for you...
The above method works fine for KDE, Gnome, XFCE4, or any other window manager/desktop environment - and has the advantage the vnc server not being open all the time. If you close the ssh console, then the secure connection will close, and with it the vnc server will be killed.
You can do more than that, e.g. tunnel the whole vnc session via ssh (more secure, but somewhat reduced performance), or use nxserver instead: the new server version supports both virtual and real X displays, and is said to perform better than vncserver. However, I've not used it yet, as x11vnc fits me rather well.