A question for our users regarding two-factor authentication

Blog
, ,
1

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.

2

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
3

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.

4

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

5

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

6

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.

7

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:

2 Likes
8

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.

9

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

10

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:

https://bugzilla.cendio.com/show_bug.cgi?id=2545

https://bugzilla.cendio.com/show_bug.cgi?id=8043

2 Likes
11

@martin I’ve read through the Google Authenticator method of handling the dual MFA prompts with Master/Agent. Is there a solution for Cisco DUO MFA to only prompt one time? Certainly, not a deal; breaker but simpler for our users. Thanks. Currently, both Master and Agent are running on a single system.

12

@NyleFL It might be possible, but I’m not aware of any implementation of it.
A quick Google didn’t yield any positive results for me. Have you consulted their documentation, or perhaps reached out to their forums?

Kind regards,
Martin

13

Thanks Martin, I appreciate the reply. I thought it was worth asking if you had seen anything with how frequently you were on the threads related. :grinning:

I’ll open a new thread to ask.

14

what does the client actually connect to on the server? Does it connect to the ssh daemon itself? Does it connect to the vsmagent? Does it connect to the vsmserver? (since one could have a different pam config for each, if they all use their own authN and pam and only have the DUO pam config in whichever… OR if there was something that pam_succeed_if could query to [not] skip over the duo prompt for the second and final connection to the server).

And how does google authN avoid this same issue? Especially in an HA config where both connections might be to separate physical servers?

thanks!
-daveb

15

The client makes two connections, first to the master server, then to the agent. These may be the same machine, or separate, depending on your configuration. In all cases, authentication is handled via sshd when using the native client.

The issue with many one-time password solutions is that they only allow the OTP to be used once. That means users get prompted twice when connecting to ThinLinc, since the second connection requires a new OTP.

I’m unsure if it’s possible to use different sshd configurations for master and agent servers, and only requiring OTP for one of the connections. @samuel do you know?

Google Authenticator (and others) avoid this issue by allowing a configurable “grace period” for the OTP, meaning it can be used multiple times within a certain window of time.

Hope that helps.

16

One thought… if you had your own pam module that talked to both the vsmserver and vsmagent processes to determine what tl login “stage” the user is in… the result of that module could be used to then skip or not skip the pam_duo line. So that one doesn’t do pam_duo for both vsmserver and vsmagent … I don’t see any way to pass any type of context to pam via sshd directly that can be queried.

and I do see some PAM-ish stuff in /opt/thinlinc… tl-pamapp … what do these do?

The second possibility would be to have, every time a session (re)_connects… thinlinc itself fires off either directly or indirectly a gui dialogue that is a program calling into its own pam service configured for DUO… and if that doesn’t come back with success, signals vsmserver to disconnect right then and there.

thanks
-daveb

17

I’m unsure if it’s possible to use different sshd configurations for master and agent servers, and only requiring OTP for one of the connections. @samuel do you know?

@aaron Using different sshd configurations for the master and agent servers should be fine, given that they are separate machines. Keep in mind that in such a scenario, the master server should be a master-only machine, and not a combination of master+agent. Otherwise, your users will get inconsistent behavior depending on which agent they end up on.

I don’t see any way to pass any type of context to pam via sshd directly that can be queried.

@CendioOssman any ideas here?

and I do see some PAM-ish stuff in /opt/thinlinc… tl-pamapp … what do these do?

@dwbotsch these are used for Web Access since that doesn’t use SSH.

18

I don’t think that the separate standalone server machine is the right answer.

The best thing is probably for cendio to code either a glue pam module or something that happens at session (re) connect into TL itself (that would then also call into pam or whatever).

thanks

19

@dwbotsch I’m aware of at least one case where pam_timestamp has been used to avoid the second authentication:

https://www.man7.org/linux/man-pages/man8/pam_timestamp.8.html

Whether this is an acceptable solution or not depends on your security requirements.

20

I’m afraid I’m not aware of anything we can easily pass on to PAM. We also need a solution that works with a standard PAM configuration, as not all users might be willing to do something custom for ThinLinc.