GNOME Bugzilla – Bug 751580
Use ssh to connect to SPICE display of remote libvirt box
Last modified: 2018-01-11 10:24:56 UTC
After a lot of trial and error I have finally succeeded to connect to a remote libvirtd using qemu+ssh://... (someone should really, really, clarify that "system" used in all the examples is NOT the system (i.e. host) where your libvirtd runs!). Now I have some nice console thumbnails. Problem is: I cannot connect to the guests because their spice servers listen on the local interface only. I cannot change this, it is part of the security concept for the virtual machines. Obviously, virt-manager uses ssh to connect to the spice servers -- it's no problem to open a guest's console from virt-manager. I think boxes should act like virt-manager.
(In reply to mnl from comment #0) > After a lot of trial and error I have finally succeeded to connect to a > remote libvirtd using qemu+ssh://... (someone should really, really, clarify > that "system" used in all the examples is NOT the system (i.e. host) where > your libvirtd runs!). You'll have to file a bug report on libvirt for that. > Now I have some nice console thumbnails. Problem is: I cannot connect to the > guests because their spice servers listen on the local interface only. I > cannot change this, it is part of the security concept for the virtual > machines. Are you are talking about security policy of this particular server or libvirt (and virtual machines in general)? If it's latter, it's not true and you do want to enable spice on non-local interface. SPICE is mainly targetted for remote case and hence is not less secure than ssh. > Obviously, virt-manager uses ssh to connect to the spice servers -- it's no > problem to open a guest's console from virt-manager. I think boxes should > act like virt-manager. I assume by 'console' you mean 'display'. I'll see how virt-manager handles this case differently.
(In reply to Zeeshan Ali (Khattak) from comment #1) > You'll have to file a bug report on libvirt for that. (Well, gnome-boxes' "Help" text could also be more helpful in this regard, but I admit that I shouldn't mix two issues here.) > Are you are talking about security policy of this particular server or > libvirt (and virtual machines in general)? If it's latter, it's not true and > you do want to enable spice on non-local interface. SPICE is mainly > targetted for remote case and hence is not less secure than ssh. This is about access rights, not about transport security. For this particular server, the policy is that access to virtual machines' displays should only be possible for users with an account on that server. > I assume by 'console' you mean 'display'. Of course. Is it not the console that is displayed here? Too difficult for non-native speakers... I simply mean whatever you see on the physical monitor of a physical (not virtual) computer. > I'll see how virt-manager handles this case differently. Thanks a lot!
(In reply to mnl from comment #2) > (In reply to Zeeshan Ali (Khattak) from comment #1) > > You'll have to file a bug report on libvirt for that. > (Well, gnome-boxes' "Help" text could also be more helpful in this regard, GNOME docs team is a small set of folks (4 I think and 2 of which are volunteers). > > Are you are talking about security policy of this particular server or > > libvirt (and virtual machines in general)? If it's latter, it's not true and > > you do want to enable spice on non-local interface. SPICE is mainly > > targetted for remote case and hence is not less secure than ssh. > This is about access rights, not about transport security. For this > particular server, the policy is that access to virtual machines' displays > should only be possible for users with an account on that server. Enable a password on the VMs and give it only to appropriate users? Or have the same password as the account? Could you please provide the XML configuration (or at least the 'graphics' node) of one of these VMs? Boxes simply uses the configuration of the VM.
(In reply to Zeeshan Ali (Khattak) from comment #3) > Enable a password on the VMs and give it only to appropriate users? Or have > the same password as the account? I considered that as a workaround, but it's not really possible due to organizational reasons. > Could you please provide the XML configuration (or at least the 'graphics' > node) of one of these VMs? Boxes simply uses the configuration of the VM. That's easy: <graphics type='spice' autoport='yes'> <mouse mode='client'/> </graphics> I haven't looked at the code, but I assume that virt-manager simply uses spice+ssh if the connection to libvirtd has been established using ssh.
Looked at the code, finally. It's virt_viewer_app_open_tunnel_ssh() in virt-viewer that does all that by launching a socat command on the remote end to tunnel the spice socket. IMO libvirt should handle the work here. In any case, this isn't simply a bug fix so not happening in 3.18.
It seems that the libvirt's qemuDomainOpenGraphicsFD method should be modified in order to also support connecting over SSH. I'll try at first to implement the workaround that virt-viewer has and then maybe I'll come up with a more intuitive solution.
Hi! Having the same issue. The workaround is to open ssh tunnel: ssh -L 5901:127.0.0.1:5901 user@myserver.com -N -C4 Are there any news?
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-boxes/issues/63.