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="<Bass64_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="<Bass64_encoded_data>", cnonce="<Bass64_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