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:

https://cern-cert.github.io/pam_2fa/
https://www.privacyidea.org/ssh-keys-and-otp-really-strong-two-factor-authentication/

(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 .

thanks

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,
Martin