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

failure to authenticate error when attempting to log in via cli w/ access workflows after removing .tsh directory #5316

Closed
deusxanima opened this issue Jan 15, 2021 · 0 comments · Fixed by #5323

Comments

@deusxanima
Copy link
Contributor

Description

What happened:

If access workflows are enabled and a user on a mac removes their .tsh directory before issuing a login command similar to tsh login --proxy=proxy.example.com --request-reason=testing --ttl=2 --auth=auth0 without specifying a user with the --user flag, they encounter the following error:

User Message: failed to authenticate with proxy proxy.example.com:3023

Rerunning the same command again does not trigger the error.

This only happens when using access workflow flags (either request-roles or request-reason) AND the .tsh directory is removed. It only happens the first time the user attempts to authenticate that way after removing the directory.

What you expected to happen:

User should be able to log in without having to explicitly set the --user flag the first time after removing the .tsh directory like they can when access workflows are not involved.

How to reproduce it (as minimally and precisely as possible):

  1. run rm -r ~/.tsh on a mac
  2. Issue following command when access workflows are enabled: `tsh login --proxy=proxy.example.com --request-reason=testing --ttl=2 --auth=auth0' (also repeatable with --request-roles and any auth connector)
  3. Observe error and no request token generated even though browser will show a successful Login redirect.
  4. Issue same command again.
  5. Observe request token generated and login successful after approval.

trying the same thing with tsh login --proxy=proxy.example.com --request-reason=testing --ttl=2 --auth=auth0 [email protected] does not trigger the error.

Environment

  • Teleport version (use teleport version): 4.4 and 5.0
  • Tsh version (use tsh version): 4.4. and 5.0
  • OS (e.g. from /etc/os-release): OSX

Relevant Debug Logs If Applicable

Logs from Mac on unsuccessful login:

DEBU [KEYSTORE]  Returning SSH certificate "/Users/user/.tsh/keys/proxy.example.com/[email protected]" valid until "2021-01-15 13:14:43 -0500 EST", TLS certificate "/Users/user/.tsh/keys/proxy.example.com/[email protected]" valid until "2021-01-15 18:14:43 +0000 UTC". client/keystore.go:319
DEBU [CLIENT]    Client  is connecting to auth server on cluster "ip-192-168-1-1-ec2-internal". client/client.go:473
INFO [CLIENT]    no host login given. defaulting to user client/api.go:801
INFO [CLIENT]    [KEY AGENT] Connected to the system agent: "/private/tmp/com.apple.launchd.ucd29VQBE6/Listeners" client/api.go:2282
ERRO [KEYSTORE]  open /Users/user/.tsh/keys/proxy.example.com/user-cert.pub: no such file or directory client/keystore.go:253

Logs from Mac on successful login:

DEBU [KEYSTORE]  Returning SSH certificate "/Users/user/.tsh/keys/proxy.example.com/[email protected]" valid until "2021-01-15 13:12:25 -0500 EST", TLS certificate "/Users/user/.tsh/keys/proxy.example.com/[email protected]" valid until "2021-01-15 18:12:25 +0000 UTC". client/keystore.go:319
DEBU [CLIENT]    Client  is connecting to auth server on cluster "ip-192-168-1-1-ec2-internal". client/client.go:473
INFO [CLIENT]    no host login given. defaulting to user client/api.go:801
INFO [CLIENT]    [KEY AGENT] Connected to the system agent: "/private/tmp/com.apple.launchd.ucd29VQBE6/Listeners" client/api.go:2282
DEBU [KEYSTORE]  Returning SSH certificate "/Users/user/.tsh/keys/proxy.example.com/[email protected]" valid until "2021-01-15 13:12:25 -0500 EST", TLS certificate "/Users/user/.tsh/keys/proxy.example.com/[email protected]" valid until "2021-01-15 18:12:25 +0000 UTC". client/keystore.go:319
INFO [KEYAGENT]  Loading key for "[email protected]" client/keyagent.go:147
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants