After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 751580 - Use ssh to connect to SPICE display of remote libvirt box
Use ssh to connect to SPICE display of remote libvirt box
Status: RESOLVED OBSOLETE
Product: gnome-boxes
Classification: Applications
Component: spice
3.14.x
Other Linux
: Normal normal
: --
Assigned To: GNOME Boxes maintainer(s)
GNOME Boxes maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2015-06-27 09:40 UTC by mnl
Modified: 2018-01-11 10:24 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description mnl 2015-06-27 09:40:16 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.
Comment 1 Zeeshan Ali 2015-06-27 14:05:12 UTC
(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.
Comment 2 mnl 2015-06-28 14:46:06 UTC
(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!
Comment 3 Zeeshan Ali 2015-06-29 12:00:21 UTC
(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.
Comment 4 mnl 2015-06-29 20:15:13 UTC
(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.
Comment 5 Zeeshan Ali 2015-10-12 16:44:47 UTC
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.
Comment 6 Visarion Alexandru 2016-08-22 16:09:06 UTC
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.
Comment 7 Michael Ledin 2017-08-13 10:22:54 UTC
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?
Comment 8 GNOME Infrastructure Team 2018-01-11 10:24:56 UTC
-- 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.