Unable to authenticate using cli

Boundary
1

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
2

Can you try installing gnome-keyring?

sudo apt install gnome-keyring

1 Like
3

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

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)

4

I think it’s because of your system. It works for me (Ubuntu 20.04).

5

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 which states;

" Linux

The Linux implementation depends on the Secret Service dbus interface, which is provided by GNOME Keyring.

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:"

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

6

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 :

…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

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…

1 Like
7

Wanted to point you all to 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.