A question for our users regarding two-factor authentication

, ,

In our recent 2022 ThinLinc Users’ Survey, we asked whether or not you use any form of two-factor authentication (2FA) or one-time password (OTP) with ThinLinc. We were quite surprised to find that 82% of respondents answered “no” to this question.

We do know that 2FA is a requirement for many organizations as part of their security protocol, and we are curious to know more about what these requirements are.

Specifically, we want to know whether anyone is interested in something like bug #4962, which would allow chaining together of multiple authentication mechanisms in the OpenSSH server configuration. This is slightly different to the way in which ThinLinc currently handles 2FA, and would enable different combinations of authentication mechanism to be used simultaneously.

Feel free to let us know whether (or not) you would find something like this useful, and leave any comments below.

OK - let me start the discussion, as the question above was triggered by our request to Cendio! :wink:
The solution we propose makes use of the SSH implementation, where one can combine a private key (no passphrase!) with the password login, i.e. SSH first checks the validity of the private key before it prompts for the user’s password! If the key is not valid, it will never go to ask for the password! In SSH, this is configured as

AuthenticationMethods publickey password

in sshd.config. The above requires both publickey and password (in that order), as opposed to the usual (standard) setting

AuthenticationMethods publickey,password

which is either key or password, i.e. only one is sufficient!

The advantage of our proposal is, that it will work for all SSH based services - if the SSH client, or the application using the SSH protocol, supports it! As our users are not only using ThinLinc, but also file transfer applications, like FileZilla, WinScp, etc, i.e. a solution that supports a broad range of applications, is preferred!

In our proposed local setup, the public key has to be uploaded by the user(s), and will be stored in a central database, i.e. this key will not live under ~/.ssh! Each user can have several keys, e.g. one per device, and the user can revoke keys, or change them. We (the administrators), can also revoke keys, e.g. if there are signs of misuse, the user reports a lost device, etc.

Comments? Thoughts? Something we are missing, or some detail we are not aware of?

BTW, we have shown in a proof-of-concept, that the ThinLinc SSH client could support the proposed setup! :wink:

1 Like

We are getting some questions about support for this feature from OpenSSH in ThinLinc, so I thought it best to clarify Cendio’s current view on this.

In general, we like to be compatible with ssh as much as possible, and this feature is no exception. However, supporting this would be quite a bit of work since the ThinLinc client is currently heavily designed around a single authentication method at a time. That means we get a bit more cautious about making sure this is a good way to spend our development resources, as they will always be limited.

I.e. adding this feature means something else will have to wait.

Multi-factor authentication is definitely desirable in today’s world. However, there are many ways to achieve that, and we are concerned that this might not be the best way. Specifically, there are a few points that give us pause:

  • An ssh private key is just a file, which can easily be duplicated if a device gets compromised or the user is careless. Many (most?) other MFA methods try to make the second factor difficult to clone, strengthening the connection between the second factor and the user.
  • Public key authentication is specific to ssh. That means users will have to deal with a different MFA system when accessing other systems. Even accessing ThinLinc via Web Access will need a different MFA, since ssh isn’t used there.

I tried to get a picture of how others are using the combination of public key authentication and a password, but I’m afraid I couldn’t find any good examples. What I could find were people combining public key authentication with a more classical MFA:


(note that these types of deployments would also require changes in the ThinLinc client)

So, we’re interested in what benefits the combination public key and password might give that would make it interesting to prioritise development for it.

we would very much like to be able to use 2FA (cornell has standardized on Duo 2fa). The main reason we aren’t using it at the moment for thinlinc is that, my understanding is that users would get prompted twice in a HA config… once during the initial connection to the vsmserver and then again to the connecting vsmagent .


Hello, @dwbotsch

We have other customers running ThinLinc with different types of 2FA solutions without any issues with being prompted twice. I will drop you a private message with some additional info.

Kind regards,

We’re looking at different MFA options for two environments where we use ThinLinc.

  1. Users connecting (mostly via Web Access with some ssh/client access)
  2. ThinLinc to more restrictive systems is being tested where users login to a webapp using Microsoft Authenticator. They generate an SSH key pair with a password on the key. Their private key is automatically stored in LDAP. A ThinLinc client is configured to connect to a specific system, specifying the new public key in the users home directory. The user launches the ThinLinc client shortcut, enters their username and are prompted for the password on the key and are granted access. SSHD on the server is configured to match users based on a specific group, requiring publickey auth using AuthenticationMethods, with AuthorizedKeysCommand and AuthorizedKeysCommandUser settings for that group.

We’re looking for other ways to use MS Authenticator (username/password auth, then push to Authenticator) or Cisco Duo, etc.

Your point 2 looks very much like the solution we have proposed, and tested in a PoC. Users upload their private key(s) (can be several keys, e.g. one per device) in a MFA protected environment, and the key(s) are stored in LDAP (or similar). The SSHD on the TL server is configured to require both key and password, in that order. All we need is support in the TL client … :wink:


We just created a test setup with Cisco Duo on a new RHEL7 virtual machine. SSH access to the Duo host works as expected (login username/password, approve the push to the mobile device, auth succeeds). When I try connecting with ThinLinc (both the MacOS client and WebAccess) it works similarly, only I’m prompted with a push notification TWICE to approve, similar to what dwbotsch mentioned.

I haven’t looked into it - just noticed two pushes when I login via ThinLinc, but not SSH.

The SSH key pair solution, so far, has been deemed too complex for users, so we’re looking at alternatives (Cisco Duo, duo_unix PAM module).

Thanks everyone for your feedback on this subject. There are some useful insights here.

For those not aware, one way to keep up-to-date with progress on feature requests and changes is through the Cendio Bugzilla. You can sign up for an account and subscribe to bugs you find interesting by checking the “Add me to CC list” box at the top right of the page, and then clicking “Save changes” at the bottom. You will then receve email notifications whenever something changes, for example if the bug gets scheduled for a release.

A couple of bugs relevant to the above discussion: