Re: Solaris 9, stock sshd, pam_krb5, MIT 1.4.3 KDC
On Thu, May 18, 2006 at 04:12:00PM -0700, Henry B. Hotz wrote: > On May 16, 2006, at 2:32 PM, [EMAIL PROTECTED] wrote: > On Heimdal you would normally create the entry and then delete the > unwanted encryption key types (if necessary). I think the mechanism > is different for Sun or MIT servers: you specify the enc type you > want as part of the add? Correct. > I wouldn't prohibit des3 across the board > just because you have some Sun machines that haven't been upgraded to > Solaris 10. Me either. If you move your KDC to Solaris 10 you'll get the benefit of that kadmind heuristic and never (mostly) notice this problem. (The heuristic, IIRC, is that the randkey operation assumes only 1DES is desired -- kadmin/ktadd on S10 always uses the randkey_3 operation, while on S8/9 it always uses randkey.) Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Solaris 9, stock sshd, pam_krb5, MIT 1.4.3 KDC
On May 16, 2006, at 2:32 PM, [EMAIL PROTECTED] wrote: > Message: 9 > Date: Tue, 16 May 2006 17:32:45 -0400 > From: Jeff Blaine <[EMAIL PROTECTED]> > Subject: Re: Solaris 9, stock sshd, pam_krb5, MIT 1.4.3 KDC > To: kerberos@mit.edu > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Nicolas Williams wrote: >> On Tue, May 16, 2006 at 04:01:11PM -0400, Jeff Blaine wrote: >>> I'm confused, then, Nicolas. >>> >>> As I read the output, there are 2 keys stored >>> for these principals: >>> >>>1 using Triple DES cbc mode with HMAC/sha1 >>> >>>1 using DES cbc mode with CRC-32 >>> >>> And the first matching enctype is supposed to be used, >>> which would be des-cbc-crc (and des3-hmac-sha1 would >>> not, as it is not common to the client and server. >> >> What does kadmin -q "getprinc host/[EMAIL PROTECTED]" say? >> >> I bet the des3-hmac-sha1 key comes before the des-cbc-crc key. > > Yes, it does. I think there is an FAQ on this: best to make sure the service principals only have key types that are understood by the service's Kerb libraries. On Heimdal you would normally create the entry and then delete the unwanted encryption key types (if necessary). I think the mechanism is different for Sun or MIT servers: you specify the enc type you want as part of the add? I wouldn't prohibit des3 across the board just because you have some Sun machines that haven't been upgraded to Solaris 10. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Solaris 9, stock sshd, pam_krb5, MIT 1.4.3 KDC
On Tue, May 16, 2006 at 06:40:29PM -0400, Jeff Blaine wrote: > Yes, MIT k5 1.4.3 > > The only Solaris piece I ever expect to use is pam_krb5.so And secure NFS? (kgssapi/kmech_krb5, gssd/mech_krb5) > I've yet to touch/test Linux + K5, but it will be promptly > after I find most of the hiccups with Solaris + MIT for > now. Then it's on to Cyrus IMAP integration and other > fun stuff. Would you consider running a Solaris 10 KDC? > Maybe I'm just sore about it, but perhaps something should > be mentioned about this in the docs? Which part? That Solaris 9 only supports the Kerberos V 1DES enctypes should be clear from the krb5.conf man page. As for the Solaris 10 kadmind heuristic I described, I'm not sure where that's documented. I'll find out. > I can't really wrap > my head around how this bit me and there wasn't a pile of > of mailing list archive chatter by other people being > bitten (when I searched before posting...). That is, I > don't see that I am doing anything rare here. You're mixing two Kerberos V implementations on the same host. This is not so rare for Solaris 8 and 9 systems, actually, but when one does this one should be careful about possibly disjoint feature sets of the two implementations. >I'm trying > to use MIT K5 as a KDC in a homogenous environment. Out > of the box, I got bit the first time I touched anything > that didn't come from MIT. If nobody finds that bad, > so be it -- I'm not going to drag it out further. See above. > And now, I cannot get kadmin.local to NOT make 3DES > keys. I have tried: The MIT and Solaris 10 kadmin/kadmin.local have a -e option to ktadd that you should use. The enctype names include a salt type (for your purposes always ":normal"). That the salt type is not optional is just awful, IMO. > No dice. It appears to be blindly ignoring everything > EXCEPT '-e des-crc-cbc:normal' as part of ktadd (which I > should not have to do when set up this way). > > Here's a bug, too :) > >kadmin.local: ktadd -e des-cbc-crc host/noodle.foo.com >ktadd: Invalid argument while parsing keysalts de > > ^^ > > This is about the time I start getting really worried. As has been pointed out you didn't include the ":normal" (though you included it in your e-mail). > Worried that either I am *really* stupid, or... wow :( No, the interface isn't very friendly. > > Perhaps we need to get this behaviour into MIT krb5, since you're using > > it alongside Solaris' krb5 support. I assume you're using MIT's KDC > > software. > > Above - and I think that's a great idea. I'll file a report in the MIT krb5 RT. Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Solaris 9, stock sshd, pam_krb5, MIT 1.4.3 KDC
On May 17, 2006, at 16:42, Jeff Blaine wrote: >> and the KDC would happily start up without reading it. > > And this is... okay with everyone? *scratches head* For the 1.5 release, we're changing direction a bit: The KDC programs (krb5kdc, kadmind, kadmin.local but not kadmin, etc) will add kdc.conf (either compiled-in path or env var) to the list of config files used, and combine the data from all of them that are found. So all the config information can be put into krb5.conf, if desired, or kdc.conf can override krb5.conf settings that currently it can't influence. (We've been talking about doing this for a while, but the big impetus now has to do with the interface chosen for the pluggable database back end support donated by Novell.) Ken Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Solaris 9, stock sshd, pam_krb5, MIT 1.4.3 KDC
> Silly question time: exactly where do you think your kdc.conf
> is? I found a bunch of times that people would mistakenly
> place it in /etc, ... You could use a system call tracer to
> make sure it's reading the right file.
bash-2.05# truss -o /tmp/out kadmin.local -q "getprinc cvs/noodle.host.com"
bash-2.05# grep kdc.conf /tmp/out
stat("/export/home/krb5/var/krb5kdc/kdc.conf", 0xFFBFF250) Err#2 ENOENT
bash-2.05#
bash-2.05# truss -o /tmp/out -f /export/home/krb5/sbin/krb5kdc -n
^C
bash-2.05# grep kdc.conf /tmp/out
553:stat("/export/home/krb5/var/krb5kdc/kdc.conf", 0xFFBFF4A8) Err#2
ENOENT
553:stat("/export/home/krb5/var/krb5kdc/kdc.conf", 0xFFBFF370) Err#2
ENOENT
bash-2.05#
> and the KDC would happily start up without reading it.
And this is... okay with everyone? *scratches head*
> You forgot to append the salt here (the ":normal" part).
Yes.
> Perhaps that should be a default ... but it did tell you
> that the error was in parsing the keysalt (I dunno why
> it picks the first few letters of the enctype
> in that error message, but that's what it's doing).
The bug I was reporting was the truncated enctype error.
Well, at least my kdc.conf mystery is solved. Thanks, Ken.
*still worriedly scratching head*
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Solaris 9, stock sshd, pam_krb5, MIT 1.4.3 KDC
>And now, I cannot get kadmin.local to NOT make 3DES >keys. I have tried: > >1. kdc_supported_enctypes = des-cbc-crc:normal >2. supported_enctypes = des-cbc-crc:normal >3. Both 1 and 2 at the same time >4. 1, 2, and 3 after restarting everything >5. Checked and rechecked that I am editing the > only kdc.conf on my entire box (find ...) Silly question time: exactly where do you think your kdc.conf is? I found a bunch of times that people would mistakenly place it in /etc, and the KDC would happily start up without reading it. You could use a system call tracer to make sure it's reading the right file. > kadmin.local: ktadd -e des-cbc-crc host/noodle.foo.com > ktadd: Invalid argument while parsing keysalts de > > ^^ You forgot to append the salt here (the ":normal" part). Perhaps that should be a default ... but it did tell you that the error was in parsing the keysalt (I dunno why it picks the first few letters of the enctype in that error message, but that's what it's doing). --Ken Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Solaris 9, stock sshd, pam_krb5, MIT 1.4.3 KDC
On Tuesday, May 16, 2006 06:40:29 PM -0400 Jeff Blaine <[EMAIL PROTECTED]> wrote: > Yes, MIT k5 1.4.3 > > The only Solaris piece I ever expect to use is pam_krb5.so > > I've yet to touch/test Linux + K5, but it will be promptly > after I find most of the hiccups with Solaris + MIT for > now. Then it's on to Cyrus IMAP integration and other > fun stuff. > > Maybe I'm just sore about it, but perhaps something should > be mentioned about this in the docs? I can't really wrap > my head around how this bit me and there wasn't a pile of > of mailing list archive chatter by other people being > bitten (when I searched before posting...). That is, I > don't see that I am doing anything rare here. I'm trying > to use MIT K5 as a KDC in a homogenous environment. Out > of the box, I got bit the first time I touched anything > that didn't come from MIT. If nobody finds that bad, > so be it -- I'm not going to drag it out further. The problem is not that you touched something that didn't come from MIT. The problem is that you have software that is old, and doesn't support as many enctypes as newer software. When you added an entry for that service to the Kerberos database, you gave it keys for enctypes the server software doesn't actually support. Neither kadmin nor the KDC have any way of knowing this, other than you telling it. An easy approach that solves this problem most of the time is to make sure that the tools you use to register a service in the Kerberos database are from the same software distribution as the service itself. That way, they'll support the same set of enctypes and no one will get confused. Unfortunately, this doesn't work all the time, for several reasons. Nico alluded to an issue with Solaris 9's kadmin which requires that the KDC go to some effort to recognize that particular client and do the right thing. More generally, the kadmin protocol is not standardized, so there is no guarantee that any client will work if it didn't come from your KDC vendor. That's something I hope to see change, eventually, but that depends a lot on the availability and willingness of people to do the work to define a standard admin protocol. In the meantime, recent versions of Solaris and MIT kadmin interoperate, but only because those parties have gone to some effort to make it so. And of course, life gets fun when you have multiple software versions that will share a service key For example, if you plan to use Sun's pam_krb5 and also run some other telnetd or sshd on the same machine, you need to make sure the host principal only has keys of types supported by all of those services. To some extent, this becomes a matter of understanding exactly what's going on, and going to some effort to get it right. It'd be nice for it to all Just Work(tm), but in this case it turns out to be tricky to get all the edge cases right. -- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA > Here's a bug, too :) > >kadmin.local: ktadd -e des-cbc-crc host/noodle.foo.com >ktadd: Invalid argument while parsing keysalts de Well, I can't speak for MIT, but I seem to recall that at least at one time, the error reporting in this case had some problems. -- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Solaris 9, stock sshd, pam_krb5, MIT 1.4.3 KDC
>> That seems a real shame -- "Use 1DES in any homogenous >> environment or you may really hurt yourself." It's not actually _that_ bad, and you don't want to change your supported_enctypes line. The only _crucial_ thing is that you cannot have service keys on a system that it cannot handle. The clients don't matter ... only the application server (e.g., ktelnetd, sshd, whatever) matters. We have a relatively complicated realm when it comes to enctypes ... some systems, by regulation, cannot have a single-DES enctype on them; other systems, for backwards compatibility with some damn version of Java (don't get me started), can _only_ have a single-DES enctype. It all works fine, and our supported_enctypes line has a bunch of enctypes in it. The only thing that is important is that the single-DES only machines only have single-DES enctypes on them (well, the no-single-DES machines don't have single-DES keys, obviously). >> Sadly, it also doesn't appear one can remove just *one* enctype >> instance of a key (the 3DES one in my case). Yeah, I sure wish MIT could do this. Oh, well. It's only a few seconds to rekey it, though, and it's easy enough to automate it. --Ken Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Solaris 9, stock sshd, pam_krb5, MIT 1.4.3 KDC
Yes, MIT k5 1.4.3 The only Solaris piece I ever expect to use is pam_krb5.so I've yet to touch/test Linux + K5, but it will be promptly after I find most of the hiccups with Solaris + MIT for now. Then it's on to Cyrus IMAP integration and other fun stuff. Maybe I'm just sore about it, but perhaps something should be mentioned about this in the docs? I can't really wrap my head around how this bit me and there wasn't a pile of of mailing list archive chatter by other people being bitten (when I searched before posting...). That is, I don't see that I am doing anything rare here. I'm trying to use MIT K5 as a KDC in a homogenous environment. Out of the box, I got bit the first time I touched anything that didn't come from MIT. If nobody finds that bad, so be it -- I'm not going to drag it out further. And now, I cannot get kadmin.local to NOT make 3DES keys. I have tried: 1. kdc_supported_enctypes = des-cbc-crc:normal 2. supported_enctypes = des-cbc-crc:normal 3. Both 1 and 2 at the same time 4. 1, 2, and 3 after restarting everything 5. Checked and rechecked that I am editing the only kdc.conf on my entire box (find ...) 6. Checked and rechecked that I am using my MIT distribution in /export/home/krb5 for all commands 7. kdc_supported_enctypes = des-cbc-crc 8. supported_enctypes = des-cbc-crc 9. 7 and 8 at the same time And even throwing the krb5.conf key-related options into /etc/krb5.conf No dice. It appears to be blindly ignoring everything EXCEPT '-e des-crc-cbc:normal' as part of ktadd (which I should not have to do when set up this way). Here's a bug, too :) kadmin.local: ktadd -e des-cbc-crc host/noodle.foo.com ktadd: Invalid argument while parsing keysalts de ^^ This is about the time I start getting really worried. Worried that either I am *really* stupid, or... wow :( > Perhaps we need to get this behaviour into MIT krb5, since you're using > it alongside Solaris' krb5 support. I assume you're using MIT's KDC > software. Above - and I think that's a great idea. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Solaris 9, stock sshd, pam_krb5, MIT 1.4.3 KDC
On Tue, May 16, 2006 at 04:57:29PM -0500, Nicolas Williams wrote: > Hmmm, OK, this is complicated, and I'd rather not go into all these > details, but: ^ right now Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Solaris 9, stock sshd, pam_krb5, MIT 1.4.3 KDC
On Tue, May 16, 2006 at 05:32:45PM -0400, Jeff Blaine wrote: > Nicolas Williams wrote: > > What does kadmin -q "getprinc host/[EMAIL PROTECTED]" say? > > > > I bet the des3-hmac-sha1 key comes before the des-cbc-crc key. > > Yes, it does. Well, that's it then. Switch to des-cbc-crc. Yes, the krb5 team at Sun greatly upgraded enctype support in Solaris 10. No, this can't be easily backported to Solaris 9. > > That means that when the stock pam_krb5/mech_krb5 do a TGS-REQ to get a > > service ticket [for the PAM_USER with host/[EMAIL PROTECTED] as the > > service principal name] with which to validate the user's TGT the ticket > > will come back encrypted in host/[EMAIL PROTECTED]'s 3DES key > > (because the KDC will select that long-term key because it's first in > > the KDB entry), which, sadly, the Solaris 9 mech_krb5 doesn't support. > > I guess this is what I want: > > http://www.ietf.org/internet-drafts/draft-zhu-kerb-enctype-nego-04.txt No, this is not applicable to your situation. > This helped just now though. What a mess. > > http://learningsolaris.com/docs/krb_enctypes_so10.pdf > > Looks like I'll redo my existing stuff to only ever allow > 1DES enctype (boggles my mind) via 'supported_enctypes' in > kdc.conf. Hmmm, OK, this is complicated, and I'd rather not go into all these details, but: - the Solaris 10 kadmind has a heuristic to detect Solaris 8 and 9 kadmin clients so that changing a service principal's keys results in getting only 1DES keys, - while for changing user passwords results in all supported_enctypes being allowed for the user. - at the same time, the Solaris 10 kadmin client's ktadd sub-command acts as though the -e option had been given, if it wasn't. So that if you have a Solaris 10 KDC and Solaris 8, 9 and 10 systems deployed you should not normally notice this 1DES vs. other enctypes issue. Perhaps we need to get this behaviour into MIT krb5, since you're using it alongside Solaris' krb5 support. I assume you're using MIT's KDC software. MIT? > That seems a real shame -- "Use 1DES in any homogenous > environment or you may really hurt yourself." > > Sadly, it also doesn't appear one can remove just *one* enctype > instance of a key (the 3DES one in my case). You could ktadd again, with -e des-cbc-crc:normal,... but though this is better than not having 3DES keys at all, it doesn't really buy you much security. > I'm glad I am finding all of this out now on a testbed > machine :O > > > You could upgrade to Solaris 10 and get support for AES (in addition to > > 3DES and HMAC-RC4)... > > Not an option. :( > Thanks for your help, Nico and Doug. NP. Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Solaris 9, stock sshd, pam_krb5, MIT 1.4.3 KDC
On Tuesday, May 16, 2006 05:32:45 PM -0400 Jeff Blaine <[EMAIL PROTECTED]> wrote: > I guess this is what I want: > > http://www.ietf.org/internet-drafts/draft-zhu-kerb-enctype-nego-04.txt Actually, this doesn't help with your problem. The mechanism described in that document allows a client and server to negotiate use of an enctype for communications with each other even when that enctype is not supported by the KDC. The problem you're having is that the KDC believes your service supports the des3-hmac-sha1 enctype, and so encrypts service tickets using that enctype. By design, there is nothing a client can do to influence the enctype used by the KDC to communicate with a service. -- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Solaris 9, stock sshd, pam_krb5, MIT 1.4.3 KDC
Nicolas Williams wrote: > On Tue, May 16, 2006 at 04:01:11PM -0400, Jeff Blaine wrote: >> I'm confused, then, Nicolas. >> >> As I read the output, there are 2 keys stored >> for these principals: >> >>1 using Triple DES cbc mode with HMAC/sha1 >> >>1 using DES cbc mode with CRC-32 >> >> And the first matching enctype is supposed to be used, >> which would be des-cbc-crc (and des3-hmac-sha1 would >> not, as it is not common to the client and server. > > What does kadmin -q "getprinc host/[EMAIL PROTECTED]" say? > > I bet the des3-hmac-sha1 key comes before the des-cbc-crc key. Yes, it does. > That means that when the stock pam_krb5/mech_krb5 do a TGS-REQ to get a > service ticket [for the PAM_USER with host/[EMAIL PROTECTED] as the > service principal name] with which to validate the user's TGT the ticket > will come back encrypted in host/[EMAIL PROTECTED]'s 3DES key > (because the KDC will select that long-term key because it's first in > the KDB entry), which, sadly, the Solaris 9 mech_krb5 doesn't support. I guess this is what I want: http://www.ietf.org/internet-drafts/draft-zhu-kerb-enctype-nego-04.txt This helped just now though. What a mess. http://learningsolaris.com/docs/krb_enctypes_so10.pdf Looks like I'll redo my existing stuff to only ever allow 1DES enctype (boggles my mind) via 'supported_enctypes' in kdc.conf. That seems a real shame -- "Use 1DES in any homogenous environment or you may really hurt yourself." Sadly, it also doesn't appear one can remove just *one* enctype instance of a key (the 3DES one in my case). I'm glad I am finding all of this out now on a testbed machine :O > You could upgrade to Solaris 10 and get support for AES (in addition to > 3DES and HMAC-RC4)... Not an option. Thanks for your help, Nico and Doug. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Solaris 9, stock sshd, pam_krb5, MIT 1.4.3 KDC
On Tue, May 16, 2006 at 04:01:11PM -0400, Jeff Blaine wrote: > I'm confused, then, Nicolas. > > As I read the output, there are 2 keys stored > for these principals: > >1 using Triple DES cbc mode with HMAC/sha1 > >1 using DES cbc mode with CRC-32 > > And the first matching enctype is supposed to be used, > which would be des-cbc-crc (and des3-hmac-sha1 would > not, as it is not common to the client and server. What does kadmin -q "getprinc host/[EMAIL PROTECTED]" say? I bet the des3-hmac-sha1 key comes before the des-cbc-crc key. That means that when the stock pam_krb5/mech_krb5 do a TGS-REQ to get a service ticket [for the PAM_USER with host/[EMAIL PROTECTED] as the service principal name] with which to validate the user's TGT the ticket will come back encrypted in host/[EMAIL PROTECTED]'s 3DES key (because the KDC will select that long-term key because it's first in the KDB entry), which, sadly, the Solaris 9 mech_krb5 doesn't support. You could upgrade to Solaris 10 and get support for AES (in addition to 3DES and HMAC-RC4)... Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Solaris 9, stock sshd, pam_krb5, MIT 1.4.3 KDC
I'm confused, then, Nicolas. As I read the output, there are 2 keys stored for these principals: 1 using Triple DES cbc mode with HMAC/sha1 1 using DES cbc mode with CRC-32 And the first matching enctype is supposed to be used, which would be des-cbc-crc (and des3-hmac-sha1 would not, as it is not common to the client and server. Nicolas Williams wrote: > On Tue, May 16, 2006 at 03:10:04PM -0400, Jeff Blaine wrote: >> Nicolas Williams wrote: >>> What does "klist -ke /etc/krb5/krb5.keytab" say? >> bash-2.05# /export/home/krb5/bin/klist -ke /etc/krb5/krb5.keytab >> Keytab name: FILE:/etc/krb5/krb5.keytab >> KVNO Principal >> >> -- >> 4 host/[EMAIL PROTECTED] (Triple DES cbc mode with HMAC/sha1) >> 4 host/[EMAIL PROTECTED] (DES cbc mode with CRC-32) >> 4 host/[EMAIL PROTECTED] (Triple DES cbc mode with HMAC/sha1) >> 4 host/[EMAIL PROTECTED] (DES cbc mode with CRC-32) >> 3 cvs/[EMAIL PROTECTED] (Triple DES cbc mode with HMAC/sha1) >> 3 cvs/[EMAIL PROTECTED] (DES cbc mode with CRC-32) >> 3 cvs/[EMAIL PROTECTED] (Triple DES cbc mode with HMAC/sha1) >> 3 cvs/[EMAIL PROTECTED] (DES cbc mode with CRC-32) >> bash-2.05# >> >>> It's possible that your host principal has keys of enctypes other than >>> des-cbc-crc or des-cbc-md5 -- since those are the only enctypes that >>> Solaris 9 supports this would be a misconfiguration. > > That's exactly it then. Solaris 9 does not support the 3DES enctypes. > > Change your host principal's keys to be only des-cbc-crc. > > Nico Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Solaris 9, stock sshd, pam_krb5, MIT 1.4.3 KDC
On Tue, May 16, 2006 at 03:10:04PM -0400, Jeff Blaine wrote: > Nicolas Williams wrote: > > What does "klist -ke /etc/krb5/krb5.keytab" say? > > bash-2.05# /export/home/krb5/bin/klist -ke /etc/krb5/krb5.keytab > Keytab name: FILE:/etc/krb5/krb5.keytab > KVNO Principal > > -- > 4 host/[EMAIL PROTECTED] (Triple DES cbc mode with HMAC/sha1) > 4 host/[EMAIL PROTECTED] (DES cbc mode with CRC-32) > 4 host/[EMAIL PROTECTED] (Triple DES cbc mode with HMAC/sha1) > 4 host/[EMAIL PROTECTED] (DES cbc mode with CRC-32) > 3 cvs/[EMAIL PROTECTED] (Triple DES cbc mode with HMAC/sha1) > 3 cvs/[EMAIL PROTECTED] (DES cbc mode with CRC-32) > 3 cvs/[EMAIL PROTECTED] (Triple DES cbc mode with HMAC/sha1) > 3 cvs/[EMAIL PROTECTED] (DES cbc mode with CRC-32) > bash-2.05# > > > It's possible that your host principal has keys of enctypes other than > > des-cbc-crc or des-cbc-md5 -- since those are the only enctypes that > > Solaris 9 supports this would be a misconfiguration. That's exactly it then. Solaris 9 does not support the 3DES enctypes. Change your host principal's keys to be only des-cbc-crc. Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Solaris 9, stock sshd, pam_krb5, MIT 1.4.3 KDC
On Tue, May 16, 2006 at 02:23:16PM -0400, Jeff Blaine wrote: > "authentication failed: Bad encryption type" > > bash-2.05# /export/home/krb5/sbin/ktutil > ktutil: rkt /etc/krb5.keytab > ktutil: list > slot KVNO Principal > > - > 14host/[EMAIL PROTECTED] > 24host/[EMAIL PROTECTED] > 34 host/[EMAIL PROTECTED] > 44 host/[EMAIL PROTECTED] > > What does "klist -ke /etc/krb5/krb5.keytab" say? It's possible that your host principal has keys of enctypes other than des-cbc-crc or des-cbc-md5 -- since those are the only enctypes that Solaris 9 supports this would be a misconfiguration. Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Solaris 9, stock sshd, pam_krb5, MIT 1.4.3 KDC
Nicolas Williams wrote: > On Tue, May 16, 2006 at 02:23:16PM -0400, Jeff Blaine wrote: >> "authentication failed: Bad encryption type" >> >> bash-2.05# /export/home/krb5/sbin/ktutil >> ktutil: rkt /etc/krb5.keytab >> ktutil: list >> slot KVNO Principal >> >> - >> 14host/[EMAIL PROTECTED] >> 24host/[EMAIL PROTECTED] >> 34 host/[EMAIL PROTECTED] >> 44 host/[EMAIL PROTECTED] >> >> > > What does "klist -ke /etc/krb5/krb5.keytab" say? bash-2.05# /export/home/krb5/bin/klist -ke /etc/krb5/krb5.keytab Keytab name: FILE:/etc/krb5/krb5.keytab KVNO Principal -- 4 host/[EMAIL PROTECTED] (Triple DES cbc mode with HMAC/sha1) 4 host/[EMAIL PROTECTED] (DES cbc mode with CRC-32) 4 host/[EMAIL PROTECTED] (Triple DES cbc mode with HMAC/sha1) 4 host/[EMAIL PROTECTED] (DES cbc mode with CRC-32) 3 cvs/[EMAIL PROTECTED] (Triple DES cbc mode with HMAC/sha1) 3 cvs/[EMAIL PROTECTED] (DES cbc mode with CRC-32) 3 cvs/[EMAIL PROTECTED] (Triple DES cbc mode with HMAC/sha1) 3 cvs/[EMAIL PROTECTED] (DES cbc mode with CRC-32) bash-2.05# > It's possible that your host principal has keys of enctypes other than > des-cbc-crc or des-cbc-md5 -- since those are the only enctypes that > Solaris 9 supports this would be a misconfiguration. > > Nico Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
