Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UseStrongestAuth "relogin" problematic on remote environments #12675

Closed
codingllama opened this issue May 16, 2022 · 2 comments · Fixed by #13134
Closed

UseStrongestAuth "relogin" problematic on remote environments #12675

codingllama opened this issue May 16, 2022 · 2 comments · Fixed by #13134
Assignees
Labels

Comments

@codingllama
Copy link
Contributor

codingllama commented May 16, 2022

Expected behavior: tsh asks for (or allows) OTP MFA.

Current behavior:

Relogin attempts default to the cluster's strongest auth method since #11781 - this is an intentional workaround for stdin-stealing issues (#11709).

The issue arises when relogin is triggered in remote/containerized environments (tsh-on-remote, WSL2) - in those scenarios USB-based MFA is not an option. The current mitigation is to cancel the relogin attempt and explicitly run tsh login, which does allow for multiple authn methods.

See comment #6630 (comment).

Bug details:

@codingllama codingllama self-assigned this May 16, 2022
@codingllama codingllama changed the title UseStrongestAuth workaround for relogin problematic on remote environments UseStrongestAuth "relogin" problematic on remote environments May 16, 2022
@gclawes
Copy link

gclawes commented May 16, 2022

This is probably a concern in enterprise SSO environments with the browser redirect to 127.0.0.1.

$ tsh --proxy=teleport.car.nasdaq.com login
If browser window does not open automatically, open it by clicking on the link:
 http://127.0.0.1:55107/1ec1e096-8b55-4de1-8d4f-6994de6d3233

Doing either the tsh login above or a similar re-login via kubectl exec assumes you are running on your local workstation, similar to the assumption that you have access to USB for WEBAUTN. I think in that case the only option is to forward the socket either with ssh -L or some kind of WSL2 socket forwarding (event then, the localhost socket isn't known in advance).

codingllama added a commit that referenced this issue Jun 3, 2022
Avoid "input swallowing" bugs by disabling stdin hijacking by default.

Only `tsh login` is allowed to hijack stdin, as it is expected to exit right
after authentication. Any MFA authentication attempts resulting from
non-`tsh login` invocations default to the user's strongest auth method.

Defaulting to the strongest auth method can cause problems in constrained
environments for users that have both Webauthn and OTP registered. For example,
someone using `tsh` under WSL (Windows Subsystem for Linux) or a remote machine
could be locked into Webauthn MFA, which they can't use because their
environment lacks USB access or they don't have physical access to it. In order
to solve this problem I've slightly modified the meaning of the `--mfa-mode`
flag so `otp` can be specified.

The `TELEPORT_MFA_MODE` environment variable may be set to avoid constant flag
passing.

Fixes #12675 and #13021.

* Expand --mfa-mode and disable stdin hijack by default
* Use TELEPORT_ instead of TSH_ for FIDO2 env var
* Use t.Setenv in tests
@codingllama
Copy link
Contributor Author

From #13021:

I've put together a fix that should land in master shortly (I'll port it to v9 after it lands).

It's similar to the fix #11709, but this time I've gone ahead and made anything that isn't tsh login default to the strongest MFA method. If that doesn't work for you (eg, remote machine), then you can use the --mfa-mode flag to specify a different MFA method (eg, tsh --mfa-mode=otp ssh llama@themachine). Setting the TELEPORT_MFA_MODE environment variable also works.

I'll keep the present issue (#12675) focused on MFA only, as SSO is a different issue altogether.

codingllama added a commit that referenced this issue Jun 6, 2022
Avoid "input swallowing" bugs by disabling stdin hijacking by default.

Only `tsh login` is allowed to hijack stdin, as it is expected to exit right
after authentication. Any MFA authentication attempts resulting from
non-`tsh login` invocations default to the user's strongest auth method.

Defaulting to the strongest auth method can cause problems in constrained
environments for users that have both Webauthn and OTP registered. For example,
someone using `tsh` under WSL (Windows Subsystem for Linux) or a remote machine
could be locked into Webauthn MFA, which they can't use because their
environment lacks USB access or they don't have physical access to it. In order
to solve this problem I've slightly modified the meaning of the `--mfa-mode`
flag so `otp` can be specified.

The `TELEPORT_MFA_MODE` environment variable may be set to avoid constant flag
passing.

Fixes #12675 and #13021.

* Expand --mfa-mode and disable stdin hijack by default
* Use TELEPORT_ instead of TSH_ for FIDO2 env var
* Use t.Setenv in tests
codingllama added a commit that referenced this issue Jun 8, 2022
Avoid "input swallowing" bugs by disabling stdin hijacking by default.

Only `tsh login` is allowed to hijack stdin, as it is expected to exit right
after authentication. Any MFA authentication attempts resulting from
non-`tsh login` invocations default to the user's strongest auth method.

Defaulting to the strongest auth method can cause problems in constrained
environments for users that have both Webauthn and OTP registered. For example,
someone using `tsh` under WSL (Windows Subsystem for Linux) or a remote machine
could be locked into Webauthn MFA, which they can't use because their
environment lacks USB access or they don't have physical access to it. In order
to solve this problem I've slightly modified the meaning of the `--mfa-mode`
flag so `otp` can be specified.

The `TELEPORT_MFA_MODE` environment variable may be set to avoid constant flag
passing.

Fixes #12675 and #13021.

* Expand --mfa-mode and disable stdin hijack by default
* Use TELEPORT_ instead of TSH_ for FIDO2 env var
* Use t.Setenv in tests
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants