https://bugzilla.mindrot.org/show_bug.cgi?id=2310
Christoph Anton Mitterer <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX |--- --- Comment #3 from Christoph Anton Mitterer <[email protected]> --- Actually I've made some further tests on this issue in the meantime and it seems as if there is just some "timing issue", which is why I reopen the issue for now, perhaps you can have a look, whether that could be fixed easily. Remember, what I've basically tried to achieve is to get automated (i.e. passwordless) login to ssh hosts that require a kerberos ticket (+afs) for login and for the home dir access. And not only this, the whole thing should also work for multiple reams, i.e. when I connect to some nodes at CERN I want a ticket for CERN.CH being automatically generated and used with ssh,... while when I contact to the university's nodes, I want the same for the PHYISIK.LMU.DE realm. Okay from the k5start side everything seems to work. What I do is basically $ k5start -q -f kt -K 10 -- user@REALM ssh .... The keytab file (kt) works, and when I run ssh with the above, login works fine as well and the I get an AFS ticket (it's probably created on the server side). Now I try to get the whole thing into ssh_config, because I want all be done automatically and especially for different realms, so I do about the following: Host lxplus.cern.ch GSSAPITrustDns yes Host *.cern.ch User mitterer GSSAPIAuthentication yes GSSAPIDelegateCredentials yes GSSAPIRenewalForcesRekey yes ProxyCommand k5start -q -f kt -K 10 -- [email protected] nc %h %p The usage of ProxyCommand with k5start and nc is a hack here, which I hoped to solve the problem that the ticket is generated before the connection is done,... and nc %h %p simply passes everything through. In other words, this is the trick which I've tried to get the feature what I've asked for in the original submission of this ticket. This however doesn't work, which makes sense, as the ssh process has no way to know where the credential cache is that k5start creates randomly for this program invocation (nc), e.g. at /tmp/krb5cc_1000_VZ7FI5. It also exports KRB5CCNAME='FILE:/tmp/krb5cc_1000_CERN', of course, but this only gets known to nc. At that point, ssh already looked for KRB5CCNAME, didn't find any, and never tries again. Do you see any simple solution to get that working somehow? Maybe even in a completely different way (extending ssh-agent and k5start to interact?) or some other tricky hack? If not, and you still think that adding such feature isn't worth to make ssh nicely usable with kerberos, than just close it again if you feel necessary. Thanks, Chris. -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. _______________________________________________ openssh-bugs mailing list [email protected] https://lists.mindrot.org/mailman/listinfo/openssh-bugs
