Most of the ThinLinc administrators we've seen until now have been unexperienced
with Linux systems, which means that they don't know too much about security in
a Linux environment.
It is definitely not our role to tell them how to do everything, and we must
trust our dear partnertechnicians (heh..), but we could still give some hints.
This bug is for collecting ideas.
The first recommendation is to recommend having different root passwords on all
Another one is to use ssh-keys to connect to the other servers, but with
ssh-agent, not passwordless keys.
Running some kind of software that checks for root kits is also a good idea.
And so on, and so on..
Oh, and of course, always keep your distribution updated.
The previous examples may be a bit too general Linux administration stuff. A better example could be how you can prevent "normal" SSH access, whilst still letting ThinLinc run.
*** Bug 5604 has been marked as a duplicate of this bug. ***
I think it would be nice to document the use of an ThinLinc access group eg. "allow users in group to run thinlinc-login". with such a configuration a ssh system can be locked down in fully with two rules: "Only allow users in admins to get shell" and "Only allow users in thinlinc group to run thinlinc-login"
Due to the fact we piggyback on SSH lock down, we might want to provide information that SSH have a match system that could be used in combination with the info we provide.
Such as having a "trusted group that is allowed to use local drives" eg. portforwardning and a "non trusted group for disabling localdrives", on the same system.
I suggest that content for "Disabling local port forwarding" is moved as a note to "Disabling remote port forwardning"
We're happy with this now.
I have followed the instructions and they all work as advertised. Good!