11:40 a.m.
My server and client are running Ubuntu Lucid, libvirt-bin
0.7.5-5ubuntu27, qemu-kvm-0.12.3+noroms-0ubuntu9 and I'm using
virt-viewer-0.0.3-6ubuntu7.xul19 or virt-manager-0.8.2-2ubuntu8 to
connect. I configured SASL2 to use GSSAPI for libvirt following the
instructions in the libvirt docs, created a keytab with
libvirt/my.fully.qualified.domain(a)MY-REALM.COM (has a dash fwiw) and
pointed SASL2 and libvirt at /etc/krb5.keytab (changing the location
of that doesn't seem to work for my version, but that's no biggie).
So I sit on my client and run this:
virsh -c qemu+tcp://my.fully.qualified.domain/system
And I get this message on the client:
error: authentication failed
error: failed to connect to the hypervisor
And this on the server logs:
16:37:35.278: error : remoteDispatchAuthSaslStart:3135 : sasl start
failed -1 (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS
failure. Minor code may provide more information (Key table entry not
found))
For fun, I ran kdestroy and tried again and got this:
error: Failed to start SASL negotiation: -1 (SASL(-1): generic
failure: GSSAPI Error: Unspecified GSS failure. Minor code may
provide more information (Credentials cache file '/tmp/krb5cc_1000'
not found))
error: failed to connect to the hypervisor
So at least the client seems to be presenting my ticket properly, but
the server is either looking for the wrong keytab entry or I can't
read very well.
-adam
9:37 a.m.
Adam Gray <adam(a)meebo-inc.com> schreibte:
libvirt/my.fully.qualified.domain(a)MY-REALM.COM (has a dash fwiw) and
pointed SASL2 and libvirt at /etc/krb5.keytab
What tells your KDC?
Have a look at
klist -t /etc/krb5.keytab
and look whether the principals match (e.g LIBVIRT/domain is not equal
libvirt/domain
Ralf
11:23 a.m.
Thanks Ralf, sadly things look OK to me. Did I typo something?? haha
forward and reverse DNS are correct for this host (petey), too. As far
as I can tell Kerberos stuff is set up as usual.
root@petey:~# klist -k /etc/krb5.keytab
Keytab name: WRFILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
2 libvirt/petey.mydomain.com(a)MYDOMAIN-INC.COM
2 libvirt/petey.mydomain.com(a)MYDOMAIN-INC.COM
2 libvirt/petey.mydomain.com(a)MYDOMAIN-INC.COM
2 libvirt/petey.mydomain.com(a)MYDOMAIN-INC.COM
-adam
On Wed, Jun 30, 2010 at 07:37, Ralf Hornik Mailings
<ralf(a)best.homeunix.org> wrote:
Adam Gray <adam(a)meebo-inc.com> schreibte:
> libvirt/my.fully.qualified.domain(a)MY-REALM.COM (has a dash fwiw) and
> pointed SASL2 and libvirt at /etc/krb5.keytab
What tells your KDC?
Have a look at
klist -t /etc/krb5.keytab
and look whether the principals match (e.g LIBVIRT/domain is not equal
libvirt/domain
Ralf
12:01 p.m.
Anno domini 2010 Adam Gray scripsit:
Hi!
Thanks Ralf, sadly things look OK to me. Did I typo something?? haha
forward and reverse DNS are correct for this host (petey), too. As far
as I can tell Kerberos stuff is set up as usual.
root@petey:~# klist -k /etc/krb5.keytab
Keytab name: WRFILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
2 libvirt/petey.mydomain.com(a)MYDOMAIN-INC.COM
2 libvirt/petey.mydomain.com(a)MYDOMAIN-INC.COM
2 libvirt/petey.mydomain.com(a)MYDOMAIN-INC.COM
2 libvirt/petey.mydomain.com(a)MYDOMAIN-INC.COM
Do you have a host/ principal, too?
How baout the access right? Can libvrtd read this file?
Does it? (strace -f -ff -eopen libvirtd --listen)
Ciao
Max
--
They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety. (Ben Franklin)
5:59 p.m.
On Wed, Jun 30, 2010 at 10:01, Maximilian Wilhelm <max(a)rfc2324.org> wrote:
Do you have a host/ principal, too?
How baout the access right? Can libvrtd read this file?
Does it? (strace -f -ff -eopen libvirtd --listen)
I added the host/ principal and still no dice :(
[pid 2184] open("/etc/libvirt/krb5.keytab", O_RDONLY) = 39
[pid 2184] fcntl(39, F_SETFD, FD_CLOEXEC) = 0
[pid 2184] fcntl(39, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET,
start=0, len=0}) = 0
[pid 2184] read(39, "\5\2\0\0\0T\0\2\0\r(this was totally my realm, I
dunno why everybody obscures it but Ima continue that
trend)\0\7libvirt\0\23petey.mydomain.com"..., 8192) = 626
-adam
12:13 p.m.
On Mon, Jun 28, 2010 at 09:40:49AM -0700, Adam Gray wrote:
My server and client are running Ubuntu Lucid, libvirt-bin
0.7.5-5ubuntu27, qemu-kvm-0.12.3+noroms-0ubuntu9 and I'm using
virt-viewer-0.0.3-6ubuntu7.xul19 or virt-manager-0.8.2-2ubuntu8 to
connect. I configured SASL2 to use GSSAPI for libvirt following the
instructions in the libvirt docs, created a keytab with
libvirt/my.fully.qualified.domain(a)MY-REALM.COM (has a dash fwiw) and
pointed SASL2 and libvirt at /etc/krb5.keytab (changing the location
of that doesn't seem to work for my version, but that's no biggie).
If changing the location in /etc/sasl2/libvirt.conf doesn't
work then you likely have a broken kerberos/sasl library.
This works in latest versions, but for broken systems you
can workaround it by setting KRB5_KTNAME=/etc/libvirt/krb5.tab
as an env variable when starting libvirtd.
So I sit on my client and run this:
virsh -c qemu+tcp://my.fully.qualified.domain/system
And I get this message on the client:
error: authentication failed
error: failed to connect to the hypervisor
And this on the server logs:
16:37:35.278: error : remoteDispatchAuthSaslStart:3135 : sasl start
failed -1 (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS
failure. Minor code may provide more information (Key table entry not
found))
Do you have your server hostname configured to exactly match
my.fully.qualified.domain (as per hostname -f command), and
is that hostname present in the DNS records, both forward and
reverse lookups. Using /etc/hosts is not sufficient for kerberos
to work IIRC.
For fun, I ran kdestroy and tried again and got this:
error: Failed to start SASL negotiation: -1 (SASL(-1): generic
failure: GSSAPI Error: Unspecified GSS failure. Minor code may
provide more information (Credentials cache file '/tmp/krb5cc_1000'
not found))
error: failed to connect to the hypervisor
That just says the client doesn't have a ticket so not
really of interest since you just kdestroy'd the ticket :-)
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
6:10 p.m.
On Wed, Jun 30, 2010 at 10:13, Daniel P. Berrange <berrange(a)redhat.com> wrote:
If changing the location in /etc/sasl2/libvirt.conf doesn't
work then you likely have a broken kerberos/sasl library.
This works in latest versions, but for broken systems you
can workaround it by setting KRB5_KTNAME=/etc/libvirt/krb5.tab
as an env variable when starting libvirtd.
Looks like upstart doesn't work quite like I thought. Running this
from the command line shows it changed the file path:
KRB5_KTNAME=/etc/libvirt/krb5.keytab strace -f -ff -eopen libvirtd
--listen 2>&1 |grep keytab
[pid 2412] open("/etc/libvirt/krb5.keytab", O_RDONLY) = 39
Do you have your server hostname configured to exactly match
my.fully.qualified.domain (as per hostname -f command), and
is that hostname present in the DNS records, both forward and
reverse lookups. Using /etc/hosts is not sufficient for kerberos
to work IIRC.
Yeah, I ran into that one way too many times to forget :(
hostname -f gives fqdn, dig on that fqdn gives the right IP, dig -x on
that IP gives a PTR to the same fqdn.
That just says the client doesn't have a ticket so not
really of interest since you just kdestroy'd the ticket :-)
2:01 a.m.
I'll try again from latest source tomorrow (or sometime soon). If that
doesn't change anything, I'll repost. Thanks for your help!
-adam
On Wed, Jun 30, 2010 at 16:10, Adam Gray <adam(a)meebo-inc.com> wrote:
On Wed, Jun 30, 2010 at 10:13, Daniel P. Berrange
<berrange(a)redhat.com> wrote:
>
> If changing the location in /etc/sasl2/libvirt.conf doesn't
> work then you likely have a broken kerberos/sasl library.
> This works in latest versions, but for broken systems you
> can workaround it by setting KRB5_KTNAME=/etc/libvirt/krb5.tab
> as an env variable when starting libvirtd.
Looks like upstart doesn't work quite like I thought. Running this
from the command line shows it changed the file path:
KRB5_KTNAME=/etc/libvirt/krb5.keytab strace -f -ff -eopen libvirtd
--listen 2>&1 |grep keytab
[pid 2412] open("/etc/libvirt/krb5.keytab", O_RDONLY) = 39
>
> Do you have your server hostname configured to exactly match
> my.fully.qualified.domain (as per hostname -f command), and
> is that hostname present in the DNS records, both forward and
> reverse lookups. Using /etc/hosts is not sufficient for kerberos
> to work IIRC.
Yeah, I ran into that one way too many times to forget :(
hostname -f gives fqdn, dig on that fqdn gives the right IP, dig -x on
that IP gives a PTR to the same fqdn.
>
> That just says the client doesn't have a ticket so not
> really of interest since you just kdestroy'd the ticket :-)
5139
days inactive
5142
days old
7 comments
4 participants
participants (4)
-
Adam Gray -
Daniel P. Berrange -
Maximilian Wilhelm -
Ralf Hornik Mailings