# Unable to authenticate using cli **URL:** \ **Category:** Boundary\ **Created:** [October 15, 2020, 9:25am UTC](https://discuss.hashicorp.com/t/unable-to-authenticate-using-cli/15778 "2020-10-15T09:25:31Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![junaidk](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/junaidk/32/13048_2.png) [@junaidk](https://discuss.hashicorp.com/u/junaidk)\ **Post date:** [October 15, 2020, 9:25am UTC](https://discuss.hashicorp.com/t/unable-to-authenticate-using-cli/15778/1 "2020-10-15T09:25:31Z")
Following getting started guide, when I try to authenticate I get some errors with authentication information. ``` Error reading auth token from system credential store: The name org.freedesktop.secrets was not provided by any .service files Authentication information: Account ID: apw_piahOowtIg Auth Method ID: ampw_1234567890 Expiration Time: Thu, 22 Oct 2020 09:18:27 UTC Token: at_XTZ16p14Dm_s13B8JPWw3tKjrriT7VVUe8wmtuj7fHPymWeiYPw13LR8zMfZyozqrDya9hjkV1ziVfMGXyAZdnpTLm8kJGHqQqPACaeSaXvGN7Xu2VDe15dc2h8zq User ID: u_1234567890 Error saving auth token to system credential store: The name org.freedesktop.secrets was not provided by any .service files ``` Subsequent boundary commands fail with Unauthenticated message. ``` Error reading auth token from system credential store: The name org.freedesktop.secrets was not provided by any .service files Error from controller when performing read on target: Error information: Code: Unauthenticated Message: Unauthenticated, or invalid token. Status: 401 ``` ---
**Author:** ![Wolfsrudel](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/wolfsrudel/32/28465_2.png) [@Wolfsrudel](https://discuss.hashicorp.com/u/Wolfsrudel)\ **Post date:** [October 15, 2020, 11:17am UTC](https://discuss.hashicorp.com/t/unable-to-authenticate-using-cli/15778/2 "2020-10-15T11:17:07Z")
Can you try installing `gnome-keyring`? `sudo apt install gnome-keyring` ---
**Author:** ![arashid290](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/arashid290/32/13062_2.png) [@arashid290](https://discuss.hashicorp.com/u/arashid290)\ **Post date:** [October 15, 2020, 11:41am UTC](https://discuss.hashicorp.com/t/unable-to-authenticate-using-cli/15778/3 "2020-10-15T11:41:08Z")
I noticed this behaviour if you do it in the same terminal as where you initially authenticated. For example, run ‘ **boundary connect ssh -target-id ttcp\_1234567890** ’ Then in the same terminal if you try to run the following: **boundary connect -exec curl -target-id ttcp\_1234567890 – -vvsL --output /dev/null [hashicorp.com](http://hashicorp.com)** I get the following output: Error reading auth token from system credential store: exit status 36 Error from controller when performing authorize-session against target: Error information: Code: Unauthenticated Message: Unauthenticated, or invalid token. Status: 401 If you open a new tab, then run the same command. It is fine. (This is on MacOS, Catalina, 10.15.6) ---
**Author:** ![Wolfsrudel](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/wolfsrudel/32/28465_2.png) [@Wolfsrudel](https://discuss.hashicorp.com/u/Wolfsrudel)\ **Post date:** [October 15, 2020, 11:47am UTC](https://discuss.hashicorp.com/t/unable-to-authenticate-using-cli/15778/4 "2020-10-15T11:47:34Z")
I think it’s because of your system. It works for me (Ubuntu 20.04). ---
**Author:** ![pentiumoverdrive](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/pentiumoverdrive/32/13085_2.png) [@pentiumoverdrive](https://discuss.hashicorp.com/u/pentiumoverdrive)\ **Post date:** [October 15, 2020, 2:45pm UTC](https://discuss.hashicorp.com/t/unable-to-authenticate-using-cli/15778/5 "2020-10-15T14:45:29Z")
Same on Centos 8 minimal, bloated gnome-keyring doesn’t help either, just more errors. Is there an undocumented dependency somewhere? When I ran vault sometime ago it just used to store the token into a file. Boundary works differently? Update: Checked the sourcecode and it implements this: [github.com/zalando/go-keyring](http://github.com/zalando/go-keyring) which states; " Linux The Linux implementation depends on the [Secret Service](https://specifications.freedesktop.org/secret-service/latest/) dbus interface, which is provided by [GNOME Keyring](https://wiki.gnome.org/Projects/GnomeKeyring). It’s expected that the default collection `login` exists in the keyring, because it’s the default in most distros. If it doesn’t exist, you can create it through the keyring frontend program [Seahorse](https://wiki.gnome.org/Apps/Seahorse):" I don’t think I have a “default collection” in centos, since gnome-keyring just gives “Error saving auth token to system credential store: failed to unlock correct collection ‘/org/freedesktop/secrets/aliases/default’”. A simple workaround seems to be to take your token and insert into an enviromnment var: **export BOUNDARY\_TOKEN=yourtoken** ---
**Author:** ![jeff](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/jeff/32/12882_2.png) [@jeff](https://discuss.hashicorp.com/u/jeff)\ **Post date:** [October 15, 2020, 3:25pm UTC](https://discuss.hashicorp.com/t/unable-to-authenticate-using-cli/15778/6 "2020-10-15T15:25:15Z")
Hi all, Sorry for confusion here. The Secret Service dbus interface is implemented by GNOME Keyring, Seahorse, KWallet, and others. I’m definitely wanting to figure out a better way to handle these errors – note that they don’t affect authentication, you got a token back! – but it’s a bit complicated to know the right thing to do. Pasting from myself from [404 attempting to authenticate · Issue #696 · hashicorp/boundary · GitHub](https://github.com/hashicorp/boundary/issues/696) : > …we thought about a Vault-style storing of the token in a local file as a backup method but over time we’ve had complaints around that approach from people that didn’t realize it was being stored in plaintext on disk. Since it’s relatively easy to make an alias that will store the token in a file for you on authentication and read it on other commands, or to send the token to some other preferred secrets mechanism we decided to leave it up to the user for the moment if the built-in integration isn’t working for them or is disabled. You can disable os credential storage by using `-token-name=none` at authentication time, and if you pass a token in directly via env var or `-token` to other calls we don’t attempt to look it up. We’re also working on getting some specific guides around helping you get set up once we figure out the right invocation – see [Issue with secrets storage on Ubuntu · Issue #697 · hashicorp/boundary · GitHub](https://github.com/hashicorp/boundary/issues/697) One thing that isn’t helping is that even on some machines with desktop environments installed, all of which have implementations of the secret service dbus service, some people are seeing this error. We’re still working through it… ---
**Author:** ![jeff](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/jeff/32/12882_2.png) [@jeff](https://discuss.hashicorp.com/u/jeff)\ **Post date:** [October 15, 2020, 4:42pm UTC](https://discuss.hashicorp.com/t/unable-to-authenticate-using-cli/15778/7 "2020-10-15T16:42:12Z")
Wanted to point you all to [https://github.com/hashicorp/boundary/issues/697#issuecomment-709448942](https://github.com/hashicorp/boundary/issues/697#issuecomment-709448942) for a potential solution and would like to hear feedback with respect to a potential alternative – please comment there to help keep comments together! One other thing relevant to (at least) the OP is that a change went into Boundary that it turns out _just barely didn’t make_ the 0.1 cutoff that causes a failure here to return a status code of 0 and a warning as opposed to a status code of 1. That will at least help with scripting workflows.