Run and Login to Boundary
To start Boundary in dev mode:
Login to Boundary
Boundary uses a predictable login name (admin
) and password (password
) in
dev mode. These can be overridden, or randomly generated, with flags to
boundary dev
.
If you are on Unix-like operating system (other than macOS/Darwin), you may get
an error indicating that the token could not be stored, as the freedesktop.org
Secret Service implementation is not always available. On these systems, you can
work around this by installing dbus-x11
and gnome-keyring
using your package
manager, then creating and unlocking the default keyring with the following,
substituting in a password of your choice for "foobar" (but ending with \n
).
You can also avoid putting the password on the command line by running the
gnome-keyring-daemon
commands directly and entering in the password, followed
by a newline (return) and an EOF (Ctrl+D
).
eval "$(printf 'foobar\n' | gnome-keyring-daemon --unlock)"
eval "$(printf 'foobar\n' | gnome-keyring-daemon --start)"
This would have to be run in each shell.
If you're unable to install these packages, or don't want to, you can tell the
Boundary authenticate command to not save the token to the operating system's
key manager by setting -token-name=none
flag or BOUNDARY_TOKEN_NAME=none
env
variable when running boundary authenticate
. You'll be responsible for setting
the token in subsequent commands via -token
flag or BOUNDARY_TOKEN
env
variable. An easy way to do this would be to use the -format=json
flag along
with jq
to pull the token value out of the response and place it wherever you
wish, then create a command alias for boundary
that sources that value into
the environment or the -token
flag.
Token storage on *nix systems has been more problematic than we expected. We're exploring alternatives. See the discussion on this GitHub issue to track it and voice your thoughts.
Next Steps
See connecting to your first target for how to use Boundary to run your first SSH session.