This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: Unable to delegate credentials from Cygwin ssh client was Re: Heimdal 1.5.2: "unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10"
- From: Jeffrey Altman <jaltman at openafs dot org>
- To: cygwin at cygwin dot com
- Date: Tue, 25 Jun 2013 11:56:53 -0400
- Subject: Re: Unable to delegate credentials from Cygwin ssh client was Re: Heimdal 1.5.2: "unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10"
- References: <409A0E510096B044A0EE3778BB3F1F5C01379C903ECD at EXMAIL dot hrl dot com> <51C4855C dot 5050206 at openafs dot org> <409A0E510096B044A0EE3778BB3F1F5C01379C904239 at EXMAIL dot hrl dot com>
On 6/25/2013 1:23 AM, Nogin, Aleksey wrote:
> Jeffrey Altman wrote:
>
>>> I am running Heimdal's kinit (as came with MobaXterm 6.2) under
>>> Windows 7 to get a ticket from a Windows AD, and then ssh'ing into RHEL
>>> 5 and 6 boxes set up to use pam_krb to authenticate against the same
>>> Windows AD. gssapi-with-mic authentication succeeds, but credential
>>> delegation does not, and I see the same "unknown mech-code 2529639054
>>> for mech 1 3 6 1 4 1 311 2 2 10" error(**) previously reported. This is
>>> an issue in my environment, where Kerberos-secured NFS is used to
>>> provide access to home directories.
>>>
>>> One thing I did notice is that when I ssh into an RHEL box, afterwards
>>> kinit on the client (Cygwin) side shows a ticket for the RHEL host (as
>>> expected), yet it shows that the ticket lacks the "forwardable" flag,
>>> which would probably explain the failure to delegate credentials. So
>>> perhaps this is a problem with the SSH client on the Cygwin end ("ssh -
>>> V" reports "OpenSSH_6.1p1, OpenSSL 1.0.1c 10 May 2012"), rather than
>>> Heimdal's? The libdefaults section in krb5.conf on Cygwin does contain
>>> "forwardable = yes" and in contract to how it happens on Cygwin, the
>>> Linux->Linux ssh that does delegate credentials correctly also does
>>> obtain a forwardable ticket on the client side.
>>
>> Going back to the original posting.
>>
>> The Heimdal that is being used is MobaXTerm's kinit.
>>
>> What Heimdal is it?
>
> "kinit --version" reports "kinit (Heimdal 1.5.2)". That said, things look exactly the same with plain Cygwin (which reports the same version of Heimdal)
>
> [snip]
If it is the Cygwin binary then it will be linked against cygwin1.dll.
If it is the native binary it will contain resource information visible
in the explorer shell and if it came from the Secure Endpoints package
will be digitally signed.
>> The Heimdal distribution matters because it will determine where the
>> krb5.conf configuration file is going to be stored. If you aren't sure,
>> use "SysInternals Process Monitor" to trace the "kinit.exe" process and
>> see what files it accesses.
>
> The configuration is stored in /etc/krb5.conf (behavior changes depending on the contents of that(. I am using the exact same krb5.conf that works correctly on RHEL.
>
>> When "kinit" is executed, is the "-f" parameter provided requesting a
>> "forwardable" ticket granting ticket?
>
> No, but I have "forwardable = yes" under "[libdefaults]" in krb5.conf. I can run "klist -vvv" and I see that the flags are as follows:
>
>
> Server: krbtgt/REALM@REALM
> Client: anogin@REALM
> [...]
> Ticket flags: pre-authent, initial, renewable, forwardable
> Addresses: addressless
>
> Server: host/sshserver@REALM
> Client: anogin@REALM
> [...]
> Ticket flags: pre-authent
> Addresses: addressless
>
> Again, the above is the same with "plain" Cygwin.
The TGT issued to your principal is forwardable but the
host/<fqdn>@<REALM> principal is not. There are four possibilities:
1. sshd is not properly requesting a forwardable ticket
2. a request to the KDC is being issued with the forwardable flag but
the KDC is refusing to issue a forwardable ticket because:
a. The krbtgt/<REALM>@<REALM> service principal does not permit
forwarding
b. The host/<fqdn>@<REALM> service principal does not permit
forwarding
3. a bug in Heimdal where the forwardable flag is not set when it
should be.
I would start by using wireshark to examine the requested tickets
and the response.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple