With the settings in the question is right without problem.
The Solution to Xming for Windows in the case is like this:
The running order of Xming and Putty
After installation of Xming for Windows, just run Xlaunch
to config and then run xming.
Config option: for
- multi windows
- start no client
- and then next and complete
Once it(Xming) is opened, It will stay in Windows taskbar.
Then run Putty for the SSH account well configured for X11 Forward, this time, when xclock
is run in the command, it will then forward to XWindows and open in your Windows desktop.
** the current Login identity for current session is also important **
If using SSH to connect Azure, the default user is not root. To elevate the privilege, using command sudo su
is necessary. If running Xming with Putty and X11 Forwarding turned on. The forwarding is working for the first login. If issued the sudo su
command. The link will be broken and GTK application such as xclock is no more working for the elevated account.
So make sure this is the first login user and to test the desktop installation, run xclock
in the command line, if in Putty, error message will be displayed for it cannot be opened.
For CentOS 6.5, tigervnc-server is needed
However, when the VNC is connected, it is blank with nothing. Because the Vino Server is VNC server for Gnome. To properly install VNC server, tigervnc-server is necessary.
For details please refer to CentOS HowTos -> VNC-Server
Tips:
The previous failure is mainly due to using Xlaunch to create a config to run for Putty which is a tutorial found in the web which is not working. The above running order make it working in my own case. I cannot say the not working method is wrong, maybe it is for other purpose that I didn't know yet.
After that, because Xming is working for xclock, so it is also working for vino-preference
now. The VNC is then immediately working to connect the remote Linux on azure after check the Allow other users to view your desktop
option and uncheck You must confirm each access...
. But because in non-root-elevated, vino-preference
is not being saved, it is not a proper way to setup the VNC, please refer to above link for details.
Best Answer
You get two categories of options:
Using X11 for its client-server capabilities.
X11 is designed as a client-server protocol, so your application effectively connect to the X11 server to display their windows. In the X11 model, the application is the client and the display is the server.
As an example, if you're sitting next to machineA and machineB is your remote Linux server, you can SSH from machineA to machineB (so machineA is the client as far as SSH is concerned). Then, if you run
xeyes
(or any X11 application), machineB will be the client to connect to machineA's X11 server (as far as the X11 application is concerned).For this to work, you need an X11 server running on machineA. This is not a problem. Linux systems with a desktop environment will have one out of the box. On Windows, you can use the one provided with Cygwin, or perhaps Exceed.
To secure such a connection, use
-X
(or-Y
if you trust the server) withssh
from a Linux box (machineA), this will automatically forward the X11 connections back to your machineA, tunnelled via SSH. Similarly (since in your use case, machineA is running Windows), SSH clients such as Putty have a option to forward X11.Using a full remote desktop environment.
You can set up a VNC server (or similar, RDP, ...) on the remote machine and connect to it from a VNC client. (The notion of client and server is perhaps more intuitive in this model.) If your VNC server isn't running by default, you might have to log on via SSH manually to start it up. You're more likely to get a "full desktop" with this method (it ultimately depends on how it's configured), so you won't need to know the commands to launch the GUIs you want to use.
UltraVNC seem to have an option to have it secured out of the box in their commercial product. If you want to secure such a connection manually, you'll probably have to connect to this machine via SSH and tunnel the VNC port on the remote server to your client machine.
In general, the second option (full desktop) will be faster.