Logging in into a Linux machine and executing the hundreds commands available is just one of the most common usages of OpenSSH. Another interesting and very useful usage is tunneling some specific (or even all) traffic from your local machine to an external machine you have access to.
Today we’ll analyze how to access a certain virtual machine’s console by tunneling the relevant VNC port locally and accessing it through your favorite VNC client. The scenario:
- Machine A is our main virtualization machine and hosts several virtual machines. (VMs)
- Each VM has its own VNC port assigned. (usually the port range goes from 5900 to 5910 or even more if the hosted VMs are more than 10)
- We’ll be using libvirt, thus virsh.
We first need to find out which port got assigned to the VM we want to have console access to:
sudo virsh virsh # list Id Name Status ---------------------------------------------------- 5 foo running 6 bar running 7 foobar running virsh # vncdisplay foobar :3
We, then, create a tunnel which redirects all the traffic from the main virtualization machine’s port to the port we gonna specify in the next command:
ssh -f -N -L 5910:localhost:5903 user@machine-A.com
A few details about the previous command:
- -N tells SSH to not execute any command after logging in.
- -f tells SSH to hide into the background just before the command gets executed.
- -L enables the port forwarding between the local (client) host and the host on the remote side.
And…why did I choose respectively port 5903 and 5910?
While you can adjust port 5910 with your own choice (that will just move the tunneled traffic from port 5910 to your favorite port), that won’t work as expected with port 5903 since each VNC port is binded to the number of display virsh assigned to it. (for example, the bar VM may be running on display 5, thus its vncdisplay port will be 5905)
When done, fire up your favorite VNC client and create a new connection with the following details:
Protocol: VNC - Virtual Network Computing Server: localhost - 127.0.0.1 Port: 5910
The connection will load and you’ll be put in front of your ‘foobar’ VM console.
That’s what virt-manager is for. Which also does the work for Spice displays transparently.
Virt-manager requires GNOME to be installed on the main virtualization machine and I try do avoid that in any case on production machines.
virt-manager(1) does not have any GNOME or GTK dependencies. It does have X dependencies, however.
See also the -via option for vncviewer. Slightly easier.
vncviewer already supports creating tunnels using the -via command line option.
if these guest VMs are mostly-headless linux servers IMO it’s nicer to make them completely-headless by setting up serial consoles and using “virsh console ” on the host and avoid VNC. (in fact, you can avoid the emulated VGA hardware and console getty’s in the guest VM entirely, even during installation.)
See sshuttle – basically it is a fully automatic VNC-over-SSH in a box.
Excuse me? virt-manager needs gtk on the management host, not GNOME on the virtualization host.
For a really-easy way to do VNC over SSH, you can also use “remote desktop viewer” (vinagre).
Connect → Protocol: VNC, then check “Use Host ____ as a SSH tunnel” (and fill in the host.
virt-viewer was written for this exact use case. To use it over ssh, you can do something like:
virt-viewer -c qemu+ssh://user@hostname/system name-of-vm
You run this on your desktop system, so it doesn’t impose any additional requirements on the server side. It takes care of setting up the tunnels and everything. It’s quite convenient.
Andrea Veri: SSH Tunneling for VNC – http://t.co/u7gEaqJP
[...] execute any command on the remote machine when connectedTunnel initiated!Related articlesSSH Tunneling for VNCSSH KeysSSH and SCP: Howto, tips & tricksSSH tip: Send commands remotelyHow To: Send and receive [...]