Under OSF/1, DCE credentials are created in the SIA layer for the parent when the user log's in with a password. These credentials do not get forwarded to the child session. This can be done via passing an environmental variable from parent to child in session.c. The following fix accomplishes this functionality and is basically a NO-OP in the event that the required environmental variable is not present: [kmy@gazelle:/dfs/sys/packages/ssh/openssh-3.4p1/alpha_tru64_v510] diff session.c.orig session.c 940c940 < char **env; --- > char **env, *dcecreds; 954a955,958 > > /* Propagate DCE credentials to child .. kmy@ornl.gov */ > if( (dcecreds=getenv("KRB5CCNAME")) ) > child_set_env( &env, &envsize, "KRB5CCNAME", dcecreds ); [kmy@gazelle:/dfs/sys/packages/ssh/openssh-3.4p1/alpha_tru64_v510] With this fix installed, users may use native DFS without the complexity of having to perform a dce_login in addition to their normal login, because the child now has access to the file containing the credentials of the parent and accepts them as their credentials. are sent to the
The attached patch has been corrupted - please attach it (in "diff -u" format) to the bug using the "Create Attachment" link
Created attachment 197 [details] diff -u session.c session.c.orig Output of "diff -u" attached as requested. -- Ken Matney, Sr.
I am not sure I understand (my Kerberos knowledge isn't so great): We already set this for Krb5 auth: #ifdef KRB5 if (s->authctxt->krb5_ticket_file) child_set_env(&env, &envsize, "KRB5CCNAME", s->authctxt->krb5_ticket_file); #endif
The existing code only handles the situation where Kerberos credentials are created by the OpenSSH's krb5 code. What would appear to be happening under OSF/1 is that one of the calls used to verify the users login is, as a by-product, creating the credentials cache. When the child is forked, this environment information is being lost. We already handle the case for Cygwin where we have to propagate the parents environment to the child - this is just a special case of that.
I am no longer running OSF1; although, I may have to do so in the future. The last comment on propagating parent's environment to the child is mostly correct. The call to sia_ses_init creates a KRB5 ticket which contains authorization/authentication for the parent. This ticket information needs to be propagated to the child. Actually, this is the proper way to handle OSF1 SIA; since, the operating system SIA layer is run-time configurable by design and you do not really want to pass the user's password to KRB5 a second time. This is to say that the file, /etc/sia/matrix.conf tells the OS about whether or not DCE is a valid authentication/authorization method. In the event that DCE is being used, the parent's authorizations do need to be propagated to the child. However, we also must deal with the case wherein DCE is no longer a valid mechanism. In this case, the parent will not have an authorization to propagate. -- Ken Matney, Sr.
Oops! That should have been sia_ses_authent instead of sia_ses_init. And sia_ses_release does not destroy the credential (also by design). -- Ken Matney, Sr.
There's a special case for copying KRB5CCNAME for AIX (because its auth modules might set it), so perhaps we just need to add a case for Tru64+SIA?
Target for early openssh-3.9
Created attachment 603 [details] Copy KRB5CCNAME for Tru64/SIA too
Comment on attachment 603 [details] Copy KRB5CCNAME for Tru64/SIA too Looks good to me. Assuming that it fixes the problem, then OK to commit.
Created attachment 626 [details] Simpler alternative patch Always check for KRB5CCNAME, since there are other instances where this is needed (eg PAM in some configurations). See: http://marc.theaimsgroup.com/?m=108366671611466
Created attachment 628 [details] Always unset KRB5CCNAME too.
BTW, if anyone uses OSF1/DUnix/Tru64 with DCE or another platform with the same issue, could you please confirm if the patch resolves it?
I tested this with a fake KRB5CCNAME and it worked as expected. Since essentially the same code is already enabled for AIX, I'm going to commit #628 unless someone objects.
#628 committed. Thanks all.
With the release of OpenSSH 4.0, these bugs are now closed. For details, see: http://www.openssh.com/txt/release-4.0