Currently you cannot get SSO inside a ThinLinc session if you authenticate using Kerberos. The reason is that we do not forward the TGT to the ThinLinc server, and we do not provide any other authentication information so that kinit can be run inside the session. Solving this is non-trivial because of the way Kerberos and ThinLinc works. When you "forward" a TGT, you do not just send over a copy of the one you have. You ask the KDC for a new one. It is also unknown if we need to tell the KDC which machine the new TGT is for, which would complicate things further. Handling this on the client could get very messy. First of all, neither tlclient nor ssh has any explicit Kerberos knowledge. tlclient has just some GUI stuff, and ssh uses GSSAPI exclusively. Another crazy idea is to handle this from thinlinc-login. Since it is running inside the SSH session, it should have access to a forwarded TGT. Best case scenario, we can just copy that over to the agent. Worst case, we need to request yet another TGT for the agent. This requires more back-and-forth during session creation, and also requires the ticket in the SSH session to be forwardable once again. A third, more hackish approach is to have the session startup on the agent wait until the client connects. Then we can try to copy the TGT from the SSH session the client is using.
*** Bug 7105 has been marked as a duplicate of this bug. ***
(In reply to comment #0) > I'm not sure where the non-trivial aspects of this come in - our SSH already supports the GSSAPIDelegateCredentials option. For Linux and Mac clients, you can create a ~/.thinlinc/config file with the following contents: GSSAPIDelegateCredentials yes This should let you forward your Kerberos tickets to the server. I haven't been able to find if/where the Windows SSH client reads a file comparable to ~/.thinlinc/config. Ideally, we'd have a checkbox somewhere in the client to enable/disable this, and only enable this for the connection to the Agent.
We also need to re-think about what role tl-kinit plays in this now and moving forward. Right now, tl-kinit is an obstacle as it changes KRB5CCNAME, making it impossible for the ThinLinc session to find an already existing ticket cache. Adding on to the workaround in comment #4, administrators must delete the /opt/thinlinc/etc/xstartup.d/01-tl-kinit.sh link or remove the lines where it modifies KRB5CCNAME.
(In reply to comment #4) > I haven't been able to find if/where the Windows SSH client reads a file > comparable to ~/.thinlinc/config. C:\tlclient\etc\ssh_config seems to be the right place for a configuration file for Windows clients.
Letting SSH do the forwarding voids having to deal with any Kerberos communication elsewhere, but it has some issues that would need to be resolved: * There is an unknown time between session creation and client connection where we won't have a ticket. We could possibly wait for the client, but that would mean an artificial delay. * There is no guarantee that we share the ticket cache with the SSH session. We could stop setting $KRB5CCNAME but the system might still be configured to have one cache per session. * The ticket cache might be destroyed (depending on config) when SSH logs out, leaving a disconnected session without any tickets
