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

That being said you aren't the first person to be fooled back around
the turn of the century (I love that I get to use that line for the
time period around 2001) there were a lot of "LDAP Experts" that made
the same claim because they never read the RFC for sasl and didn't
recognize base64 when they saw it. There was even one who claimed on
his website that sasl was doing its own ssl encryption till I emailed
him his password from the example on his web site lol.




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