Support headless environments without a secret service / keyring

[jrabensc]

sn-cli currently requires a secret service (e.g., GNOME Keyring, KWallet) to store credentials. This makes it difficult or impossible to use on headless servers where no desktop environment or D-Bus secret service is available.

Attempting to run sn-cli on a headless Linux server results in errors related to the missing keyring/secret service backend.

Suggested Solutions

• Config file with encryption
• Plaintext option with warning: Provide a --no-keyring flag that stores credentials in a local file (with appropriate file permissions), displaying a security warning

[jonhadfield]

Hi @jrabensc, by credentials, do you mean username/password for an account without a token, or a session and refresh token that can be used to access the account?

[jrabensc]

username/password using 2fa.

[jonhadfield]

The problem is that 2FA is TOTP, so would require storing the seed value (usually shown as a QR code during setup) in the credentials file (not ideal), and I'd have to write something to generate a token based on that seed value when you run the first command. From then on, you could use the session and refresh the session with the refresh token.

For M2M (Machine to Machine) you normally want some kind of auth flow that means something other than initial credentials are needed. I don't think there's anything on SN to support that.

You could simply add a session on your instance (using the cli) and then future commands would make use of that session?

[jrabensc]

The issue is that sncli login itself requires the secret service to store credentials. Without a keyring, you can't authenticate at all, so "just add a session" isn't possible on a headless machine.

How would you run the initial login on a headless server without a secret service available? A --session-file flag for the login command that writes directly to a file instead of the keyring would solve this.

[jonhadfield]

You should be able to set SN_EMAIL and SN_PASSWORD to handle authentication without 2FA.
The problem with 2FA is that it always wants to be interactive, i.e. ask for a TOTP number. The only solution would be for you to store username, password, and 2FA TOTP seed value. It's not an ideal scenario, but I'll see if I can add support.