On 19/12/12 23:45, Paul Robert Marino wrote:
> this statement
> " (I double checked the network traffic, and even though not using SSL
> the password is not transferred over the network in clear-text)"
> is wrong
> It is clear text that has been base64 encoded unless you are using
> gssapi with kerberos 5 or some other encrypted authentication
> mechanism. you can mitigate this slightly by using the digest-md5 auth
> but all you are doing then is sending the hash of the password in
> clear text which isn't that much better

I might be wrong, but I am quite confident that the data I see is
encrypted.  I've looked at the data via wireshark, and even though it
looks like base64, it doesn't render my password.

And looking further in the comments in /etc/libvirt/libvirtd.conf, there
is this statement:

   # Using the TCP socket requires SASL authentication by default. Only
   # SASL mechanisms which support data encryption are allowed. This is
   # DIGEST_MD5 and GSSAPI (Kerberos5)

And what I see, looks pretty much like digest-md5 with RC4 encryption.
My libvirtd daemon tells this to my client:

   DIGEST-MD5 Dnonce="<BASE64_ecncoded_data>",
   realm="<DOMAIN>",qop="auth-conf",
   cipher="rc4-56,rc4,3des",
   maxbuf=65536,charset=utf-8,algorithm=md5-sess

The client responds with this:

   DIGEST-MD5 Eusername="<USERNAME>",realm="<DOMAIN>",
   nonce="<BASE64_encoded_data>",
   cnonce="<BASE64_encoded_data_2>",
   nc=00000001,qop=auth-conf,cipher=rc4,maxbuf=65536,
   digest-uri="libvirt/1035110",
   response=1f4023d0417acb495ed187255ba80fcf

And then the server responds with:

   rspauth=40922952d194910a08f3654b28d5485f

After this response, it comes a data flow which looks more like normal
data traffic.

As far as I can interpret this, the data from the client is encrypted,
using some shared data for a key exchange.  But I haven't dug into the
source code to verify this yet.

If I'm wrong, then I need to learn more about the DIGEST-MD5 protocol.


kind regards,

David Sommerseth


> On Wed, Dec 19, 2012 at 6:14 AM, David Sommerseth
> <[log in to unmask]> wrote:
>> On 19/12/12 04:38, Nico Kadel-Garcia wrote:
>>> I'd love to be able to use sudo with virt-manager, but it simply
>>> fails. It does work on Ubuntu, and I'd like to be able to use sudo for
>>> all access to my KVM servers, rather than direct root login.
>>>
>>> Is anyone using sudo successfully with virt-manager on SL 6.3? Other X
>>> applications work just fine.
>>
>> I do something similar to this, but slightly differently.  I'm running
>> virt-manager as my local user, but connecting to the TCP port,
>> authenticating using the SASL feature.  (I double checked the network
>> traffic, and even though not using SSL the password is not transferred
>> over the network in clear-text)
>>
>> * In /etc/libvirt/libvirtd.conf I set the following parameters:
>>
>>    listen_tls=0
>>    listen_tcp=1
>>    listen_address=x.x.x.x # optional
>>    auth_tcp = "sasl"
>>
>>
>> * Create the SASL database with the username/password I want to use
>>
>>   Look up the "sasldb_path" in /etc/sasl2/libvirt.conf.  In my setup
>>   it was set to /etc/libvirt/passwd.db.  Then do:
>>
>>   [root@host ~]# saslpasswd2 -f /etc/libvirt/passwd.db <USERNAME>
>>
>>   The username can be completely virtual if you want.  saslpasswd2 will
>>   ask for the wanted password.  This username/password will only be
>>   used for libvirt.
>>
>>   You can check the user database like this:
>>
>>   [root@host ~]# sasldblistusers2 -f /etc/libvirt/passwd.db
>>
>>
>> * Make libvirtd listen to TCP sockets
>>   Edit /etc/sysconfig/libvirtd so that LIBVIRTD_ARGS have "--listen" set
>>
>>   F.ex:
>>   LIBVIRTD_ARGS="--listen"
>>
>>
>> * Restart libvirtd
>>
>>   [root@host ~]# service libvirtd restart
>>
>> If you want to connect to another IP than localhost, you also need to
>> open up your firewall as well.  But at this point, it should be possible
>> to connect to libvirt over the network:
>>
>>    [user@host ~]$ virsh -c qemu+tcp://localhost/system
>>    [user@host ~]$ virt-manager -c qemu+tcp://localhost/system
>>
>>
>> I'm primarily using this approach to manage a couple of KVM hosts over a
>> VPN connection, running virsh and virt-manager locally, connecting to
>> the IP which is accessible over the VPN.  Works pretty well, but I had
>> to do some changes in the guest configs so that SPICE or VNC consoles
>> also listened to an IP address available over the VPN.  Changing these
>> parameters requires cold-booting the virtual guests.
>>
>> I have tried to use SSL/TLS mode as well, but when managing more
>> independent libvirt based servers, it gets quite annoying with how the
>> client certificates needs to be configured.  (Granted, it's a long time
>> ago I tried it, so it might have changed)  But I figured, as long as I
>> use SASL and does this over VPN connections with strict firewalls, the
>> setup is safe enough in my use cases.
>>
>>
>> kind regards,
>>
>> David Sommerseth