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