Bug 4962 - Support for multiple authentication methods simultaneously
Summary: Support for multiple authentication methods simultaneously
Status: NEW
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Client (show other bugs)
Version: 4.1.1
Hardware: PC Unknown
: P2 Normal
Target Milestone: MediumPrio
Assignee: Peter Åstrand
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-01-17 13:30 CET by Henrik Andersson
Modified: 2024-02-12 01:31 CET (History)
9 users (show)

See Also:
Acceptance Criteria:


Attachments

Description Henrik Andersson cendio 2014-01-17 13:30:46 CET
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."
Comment 1 Aaron Sowry cendio 2014-04-25 11:26:09 CEST
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.
Comment 2 Henrik Andersson cendio 2014-04-25 11:29:18 CEST
(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 ?
Comment 3 Torkil Svensgaard 2015-08-18 15:10:49 CEST
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.
Comment 4 Torkil Svensgaard 2017-12-21 07:30:39 CET
This came up yet again, is it on your road map? =)
Comment 5 Samuel Mannehed cendio 2017-12-27 09:33:48 CET
(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.
Comment 9 Mats Kronberg 2021-06-07 16:14:48 CEST
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.
Comment 12 Erik Starbäck 2021-11-15 14:23:16 CET
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
...
Comment 14 Torsten Kasch 2022-02-28 16:26:42 CET
(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?
Comment 15 Pierre Ossman cendio 2022-02-28 17:10:45 CET
"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.
Comment 16 Torsten Kasch 2022-02-28 17:40:40 CET
(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...
Comment 17 Torsten Kasch 2022-03-01 08:15:57 CET
(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. :-(
Comment 25 Matt Perkins 2024-02-12 01:31:20 CET
+1 for needing this for ssh public key and 2FA which is now a requirement in our orginization. 

Matt

Note You need to log in before you can comment on or make changes to this bug.