In principle, one should be able to activate agent forwarding by creating a ~/.thinlinc/config with: Host * ForwardAgent yes This does not work, though, because tlclient clears out SSH_AUTH_SOCK when not using smart cards.
The normal SSH client has an option "-A" that enables forwarding of the authentication agent connection. Ie, if you have an ssh-agent and a suitable environment variable SSH_AUTH_SOCK, the remote sshd will create a tunnel to it, and setup a suitable SSH_AUTH_SOCK in the remote session. One customer uses this approach for their customers: They have an ssh-agent on the client, and then uses agent forwarding to all hosts. They asked if this could be used with ThinLinc. I've done a quick check and I believe it is possible to setup a soltuion like this. We would need to add -A to the ssh command line (or use a config file). Then, the main problem is that the SSH_AUTH_SOCK environment variable is not available in the TL session; only in the SSH one. Typically, you can work around this by executing: export SSH_AUTH_SOCK=`echo /tmp/ssh-*/agent.*` This works if this particular user has only one agent socket on this server. A better solution would be to use a "fixed" name tied to the session number. thinlinc-login (which can see SSH_AUTH_SOCK) can then adjust the symbolic link accordingly.
Other issues to think about: * Should we forward the key used by the ThinLinc client? Or the smart card? * What if the user wants to run an agent inside the session as well?
GNOME likes to start its own SSH agent. See info here: https://wiki.archlinux.org/index.php/GNOME/Keyring
Note that OpenSSH has added some security improvements to the forwarding: https://www.openssh.com/agent-restrict.html
