Bug 737176

Hi, Michal Privoznik 

I want to verify this bug , but I do not know how to repruduce this bug or verify it , could you tell me how thanks very much .

Wenlong

To reproduce this bug do this:

you need a client (foo) with virsh installed and a server (bar) in a kerberized environment running the libvirt daemon and an ssh Server with gssapi authentication enabled: "GSSAPIAuthentication yes" in sshd_config. Additionally
set LogLevel to DEBUG in sshd_config and restart the sshd.

Obtain a ticket on the client:

baz@foo:~ kinit

Do an ssh Login on the server:

baz@foo:~ ssh -v bar

If everything is configured correctly you must not be asked for a password.

On the server you will find these lines in the auth.log:

Sep 21 12:11:49 bar sshd[15136]: Authorized to baz, krb5 principal  baz@REALM (krb5_kuserok)
Sep 21 12:11:49 bar sshd[15136]: Accepted gssapi-with-mic for baz from 1.2.3.4 port 36011 ssh2

The debugging output of your client should include these lines:

debug1: Next authentication method: gssapi-with-mic
debug1: Delegating credentials
debug1: Delegating credentials
debug1: Authentication succeeded (gssapi-with-mic).

Then try to access the libvirt daemon from an xterm with:

baz@foo:~ virsh qemu+ssh://bar/system

Passwordless Login will not succeed.

If you 'strace -f' the virsh process you should see lines like these:

baz@foo:~ grep -A 1 'gssapi' virsh.log
[pid 26698] write(2, "debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password\r\n", 92) = 92
[pid 26698] write(2, "debug1: Next authentication method: gssapi-keyex\r\n", 50) = 50
[pid 26698] write(2, "debug1: No valid Key exchange context\r\n", 39) = 39
[pid 26698] write(2, "debug1: Next authentication method: gssapi-with-mic\r\n", 53) = 53
[pid 26698] write(2, "debug1: Next authentication method: publickey\r\n", 47) = 47
--
[pid 26698] write(2, "debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password\r\n", 92) = 92
[pid 26698] write(2, "debug1: Offering public key: /home/baz/.ssh/id_dsa\r\n", 52) = 52
--
[pid 26698] write(2, "debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password\r\n", 92) = 92
[pid 26698] write(2, "debug1: Next authentication method: password\r\n", 46) = 46
--
[pid 26698] write(2, "debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password\r\n", 92) = 92
[pid 26698] write(2, "Permission denied, please try again.\r\n", 38) = 38
--
[pid 26698] write(2, "debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password\r\n", 92) = 92
[pid 26698] write(2, "Permission denied, please try again.\r\n", 38) = 38
--
[pid 26698] write(2, "debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password\r\n", 92) = 92
[pid 26698] write(2, "debug1: No more authentication methods to try.\r\n", 48) = 48
[pid 26698] write(2, "Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).\r\n", 70) = 70
[pid 26698] exit_group(255)             = ?

(In reply to comment #5)
> To reproduce this bug do this:
> 
> you need a client (foo) with virsh installed and a server (bar) in a kerberized
> environment running the libvirt daemon and an ssh Server with gssapi
> authentication enabled: "GSSAPIAuthentication yes" in sshd_config. Additionally
> set LogLevel to DEBUG in sshd_config and restart the sshd.
> 
> Obtain a ticket on the client:
> 
> baz@foo:~ kinit
> 
> Do an ssh Login on the server:
> 
> baz@foo:~ ssh -v bar
> 
> If everything is configured correctly you must not be asked for a password.
> 
> On the server you will find these lines in the auth.log:
> 
> Sep 21 12:11:49 bar sshd[15136]: Authorized to baz, krb5 principal  baz@REALM
> (krb5_kuserok)
> Sep 21 12:11:49 bar sshd[15136]: Accepted gssapi-with-mic for baz from 1.2.3.4
> port 36011 ssh2
> 
> The debugging output of your client should include these lines:
> 
> debug1: Next authentication method: gssapi-with-mic
> debug1: Delegating credentials
> debug1: Delegating credentials
> debug1: Authentication succeeded (gssapi-with-mic).
> 
> Then try to access the libvirt daemon from an xterm with:
> 
> baz@foo:~ virsh qemu+ssh://bar/system
> 
> Passwordless Login will not succeed.
> 
> If you 'strace -f' the virsh process you should see lines like these:
> 
> baz@foo:~ grep -A 1 'gssapi' virsh.log
> [pid 26698] write(2, "debug1: Authentications that can continue:
> publickey,gssapi-keyex,gssapi-with-mic,password\r\n", 92) = 92
> [pid 26698] write(2, "debug1: Next authentication method: gssapi-keyex\r\n",
> 50) = 50
> [pid 26698] write(2, "debug1: No valid Key exchange context\r\n", 39) = 39
> [pid 26698] write(2, "debug1: Next authentication method: gssapi-with-mic\r\n",
> 53) = 53
> [pid 26698] write(2, "debug1: Next authentication method: publickey\r\n", 47) =
> 47
> --
> [pid 26698] write(2, "debug1: Authentications that can continue:
> publickey,gssapi-keyex,gssapi-with-mic,password\r\n", 92) = 92
> [pid 26698] write(2, "debug1: Offering public key: /home/baz/.ssh/id_dsa\r\n",
> 52) = 52
> --
> [pid 26698] write(2, "debug1: Authentications that can continue:
> publickey,gssapi-keyex,gssapi-with-mic,password\r\n", 92) = 92
> [pid 26698] write(2, "debug1: Next authentication method: password\r\n", 46) =
> 46
> --
> [pid 26698] write(2, "debug1: Authentications that can continue:
> publickey,gssapi-keyex,gssapi-with-mic,password\r\n", 92) = 92
> [pid 26698] write(2, "Permission denied, please try again.\r\n", 38) = 38
> --
> [pid 26698] write(2, "debug1: Authentications that can continue:
> publickey,gssapi-keyex,gssapi-with-mic,password\r\n", 92) = 92
> [pid 26698] write(2, "Permission denied, please try again.\r\n", 38) = 38
> --
> [pid 26698] write(2, "debug1: Authentications that can continue:
> publickey,gssapi-keyex,gssapi-with-mic,password\r\n", 92) = 92
> [pid 26698] write(2, "debug1: No more authentication methods to try.\r\n", 48)
> = 48
> [pid 26698] write(2, "Permission denied
> (publickey,gssapi-keyex,gssapi-with-mic,password).\r\n", 70) = 70
> [pid 26698] exit_group(255)             = ?

Hi, Matthias Witte 

I have not kerberized envirnment , I just use a var to test it , 

test steps : 
1. export KRB5CCNAME=libvirt_krb_test  
2. export LIBVIRT_DEBUG=1
3. virsh -c qemu+ssh://10.66.5.12/system
...
virCommandRunAsync:2042 : About to run LC_ALL=C PATH=/usr/lib64/qt-3.3/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin HOME=/root USER=root LOGNAME=root KRB5CCNAME=libvirt_krb_test SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass DISPLAY=localhost:11.0 ssh 10.66.5.12 nc -U /var/run/libvirt/libvirt-sock
...

4. check 
the $KRB5CCNAME is correct . 

So I think the path works .
If you have the kerberos envirnment  ,could you help me to test it , thanks very much .

Hi Matthias,

Would you pls help to verify this bug per commet 6?

Thanks,
Rita

Verify this bug with libvirt-0.9.4-19.el6.x86_64 

1) setup a KDC server with libvirt on one host  

2) On the client  get the ticket for libvirt 

1. kinit  

check the ticket your get
2. klist   
Default principal: root.REDHAT.COM

Valid starting     Expires            Service principal
10/21/11 13:33:10  10/22/11 13:33:10  krbtgt/WHUANG.NAY.REDHAT.COM.REDHAT.COM
	renew until 10/21/11 13:33:10
10/21/11 13:33:16  10/22/11 13:33:10  host/whuang.nay.redhat.com.REDHAT.COM
	renew until 10/21/11 13:33:10

3. virsh -c qemu+ssh://$libvirt_ip/system  


It get connection without ssh passwd .

(In reply to comment #7)
> Hi Matthias,
> 
> Would you pls help to verify this bug per commet 6?
> 
> Thanks,
> Rita

I apologise for my late reply.

Here is my verification:

1. Disable passing KRB5CCNAME in src/rpc/virnetsocket.c and compile 0.9.6

2. Connect to VM Host using virsh

$ LIBVIRT_DEBUG=1 virsh -c qemu+ssh://foo/system
[...]
14:09:11.043: 12278: debug : virCommandRunAsync:2043 : About to run LC_ALL=C PATH=/sbin:/usr/sbin:/usr/local/sbin:/home/baz/bin:/usr/local/bin:/usr/bin:/bin HOME=/home/baz USER=baz LOGNAME=baz SSH_AUTH_SOCK=/tmp/keyring-B3FC1f/ssh DISPLAY=:0.0 ssh foo nc -U /var/run/libvirt/libvirt-sock
[...]

Result: I get a password prompt, KRB5CCNAME ist not passed in virCommandRunAsync

3. Reenable passing KRB5CCNAME and GSSAPI Login works

15:26:30.915: 7177: debug : virCommandRunAsync:2043 : About to run LC_ALL=C PATH=/sbin:/usr/sbin:/usr/local/sbin:/home/baz/bin:/usr/local/bin:/usr/bin:/bin HOME=/home/baz USER=baz LOGNAME=baz KRB5CCNAME=FILE:/tmp/krb5cc_1000_esIWWB SSH_AUTH_SOCK=/tmp/keyring-B3FC1f/ssh DISPLAY=:0.0 ssh foo nc -U /var/run/libvirt/libvirt-sock


All in all I think Wenlongs Test is correct.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1513.html