SSH's X11 forwarding is a bit more than generic port forwarding, and it probably is the simplest way to achieve what you want, at least from the user's viewpoint.
If you want technically simpler, you'll need to understand how X11 was originally envisioned to be used.
In an environment with a number of X11-capable computers, the user information might be centrally managed with NIS and home directories shared from a dedicated disk server to all the other computers with NFS (with a bit of automounter thrown in). All the computers would also have to be able to resolve each other's hostnames. In a trusted internal network, you (it was assumed) would not disable the TCP listening port of your X11 server.
In such an environment, you could connect from one host to another, and only need to make sure the DISPLAY
environment variable was set properly to have any remote X11 client program make a direct connection to your local X11 server, and thus, to your local display. Since the home directories are shared with NFS, the same ~/.Xauthority
would be seen by both the remote and the local host.
If there was no NIS? That is not a problem for X11: it does not really care about identity. As long as any client connecting to the X11 server can present the correct X11 authentication cookie from the ~/.Xauthority
file (or a non-default file pointed to by the XAUTHORITY
environment variable), X11 would work. However, without shared UID/GID number assignments, sharing the home directories might not be possible.
Without a shared home directory? In that case, you would also need to pass the X11 authentication cookie, typically by extracting it on your display host with e.g. xauth nextract /some/file :0.0
, then getting the contents of /some/file
transferred to the remote host using whatever method, and using xauth nmerge
there to add it in the remote host's ~/.Xauthority
file.
(Or you could use xhost +
to disable the security check, either entirely or for specific remote host only. But that turned out to be a very bad idea: if the remote host had other users, doing that opened you up for getting xsnow
ed in, or for an xroach
infestation, or worse things like getting all your keyboard and mouse events for you entire X11 session monitored.)
But the unencrypted X11 protocol was found to be a pretty big security weakness. Because of what the USA's crypto export laws were at the time, the world settled on using SSH with X11 forwarding and disabling the TCP port of the X11 server. It became the norm to see the X server started as Xorg -nolisten tcp <other options...>
.
Fairly recently the X.org has recognized this and flipped the TCP listening logic: if your Linux distribution starts an X11 server without the -nolisten tcp
option by default, it might be because your X11 server version actually requires an explicit -listen tcp
option to enable the classic and insecure X11 TCP listener.
So... yes, you could:
- enable the TCP listener on your host's X11 server
- make sure your VM can resolve the host's IP address and connect to host's port 6000 (= corresponds to DISPLAY
:0.0
over TCP)
- arrange for your VM to have the
DISPLAY
variable point to kvmhost:0.0
- take the necessary steps to get the X11 authentication cookie passed to the VM
That would allow X11 to work the "classic way", with minimal added technical complexity. But it's quite a lot more complicated to actually set up than just using ssh -X virtualmachine
, and may open you up for various old, well-known attacks.
qemu
directly (with itsguestfwd
option), no need forssh
. There may be more interesting ways to speed up things, but that needs a bit more testing and research. But I'm not using libvirt/virtmanager (I'm using qemu+kvm directly), so I'm not sure I can help you. – Mar 24 '19 at 19:37virt-manager
? – Michael Hampton Mar 25 '19 at 14:10