Subcommand to verify login status

[weichuliu]

Hi,

I am trying to find a command to understand the current keeper login status.

Likely keeper (some commands) returns 0 when the cli is logged in, and returns 1 otherwise.

However, when logged out, keeper with any subcommand will get into interactive mode and try to ask for User(Email):. So the whole script get stuck.

Is there a way to tell whether keeper is logged in without the cli attempting to wait for user input?

[sk-keeper]

There is no command that tells you if login will be interrupted with any prompt. It is not supported at the backend.
It is not clear why you got username prompt. Once you logged in the last username is stored into the config file config.json
You should not be asked for username.

[weichuliu]

Once you logged in the last username is stored into the config file config.json
You should not be asked for username.

Yes that is true. But I do want my script able to handle the situation when config.json does not exist i.e. the user haven't ever login.

But now if the config.json is not there, any keeper commands will pop a User(Email) and got stuck forever, which is not desirable.

[sk-keeper]

The login flow can prompt for user input up to 3 times

• device approval
• two factor authentication
• password
  It is not possible to use Commander in unattended mode in all situations.
  Keeper provides another API for services.
  https://docs.keeper.io/secrets-manager/secrets-manager/overview

[ebarrere]

We pay for KSM, but I would also very much like this functionality. There are situations where it simply does not apply, or using it would actually reduce overall security.

For instance, I would like the ability to pull arbitrary passwords from my vault to pass in to other scripts and systems. Using KSM for this would make every password in my vault accessible to anyone with read-access to the configuration file.

The Commander CLI already provides exactly what I need, with the major exception of login flow.

[maksimu]

@ebarrere

Just wanted to quickly clarify something about Keeper Secrets Manager (KSM) and Commander.

KSM is all about machine-to-machine communication. It's built for automated environments (like servers and CI/CD pipelines) where you need to handle secrets without manual input. This is why it uses a Zero-Knowledge encryption model and other features like local caching and IP lockdown.

Commander, on the other hand, is more user-focused and requires user interaction for managing secrets. It's great for individual use but not so much for automated processes.

[ebarrere]

@maksimu — thank you for the reply.

I understand that, but my point again is that KSM does not apply to my use cases (as you said it is more for machine-to-machine communication) yet the previous comment seems to imply this is the solution:

Keeper provides another API for services.
https://docs.keeper.io/secrets-manager/secrets-manager/overview

I would very much like the ability to use Commander to automate my own personal workflows, for which KSM does not apply.

[lancepants]

This feature would be very useful for the various local scripts that users use to perform daily tasks which require password retrieval.