Restricting access to ThinLinc servers

In some cases it might be desirable or required to restrict the users’ access to the ThinLinc servers and their ability to move data in and out of the system. This chapter describes some ways this can be achieved, as well as the consequences of such restrictions.

Disabling SSH access

The system’s SSH server often includes a lot of functionality for accessing the system. Completely disabling this service is a quick way to restrict most of the external access to the system. However the native ThinLinc client requires SSH to function so users will be limited to only using the HTML based Web Access client.

Many SSH servers also support limiting access to just certain users. OpenSSH has settings such as AllowGroups and Match that can limit functionality without completely disabling the SSH server.

Disabling shell access

User sessions are normally started via the user’s configured shell, so restricting the shell is a good method to restrict what kind of sessions the user can start. Primarily this is usefull to prevent users from running custom commands via SSH.

Changing the configured shell

Commonly the user’s shell is configured to /bin/false in order to disable shell access. Unfortunately this also prevents access to ThinLinc as it needs to run the commands thinlinc-login and /opt/thinlinc/etc/xsession via the user’s shell. As an alternative it is possible to configure /usr/bin/thinlinc-login as the shell. This will allow ThinLinc to function whilst preventing any other type of session.

Note that this method prevents any terminals inside the session from functioning as well. In most cases it also does not prevent users from running custom scripts and shell commands as they can use a text editor to construct such scripts.

Using ForceCommand

OpenSSH has the ability to ignore the user’s configured shell and run a different command instead. This makes it possible to keep a normal shell for the user and only restrict access when connecting via SSH. However this prevents the native ThinLinc client from connecting as it needs to be able to run the command thinlinc-login with specific arguments. The following script can be specified as ForceCommand to allow only ThinLinc access via SSH:

thinlinc-login -c "${SSH_ORIGINAL_COMMAND}"

It is also possible to apply this restriction only to a subset of users by using the Match setting. Please see OpenSSH’s documentation for how to configure this mechanism.

Disabling port forwarding

ThinLinc relies on SSH port forwarding in order to function. However it is possible to limit that port forwarding in order to avoid unwanted network access. ThinLinc only requires forwarding via the loopback interface, so the SSH server can always be configured to only allow this without limiting ThinLinc in any way. For OpenSSH this is configured by specifying the following in sshd_config:

GatewayPorts no

Note that it is also necessary to disable shell access in order to completely prevent users from forwarding ports as otherwise they could run their own forwarding software over the shell channel.

Disabling remote port forwarding

It is possible to use ThinLinc with remote port forwarding completely disabled. However this will prevent local devices such as sound, drives and printers from functioning. In OpenSSH this is configured by adding the following to /etc/ssh/sshd_config:

AllowTcpForwarding local

It is also possible to apply this restriction only to a subset of users by using the Match setting. Please see OpenSSH’s documentation for how to configure this mechanism.


Local port forwarding cannot be disabled as it is required for even the basic ThinLinc functionality.

Disabling clipboard

It is possible to disable clipboard transfers in either direction in order to avoid easily moving data to and from the server. The first step is adding -noclipboard to the ThinLinc setting /vsmagent/xserver_args. This prevents the user from later changing the clipboard settings. Next add -AcceptCutText=0 to disable clipboard transfers going to the server, and -SendCutText=0 to prevent transfers going from the server.

Disabling local drives

ThinLinc local drives redirection relies on being able to ask the kernel to mount a NFS share. This is a privileged operation that only root is permitted to perform, and as such this feature requires a setuid helper binary. This helper is called /opt/thinlinc/libexec/tl-mount-personal and the setuid permission can be removed by running the follow:

$ sudo chmod u-s /opt/thinlinc/libexec/tl-mount-personal

Note that this only disables the ability to use the kernel NFS client. If a user can start some other NFS client then they can still access the local drive redirection. The setuid permission is also restored each time ThinLinc is upgraded.