Its base64 with DIGEST-MD5 hashing with no salt.
If you don't beleave me just decode it through any base64 tool and you will
see the entire conversation
And if you still don't beleave me read the RFC that describes SASL its very
clearly explained and a relativly short read as RFCs go.
On Dec 20, 2012 10:16 AM, "David Sommerseth" <
[log in to unmask]> wrote:

> 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
>
>