ThinLinc client does only use the explicit chosen authentication method while the backend (SSH) supports using several methods in a chain. There are two use cases for this, first one is to get the same behavior as with using a ssh client, try this if fail, continue with next method... The second use case is to support two factor authentication which is available in OpenSSH 6.2 which a configuration server side using AuthenticationMethods as manual specifies: "Specifies the authentication methods that must be successfully completed for a user to be granted access. This option must be followed by one or more comma-separated lists of authentication method names. Successful authentication requires completion of every method in at least one of these lists."
Another potential use-case is for organisations where different groups of users are using different authentication methods. i.e. display the username/password fields *unless* a smartcard is inserted.
(In reply to comment #1) > Another potential use-case is for organisations where different groups of users > are using different authentication methods. i.e. display the username/password > fields *unless* a smartcard is inserted. That sound more like Bug #3556 ?
We're still interested in this, as TOTP like google authenticator seems to be either all or nothing, where as support for AuthenticationMethods would make it possible to support different scenarios, like doing different things depending on the originating IP address.
This came up yet again, is it on your road map? =)
(In reply to comment #4) > This came up yet again, is it on your road map? =) Hi Torkil, no it's currently not. Please contact our support or sales team if this feature is important to you.
We are also interested in this feature. Use case: authenticate users using (username+password+TOTP code) OR (username+SSH public key+TOTP code). We will also reach out to you through sales to request this.
I can agree that even UPPMAX is really interested in the request above from Mats K. And now when SNIC tries to coordinate second factor solutions, it would be very good to have thinlinc as a system compatible with ... ChallengeResponseAuthentication yes AuthenticationMethods publickey,keyboard-interactive ...
(In reply to Mats Kronberg from comment #9) > We are also interested in this feature. Use case: authenticate users using > (username+password+TOTP code) OR (username+SSH public key+TOTP code). That's exactly what we're trying to achieve: optional 2FA for both public key and password authentication. Based on https://cern-cert.github.io/pam_2fa/ we have a PAM config working as desired but only for plain/text ssh sessions and not for tlclient's ssh connection. After some tracing we believe that's due to the fact that tlclient calls "ssh -o NumberOfPasswordPrompts=1" which seems to break for the PAM setup mentioned above where the password-interactive PAM stack is processed twice: [...] UsePAM yes PubkeyAuthentication yes PasswordAuthentication no ChallengeResponseAuthentication yes AuthenticationMethods publickey,keyboard-interactive:pam \ keyboard-interactive:pam,keyboard-interactive:pam [...] In fact, tlclient seems to work for us as expected when we modify the tlclient binary replacing "NumberOfPasswordPrompts=1" with "NumberOfPasswordPrompts=3" (the default according to the man page). I'm not sure if this would break other setups, but if not, this might be a feasible change for a future client version?
"keyboard-interactive:pam,keyboard-interactive:pam" is a very odd configuration and not how PAM normally operates. I see from your link that there has been some modifications to try to coax PAM to do the right thing anyway, but I would recommend avoiding trying to cram a round peg in a square hole. I would suggest changing that to a single PAM invocation (i.e. "keyboard-interactive:pam") and adjust your PAM configuration so that it does both password and 2FA if no previous public key authentication has been performed. You should be able to do that and still not send out extra SMS by being careful how you stack things. Changing "NumberOfPasswordPrompts" will at the very least nag users in an odd way if they enter the wrong password, and may break in other ways as that is not what the client is designed to handle. So I'm afraid that is not a reliable way forward here.
(In reply to Pierre Ossman from comment #15) > "keyboard-interactive:pam,keyboard-interactive:pam" is a very odd > configuration and not how PAM normally operates. I see from your link that > there has been some modifications to try to coax PAM to do the right thing > anyway, but I would recommend avoiding trying to cram a round peg in a > square hole. Well, it looks strange, I've to admit. But since the patch mentioned by the CERN guy was accepted upstream quite some time ago, there's now official support for passing a state between two separate runs through the PAM stacks in OpenSSH. Thereforre I'd consider our setup legitimate...
(In reply to Pierre Ossman from comment #15) [...] > I would suggest changing that to a single PAM invocation (i.e. > "keyboard-interactive:pam") and adjust your PAM configuration so that it > does both password and 2FA if no previous public key authentication has been > performed. You should be able to do that and still not send out extra SMS by > being careful how you stack things. On Ubuntu 20.04 it seems to be sufficient to have "auth required pam_google_authenticator.so nullok" in /etc/pam.d/common-auth to make 2FA work for ThinLinc logins but only for password authentication. When using public key auth, the second factor won't get queried, but this is what we want to have. Unfortunately we did not succeed in getting 2FA to work in both cases without the hack described in comment #14. But maybe we're missing something... > Changing "NumberOfPasswordPrompts" will at the very least nag users in an > odd way if they enter the wrong password, and may break in other ways as > that is not what the client is designed to handle. So I'm afraid that is not > a reliable way forward here. I was afraid that this wouldn't be an option. :-(
https://community.thinlinc.com/t/a-question-for-our-users-regarding-two-factor-authentication/342/6
+1 for needing this for ssh public key and 2FA which is now a requirement in our orginization. Matt
Just for the sheer hell of it I experimented by binary patching the tlclient.bin placing a zero byte at the start of the "ChallengeReponseAuthentication=no" and "KbdInteractiveAuthentication=no" strings, and with this hack, 2FA with an SSH key and a OTP using Google Auth worked perfectly. To prevent being asked for a second OTP, you can also set "grace_period=15" in the pam_google_authenticator.so parameters. (This was run on the Linux x86_64 client, version 4.17.0) Unfortunately, since this is a hack it’s not something I can roll out to other users, however, like Matt Perkins above, corporate are mandating SSH keys + 2FA. Perhaps in the configuration settings for SSH key, the Thinlinc client could provide a tick box that disables sending the above strings to the SSH client?
