Hello everybody, We are trying to use libvirt with qemu over ssh and our goal is to have authentication done by certificates. Therefore I created a keypair on the client and send the public key to the server. Std. SSH connections work without an password prompt as expected (ssh <ip> -l user), but if I try "sudo virsh -c qemu+ssh://user@<ip>/system" it prompts for a password (Beside that password prompt it works as expected). Is there anything else I have to do beside registering the public key at the server?

On Mon, Jun 08, 2009 at 11:35:00AM +0200, Christian Weyermann wrote: > Hello everybody, > > I encountered the following problem. I want my users to only be able to > connect to their own virtual machines via VNC. Is there any way to do so? > The VNC authentication setup is currently being done per-host, so there is no way to define ACLs per-(user,vm) tuple as you describe. Daniel

On Mon, Jun 08, 2009 at 02:00:58PM +0200, Christian Weyermann wrote: > Daniel P. Berrange schrieb: > >> On Mon, Jun 08, 2009 at 11:35:00AM +0200, Christian Weyermann wrote: >> >> >>> Hello everybody, >>> >>> I encountered the following problem. I want my users to only be able to >>> connect to their own virtual machines via VNC. Is there any way to do so? >>> >>> >> The VNC authentication setup is currently being done per-host, so there >> is no way to define ACLs per-(user,vm) tuple as you describe. >> >> > Do you think, there might be a chance reaching this goal anyway, using > VNC-Kerberos Auth via SASL, as the virt-viewer supports SASL? > No, afraid that won't help you. The key issue is that there is no way to specify authorization data on a per-VM basis. So if you authenticate successfully you have access. We need to add a way to check the authenticated username against an access control list of some form.

On Mon, Jun 08, 2009 at 11:35:00AM +0200, Christian Weyermann wrote: > Hello everybody, > > I encountered the following problem. I want my users to only be able to > connect to their own virtual machines via VNC. Is there any way to do so? The VNC authentication setup is currently being done per-host, so there is no way to define ACLs per-(user,vm) tuple as you describe.

On Thu, Jun 11, 2009 at 04:05:39AM -0400, Jim Paris wrote: > Daniel P. Berrange wrote: > >> On Mon, Jun 08, 2009 at 11:35:00AM +0200, Christian Weyermann wrote: >> >>> Hello everybody, >>> >>> I encountered the following problem. I want my users to only be able to >>> connect to their own virtual machines via VNC. Is there any way to do so? >>> >> The VNC authentication setup is currently being done per-host, so there >> is no way to define ACLs per-(user,vm) tuple as you describe. >> > What about the VNC password? > That's per-VM, isn't it? > That is true by I don't really consider VNC password to be useful. It is utterly insecure. If you want to have plain passwords, then its better to use the new SASL authentication method, with its Digest-MD5 plugin. That is still not top-grade security, but it is better then VNC password and allows configuration of arbitrary Username+pasword pairs.. At which point we just need ACLs against the usernames. SASL also provide Kerberos auth, where we can do an ACL against the Kerberos principle name. And VeNCrypt provides TLS+x509 certificates which you can either layer SASL over again, or require client x509 certs and do an ACL against the client CNAME

On Thu, Jun 11, 2009 at 11:10:47AM +0200, Christian Weyermann wrote: > Daniel P. Berrange schrieb: > >> On Thu, Jun 11, 2009 at 04:05:39AM -0400, Jim Paris wrote: >> >> >>> Daniel P. Berrange wrote: >>> >>> >>>> On Mon, Jun 08, 2009 at 11:35:00AM +0200, Christian Weyermann wrote: >>>> >>>> >>>>> Hello everybody, >>>>> >>>>> I encountered the following problem. I want my users to only be able to >>>>> connect to their own virtual machines via VNC. Is there any way to do so? >>>>> >>>>> >>>> The VNC authentication setup is currently being done per-host, so there >>>> is no way to define ACLs per-(user,vm) tuple as you describe. >>>> >>>> >>> What about the VNC password? >>> That's per-VM, isn't it? >>> >>> >> That is true by I don't really consider VNC password to be useful. It is >> utterly insecure. If you want to have plain passwords, then its better to >> use the new SASL authentication method, with its Digest-MD5 plugin. That >> is still not top-grade security, but it is better then VNC password and >> allows configuration of arbitrary Username+pasword pairs.. At which point >> we just need ACLs against the usernames. SASL also provide Kerberos auth, >> where we can do an ACL against the Kerberos principle name. And VeNCrypt >> provides TLS+x509 certificates which you can either layer SASL over again, >> or require client x509 certs and do an ACL against the client CNAME >> > Ok, so let me sumarize: It is possible to define username+password pairs > via SASL. SASL can also sync with Kerberos. So the only problem left is, > that there is no way to assign a specific username to a VM. So, what we > need is a plugin, where we have an username and a virtual machine as > input and we need to refuse the connection, if this pair is not valid. > The VNC Server is part of libvirt, so the perfect method to add this > functionallity would be the VNC Servers authenticate or start method. > > However, a Windows user is still not able to connect as there is no > windows vnc client capable of doing SASL. > GTK-VNC builds on Windows, and so does libvirt. So the intent was that we'd be able to have virt-viewer working on Windows using those two. Oh, when I say Windows, i mean Mingw32

On Thu, Jun 11, 2009 at 11:45:43AM +0200, Christian Weyermann wrote: > Daniel P. Berrange schrieb: > >> On Thu, Jun 11, 2009 at 11:10:47AM +0200, Christian Weyermann wrote: >> >> >>> Daniel P. Berrange schrieb: >>> >>> >>>> On Thu, Jun 11, 2009 at 04:05:39AM -0400, Jim Paris wrote: >>>> >>>> >>>> >>>>> Daniel P. Berrange wrote: >>>>> >>>>> >>>>> >>>>>> On Mon, Jun 08, 2009 at 11:35:00AM +0200, Christian Weyermann wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Hello everybody, >>>>>>> >>>>>>> I encountered the following problem. I want my users to only be able to >>>>>>> connect to their own virtual machines via VNC. Is there any way to do so? >>>>>>> >>>>>>> >>>>>>> >>>>>> The VNC authentication setup is currently being done per-host, so there >>>>>> is no way to define ACLs per-(user,vm) tuple as you describe. >>>>>> >>>>>> >>>>>> >>>>> What about the VNC password? >>>>> That's per-VM, isn't it? >>>>> >>>>> >>>>> >>>> That is true by I don't really consider VNC password to be useful. It is >>>> utterly insecure. If you want to have plain passwords, then its better to >>>> use the new SASL authentication method, with its Digest-MD5 plugin. That >>>> is still not top-grade security, but it is better then VNC password and >>>> allows configuration of arbitrary Username+pasword pairs.. At which point >>>> we just need ACLs against the usernames. SASL also provide Kerberos auth, >>>> where we can do an ACL against the Kerberos principle name. And VeNCrypt >>>> provides TLS+x509 certificates which you can either layer SASL over again, >>>> or require client x509 certs and do an ACL against the client CNAME >>>> >>>> >>> Ok, so let me sumarize: It is possible to define username+password pairs >>> via SASL. SASL can also sync with Kerberos. So the only problem left is, >>> that there is no way to assign a specific username to a VM. So, what we >>> need is a plugin, where we have an username and a virtual machine as >>> input and we need to refuse the connection, if this pair is not valid. >>> The VNC Server is part of libvirt, so the perfect method to add this >>> functionallity would be the VNC Servers authenticate or start method. >>> >>> However, a Windows user is still not able to connect as there is no >>> windows vnc client capable of doing SASL. >>> >>> >> GTK-VNC builds on Windows, and so does libvirt. So the intent was that >> we'd be able to have virt-viewer working on Windows using those two. >> Oh, when I say Windows, i mean Mingw32 >> >> > Ok, so the other part of the post is correct? So what do you think about > the effort for implementing this feature? > Well I've had the demo program from GTK-VNC working sucessfully under Wine, and had virsh successfully working under Wine. So I see no reason why we virt-viewer should be troublesome to get working. I hope it'll just be a lot of silly small bugfixes/portability fixes, rather than any large fundamental problem.

Daniel P. Berrange wrote: > On Mon, Jun 08, 2009 at 11:35:00AM +0200, Christian Weyermann wrote: > > Hello everybody, > > > > I encountered the following problem. I want my users to only be able to > > connect to their own virtual machines via VNC. Is there any way to do so? > > The VNC authentication setup is currently being done per-host, so there > is no way to define ACLs per-(user,vm) tuple as you describe. What about the VNC password? That's per-VM, isn't it?