Any downside of using the same credentials in a few workstations?

Hi everyone:

I’ve been a happy user for a long time :smiley: . A few months ago (before the dotfiles features were released) I started using chezmoi for syncing stuff.

One of the things I use the most with chezmoi is that I can run scripts the first time I pull the dotfiles so I haven’t been able to migrate because of that.

Anyway, so I have a few machines syncing to my Atuin server and everything is amazing. However, I feel like I’m losing data because I have VMs that I use for particular things that are “disposable”. So I don’t want to clutter my instance with many devices.

I was wondering if it would be possible to create a “generic” device on my Atuin server and share those credentials among those disposable environments. Will stuff get corrupted or will I lose data if I do that?

TL;DR: Can I sync the ~/.local/atuin/key to many devices so that I don’t have to authenticate in disposable environments?

Thanks for reading :slight_smile:

1 Like


I’m not 100% sure I’ve understood the question correctly, but there’s no reason you can’t sync 1000+ machines. If you run into any performance issues please do get in touch

Having a bunch of very short-lived machines will only really increase the sync index size - this isn’t very large anyway, and still has plenty of room for optimisation if we run into trouble.

A single generic device is likely to cause issues, because sync works on the premise that each host is the only machine writing for a given host ID - as soon as we have multiple machines writing to the same host ID, weird things could happen

Hi @ellie

That’s what I thought. You understood the idea perfectly. I just wanted to sync the “generic” host ID to my transient VMs so that I didn’t have to authenticate manually each time to my Atuin local server every time I boot up a disposable VM.

I’ll see if I can come up with a workaround. I’ll try to use Bitwarden-cli to get the creds without having to type them.

would you like me to write a bash script to do this?

Hi @AtomicRobotMan0101

Thanks! I just forgot to share what I ended up using. I didn’t like bitwarden-cli, so I ended up using rbw instead:

login_atuin() {
    # Check if 'atuin' is available on the path
    if ! command -v atuin &> /dev/null; then
        echo "Error: 'atuin' command is not installed or not found in PATH."
        return 1
    # Retrieve credentials from Bitwarden
    local username=$(rbw get "atuin" --field=username)
    local password=$(rbw get "atuin" --field=password)
    local key=$(rbw get "atuin" --field=notes)  # Assuming 'notes' field contains the key
    # Check for empty values and prompt error if any
    if [[ -z "$username" || -z "$password" || -z "$key" ]]; then
        echo "Error: Missing credentials. Please ensure all fields are retrieved correctly."
        return 1
    # Execute the atuin login command with the retrieved credentials
    atuin login -u "$username" -p "$password" -k "$key"

If you have any suggestions, I’d love to hear them though :slight_smile:

1 Like

I love these hidden gems. What an excellent project. Bookmarked!

I was thinking was of taking the bitwarden creds and registering a new machine as part of an Atuin setup script.

Essentially, a tool that will take the username/password and register to create some new HostIDs.

IDEA - what if we:

  • Script up a “pre-register” tool which manufactures a bunch of keys/HostIDs (25? 100?)
  • It pops them into little local SQLite DB
  • All synced with new machines via SyncThing
  • A new VM setup process (e.g. Ansible, or just my usual bastardised hacks/bash) would simply read the next available key, mark it used, copy the needed files to places…

and presto, working VM with Atuin.

No doubt @ellie will spew at us generating 100 keys :slight_smile: (it will look like an attack!)

So hosts are never registered, records just also have a host ID. There’s not need to pre-register anything, you just start using a new ID and it works just fine. Every time you install and setup atuin, a new host ID is generated. Even if you never register for sync.

In addition, there’s one single encryption key for an entire account, so this approach will lead to sync not functioning. Otherwise users would need to handle as many keys as they have machines