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
|