On Thu, Feb 26, 2009 at 10:47:37PM +0100, Michael Kress wrote:
My questions:
1) Isn't there a more comfortable end user compatible method to connect
to the beast?
(Because with this method, users obviously are urged to have Linux on
the client side. Or would the purchase of real vnc enterprise edition
would be the solution there?)
This is an ongoing area of development. The VeNCrypt extension
provides two core capabilities
- Data encryption of the session (only server & CA certs required)
- Crude authentication (if using client clients too)
For Fedora 11, I have been working on integrating SASL as an
additional authenication mechanism. This provides a pluggable
system for auth methods, which includes such things as
- Username/password auth against PAM, LDAP, SQL database
- One time passwords
- GSSAPI Kerberos single sign on
https://fedoraproject.org/wiki/Features/VirtVNCAuth
Most of the auth methods require that you already have a secure data
channel, so you'd have to layer them over the VeNCrypt extension. The
last GSSAPI though is particularly interesting, because GSSAPI also
provides data encryption, avoiding any need for VeNCRypt. So you
will have a wide variety of options for accessing VNC
- VNC on localhost, access remotely over SSH, authenticate VNC
with any SASL auth method
- VNC on public IP addr, using TLS for encryption, and any SASL
auth method
- VNC on public IP addr, using GSSAPI SASL auth method for
auth and encryption
2) I simulated an interested user owning a certificate and walked
through the different screens of the host (before, I created a few). I
could easily access them by just chosing to connect to "localhost:0"
"localhost:1" ... (given the requirement to have an ssh tunnel which the
client machine easily can build)
Is it possible to let him only view what he's supposed to? How?
In libvirt we do not yet any a way to setup per-VM access control
lists. This is the next item on the TODO list....
3) Is there a way to stick one certificate to one virtual machine?
e.g. stick client-cert-user001.pem to /etc/libvirt-bin/qemu/user001-vm01.xml
(trying to find a solution to question 2) with this question).
You wouldn't really want todo this. All VMs on a host should typically
use the same certificate. To get per-user access control, we need
libvirt to get some kind of per-VM allow/deny list.
You can see more about what i'm experimenting with here
http://lists.gnu.org/archive/html/qemu-devel/2009-02/msg01426.html
Daniel
--
|: Red Hat, Engineering, London -o-
http://people.redhat.com/berrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org -o-
http://ovirt.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|