MFA modal in Connect asks for key insertion despite tshd not waiting for a key to be inserted

[ravicious]

The MFA modal tells you to insert a key and tap it:

This works on Windows where tshd uses a system prompt which handles that scenario. On macOS however we use the same custom prompt as tsh. If you try to call tsh login with no keys inserted, you'll see that it fails immediately.

tsh login with no keys

$ tsh login --proxy=teleport-local.dev:3090 -d
2024-11-19T16:18:16+01:00 INFO [CLIENT]    No teleport login given. defaulting to rav client/api.go:1280
2024-11-19T16:18:16+01:00 INFO [CLIENT]    no host login given. defaulting to rav client/api.go:1290
2024-11-19T16:18:16+01:00 INFO [CLIENT]    [KEY AGENT] Connected to the system agent: "/private/tmp/com.apple.launchd.AzQxOSRLq5/Listeners" client/api.go:4760
2024-11-19T16:18:16+01:00 DEBU [TSH]       Pinging the proxy to fetch listening addresses for non-web ports. common/tsh.go:4024
2024-11-19T16:18:16+01:00 DEBU [CLIENT]    attempting to use loopback pool for local proxy addr: teleport-local.dev:3090 client/api.go:4718
2024-11-19T16:18:16+01:00 DEBU [CLIENT]    reading self-signed certs from: /var/lib/teleport/webproxy_cert.pem client/api.go:4726
2024-11-19T16:18:16+01:00 DEBU [CLIENT]    could not open any path in: /var/lib/teleport/webproxy_cert.pem client/api.go:4730
2024-11-19T16:18:16+01:00 DEBU  Attempting request to Proxy web api method:GET host:teleport-local.dev:3090 path:/webapi/ping trace_id:5908b62650191af9c5dee49e6d4443fb span_id:3b629505ad7f3a1d webclient/webclient.go:134
2024-11-19T16:18:16+01:00 DEBU  ALPN connection upgrade test complete address:teleport-local.dev:3090 upgrade_required:false trace_id:5908b62650191af9c5dee49e6d4443fb span_id:3b629505ad7f3a1d client/alpn_conn_upgrade.go:96
2024-11-19T16:18:16+01:00 DEBU  Attempting request to Proxy web api method:GET host:teleport-local.dev:3090 path:/webapi/find trace_id:5908b62650191af9c5dee49e6d4443fb span_id:172a8ed9f1e513d5 webclient/webclient.go:134
2024-11-19T16:18:16+01:00 DEBU [CLIENT]    Attempting to login with new software private keys. client/api.go:3994
Enter password for Teleport user rav:
2024-11-19T16:18:18+01:00 DEBU [CLIENT]    attempting to use loopback pool for local proxy addr: teleport-local.dev:3090 client/api.go:4718
2024-11-19T16:18:18+01:00 DEBU [CLIENT]    reading self-signed certs from: /var/lib/teleport/webproxy_cert.pem client/api.go:4726
2024-11-19T16:18:18+01:00 DEBU [CLIENT]    could not open any path in: /var/lib/teleport/webproxy_cert.pem client/api.go:4730
2024-11-19T16:18:18+01:00 DEBU [CLIENT]    HTTPS client init(proxyAddr=teleport-local.dev:3090, insecure=false, extraHeaders=map[]) client/weblogin.go:519
2024-11-19T16:18:19+01:00 DEBU             Attempting platform login webauthncli/api.go:168
2024-11-19T16:18:19+01:00 DEBU             Platform login failed, falling back to cross-platform error:[touch ID not available] webauthncli/api.go:174
2024-11-19T16:18:19+01:00 DEBU             FIDO2: Using libfido2 for assertion webauthncli/api.go:183
2024-11-19T16:18:19+01:00 DEBU             FIDO2: assertion: passwordless=false, uv=false, 3 allowed credentials webauthncli/fido2.go:168

ERROR REPORT:
Original Error: *errors.errorString no security keys found
Stack Trace:
	github.com/gravitational/teleport/lib/auth/webauthncli/fido2.go:667 github.com/gravitational/teleport/lib/auth/webauthncli.runOnFIDO2Devices
	github.com/gravitational/teleport/lib/auth/webauthncli/fido2.go:274 github.com/gravitational/teleport/lib/auth/webauthncli.fido2Login
	github.com/gravitational/teleport/lib/auth/webauthncli/fido2_common.go:50 github.com/gravitational/teleport/lib/auth/webauthncli.FIDO2Login
	github.com/gravitational/teleport/lib/auth/webauthncli/api.go:184 github.com/gravitational/teleport/lib/auth/webauthncli.crossPlatformLogin
	github.com/gravitational/teleport/lib/auth/webauthncli/api.go:175 github.com/gravitational/teleport/lib/auth/webauthncli.Login
	github.com/gravitational/teleport/lib/client/mfa/cli.go:248 github.com/gravitational/teleport/lib/client/mfa.(*CLIPrompt).promptWebauthn
	github.com/gravitational/teleport/lib/client/mfa/cli.go:202 github.com/gravitational/teleport/lib/client/mfa.(*CLIPrompt).Run
	github.com/gravitational/teleport/[email protected]/mfa/ceremony.go:113 github.com/gravitational/teleport/api/mfa.(*Ceremony).Run
	github.com/gravitational/teleport/lib/client/weblogin.go:727 github.com/gravitational/teleport/lib/client.SSHAgentMFALogin
	github.com/gravitational/teleport/lib/client/api.go:4085 github.com/gravitational/teleport/lib/client.(*TeleportClient).localLogin
	github.com/gravitational/teleport/lib/client/api.go:3681 github.com/gravitational/teleport/lib/client.(*TeleportClient).getSSHLoginFunc.func2
	github.com/gravitational/teleport/lib/client/api.go:3873 github.com/gravitational/teleport/lib/client.(*TeleportClient).SSHLogin.func1
	github.com/gravitational/teleport/lib/client/api.go:3926 github.com/gravitational/teleport/lib/client.(*TeleportClient).loginWithHardwareKeyRetry
	github.com/gravitational/teleport/lib/client/api.go:3871 github.com/gravitational/teleport/lib/client.(*TeleportClient).SSHLogin
	github.com/gravitational/teleport/lib/client/api.go:3461 github.com/gravitational/teleport/lib/client.(*TeleportClient).Login
	github.com/gravitational/teleport/tool/tsh/common/tsh.go:2045 github.com/gravitational/teleport/tool/tsh/common.onLogin
	github.com/gravitational/teleport/tool/tsh/common/tsh.go:1512 github.com/gravitational/teleport/tool/tsh/common.Run
	github.com/gravitational/teleport/tool/tsh/common/tsh.go:627 github.com/gravitational/teleport/tool/tsh/common.Main
	github.com/gravitational/teleport/tool/tsh/main.go:26 main.main
	runtime/proc.go:272 runtime.main
	runtime/asm_arm64.s:1223 runtime.goexit
User Message: no security keys found

Connect behaves no differently – the Webauthn goroutine fails immediately too, but the Electron app keeps showing the modal asking you to insert a key. After you insert it, you'd expect to be able to tap it, but at this point tshd is not requesting a key tap. So you have to cancel the modal manually.

That behavior is a bit more acceptable for second_factor: "on" where in theory even if the Webauthn goroutine fails, the user is still able to change the MFA type to TOTP and enter a code. But even in this case we don't reflect the fact that Webauthn is not going to work unless you close the modal, insert the key and perform the action again.

The proper fix: wait for a key to be inserted

This would require adjusting the tsh code so that it waits for a key to be inserted. This is how most hardware key prompt implementations work, e.g., the one in Chrome, Safari, or Windows.

At this point it's not clear how much effort this would require.

The quick fix: don't ask for key insertion and fail immediately

This is what Teleport Connect v16.0.0 used to do. I haven't checked this, but I suspect the regression was introduced in #47153 when we switched to a two-step login flow. In the old flow, you'd select your MFA type first and only then submit the login form. In the new flow, you send your credentials first and then Connect shows the same MFA modal it shows everywhere else. The fact that the Webauthn goroutine failure doesn't cause an error is likely related to how we handle the scenario where multiple MFA types are available (webauthn + totp).

On platforms where we don't wait for key insertion (TODO: check if it's just macOS or Linux too) we shouldn't ask for key insertion in the modal, it should say just "Tap your security key". If the Webauthn goroutine fails and there's no other goroutine to wait for (e.g., TOTP), the modal should show an error.

[ravicious]

@codingllama This doesn't have a huge priority at the moment, but off the top do you head do you know what would it take to implement waiting for key insertion in tsh MFA?

[codingllama]

We've gone back and forth between waiting for key insertion or not over time - last time this was removed it was a refactor of mine. We can do it, the cost is more complex code.

I can also confirm that this will happen for tsh in both macOS and Linux, as they use the same WebAuthn client-side logic. On Windows we use system APIs, that's why they behave differently.