Yubikey error blocks using Teleport Connect

[stevenGravy]

Expected behavior:

An error would allow dismissing the issue or at least give further information.

Current behavior:

After upgrading to 13.3.1 experiencing a lockout to access any functionality. Had to remove the user data directory. I have backed up the user data dir. Putting it back in the error is repeated.

Bug details:

• Teleport version: 13.3.1
• Recreation steps

I don't know exactly what's causing this. I can share the data dir which repeatedly causes this.

[gzdunek]

The problem happens because we have Storage.ReadAll() in StartHeadlessWatchers() which is called during the app initialization. Storage.ReadAll() returns an error when ybukiey is not connected. We should catch this error instead of crashing the app.

The workaround is to have yubikey connected when starting the app.

[ravicious]

@stevenGravy Do you use hardware-based private keys?

@gzdunek What should we do after catching the error? Storage.ReadAll is mostly used to get the list of all profiles on startup, which lets us see which profiles have valid keys and which require login. I suppose in this situation we could consider the profile to not have a valid key and force the user to log in again?

@Joerger Do you know what's the state of hardware-based PK support in Connect? I looked at RFD 80 and it seems like Connect supports only the login happy path and ssh, but no db proxies, right?

[gzdunek]

@gzdunek What should we do after catching the error? Storage.ReadAll is mostly used to get the list of all profiles on startup, which lets us see which profiles have valid keys and which require login. I suppose in this situation we could consider the profile to not have a valid key and force the user to log in again?

Yes, it seems to me that it should work this way, when the user tries to interact with that profile, they will be prompted to log in again (as usual).

[stevenGravy]

@stevenGravy Do you use hardware-based private keys?

@gzdunek What should we do after catching the error? Storage.ReadAll is mostly used to get the list of all profiles on startup, which lets us see which profiles have valid keys and which require login. I suppose in this situation we could consider the profile to not have a valid key and force the user to log in again?

@Joerger Do you know what's the state of hardware-based PK support in Connect? I looked at RFD 80 and it seems like Connect supports only the login happy path and ssh, but no db proxies, right?

I had been trying hardware based keys for a period. I had taken it off the user's roles at one point.

[zmb3]

@ravicious @Joerger can we close this as a duplicate of #34415?

[Joerger]

@zmb3 This is separate - We need to add some UX improvements here when the user removes the yubikey where their private key is stored. The user should be prompted with a better error message to either log out or connect their yubikey and retry.