In principle, one should be able to activate agent forwarding by creating a ~/.thinlinc/config with:
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
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:
Note that OpenSSH has added some security improvements to the forwarding: