Solaris 9, stock sshd, pam_krb5, MIT 1.4.3 KDC
Henry B. Hotz
hotz at jpl.nasa.gov
Thu May 18 19:12:00 EDT 2006
On May 16, 2006, at 2:32 PM, kerberos-request at mit.edu wrote:
> Message: 9
> Date: Tue, 16 May 2006 17:32:45 -0400
> From: Jeff Blaine <jblaine at kickflop.net>
> Subject: Re: Solaris 9, stock sshd, pam_krb5, MIT 1.4.3 KDC
> To: kerberos at mit.edu
> Message-ID: <446A44FD.2050802 at kickflop.net>
> 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/noodle.foo.com at JBTEST" 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.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu
More information about the Kerberos
mailing list