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