Key management user experience

General
1

Lately we’ve been getting a lot of new users (awesome!), but also a growing number of users who end up with the wrong key on a new device.

Quick refresher on how Atuin handles this: we store your encrypted data, your username, and a hash of your password. The encryption key is entirely up to you. You’re responsible for keeping it safe (ideally in a password manager) and using it when you set up a new machine.

That said, I think parts of our setup UX don’t make this clear enough. I have some thoughts on how to improve things, but before jumping to solutions I’d love to hear from you:

  • What did you find confusing about install/setup, especially around key management?
  • Where do you store your key?
  • How do you transfer it between devices?

Any and all feedback is welcome, thank you in advance!

2

Nothing especially but I might not be a generic user since I’ve used Atuin for a while

In the default location

I transfer it using the Atuin key and copying/pasting it once I get it from a current device

it’d be nice if we had a way to verify a login from a current device and have it auto transfer the key though, although there may be security considerations I haven’t taken into account on thinking this

3

and Shell Integration - Atuin Documentation

‘’

ATUIN_SESSION Unique identifier for this shell session’

‘’

is confusing. session_path is a path to a file containing an API id tied to your account right?

4

I have installed atuin on a bunch of servers, 70+ at least.

I install it via chezmoi with a “run after” script, where I fetch the password and key from keyhole which is a password manager that uses your ssh key to access the secrets - very useful[1] for bootstrapping the “first secret”.

I have had some issues where the secret fetch failed, which I didn’t notice and a following sync botched the server-side copy with un-decryptable history entries, that then propagated to all my other servers at login due to auto sync.

I still experience this sometimes, when my script tries to login but the secret fetch fails.
Thanks to the new version the bad history no longer propagates but stays on the new host. If I run my login script a second time it succeeds, but now I already have a few history entries encrypted with a key I don’t have access to.

if atuin status &> /dev/null; then
    echo "Atuin is already logged in."
    atuin status
else
    echo "Atuin is not logged in. Logging in..."
    # Here I inspect hostnames to determine the correct username
    # I self-host and have different usernames for different environments
    export ATUIN_USERNAME="username"

    if [[ -n "$ATUIN_USERNAME" ]]; then
        ATUIN_PASSWORD="$(ssh -o StrictHostKeyChecking=accept-new keyhole.example.com get atuin/$ATUIN_USERNAME/password)"
        ATUIN_KEY="$(ssh -o StrictHostKeyChecking=accept-new keyhole.example.com get atuin/$ATUIN_USERNAME/key)"
        if [[ -z "$ATUIN_PASSWORD" || -z "$ATUIN_KEY" ]]; then
            echo "Failed to retrieve Atuin credentials - Skipping atuin login."
        else
            atuin login \
                --username "$ATUIN_USERNAME" \
                --password "$ATUIN_PASSWORD" \
                --key "$ATUIN_KEY"
        fi
    else
        echo "Unknown host type - Skipping atuin login."
    fi
fi

I believe this script should work, but I think that auto sync might try to sync without a propper key configured, which then leads to “bad history” when I do login with the correct key and password.

I have submitted a PR with a command atuin store repair that can repair the local history by either uploading readable history entries, or fetching history entries we have locally but can’t read.

I have used this on my own atuin server to successfully repair my history store.

A feature like what openconnect, has where you can login and supply your secrets on stdin would be most welcome, as my current way of logging in exposes the secrets in the process list for a brief period.

Something like echo "password\nkey" | atuin login --username user --stdin, then replace echo with your favourite secret manager.

  1. Full disclosure, I’m the author of Keyhole ↩︎

5

It is not really around key management, but for the beginning that ‘curl … | sh’ thing. This is frightening and definitely not something I’ll be willing to do. I would definitely like to have better documentation for manual installation. In the end I just copied one binary to somewhere in my path, but finding out this is all what is needed was not really trivial. After installation come also shell plugins and setup, but this is quite well documented.

Around key management few words about where and in what form the key is stored would be useful. I think the key is stored Base64 encoded in ~/.local/share/atuin/key (using default setup), but I didn’t find that well documented. Location is mentioned in default config.toml comments, Base64 appears in `atuin key —help`, but …

Recently I moved two of my accounts from one machine to another where the latter eventually replaced former one changing its name at that time, but they both lived for about a week in parallel. I am still not sure what is the best way to perform this regarding Atuin. What exactly is a host here (is this a hostname or more likely a “key” in ~/.local/share/atuin/host_id), what happens if hostname changes (to something which existed before on another system), what if host_id changes, can you run two systems with same host_id in parallel, … I miss these information in documentation.

In password manager.

Copy & paste from password manager or from another device.

Aleš