atuin sync: thread 'main' panicked at 'failed to decrypt history! check your key: could not encrypt #1199
Comments
|
I am having the same issue. I have also double checked the following values. As well as logging out and manually logging in using the same details on my local machine (which works and is running Arch) and the remote machine. I'm trying to run atuin on 20.04.6 LTS (Focal Fossa) Here is a backtrace. I am deploying atuin using Ansible so I can sync up multiple devices here - https://github.com/LiamAEdwards/Deploying-Atuin-Ansible |
|
I am having this issue as well. |
|
Me as well. Been this way for a pretty long time actually. My rust is really rusty so I dunno...Hopefully somebody can help here. |
|
I've been hitting this persistently for months as well across several versions now. I've been hacking around in the code dumping ciphertexts and keys and trying to get more info to no avail. Almost any pairing of 2 machines I've tried synchronize fine, any of several thirds I've tried to mix it fail with this sync error even after successfully authenticating and showing identical keys. |
|
Would love to see a fix for this as it's effectively stopped me using Atuin on more than one device. |
|
So this isn't an error related to the session. That's just your auth with the sync server and nothing to do with encryption Does the output of "atuin key" match across all machines? What's the output of "atuin status"? If any machine has ever had a key with a typo or similar and uploaded invalid history, you'll need to recreate you account Otherwise maybe try copying the ~/.local/share/atuin/key file to a new machine Our key management currently relies on the user and has no server side checks. we're addressing it in a new version of sync, but that's a rather large change and taking a while |
|
Will get back to you on that, not currently at the devices I was using at the time but last time I checked
By that do you mean recreate the account for the device that uploaded invalid history? What makes invalid history? I'll try copying and taking a look again, it's been a while. Thank you again for looking in at this :) |
|
Chiming in as well, tested via OpenSUSE TW repos, cargo install, and nixpkgs.atuin, same error, first it was the fact it wasn't in base64 and after creating that I put the key in a txt file in the same location on both computers, and still says can't encrypt when running atuin sync |
What happens if you set your key by copying the output of "atuin key" from another machine and pasting it in when "atuin login" asks you to? There are so many things that can go wrong if you're messing with the key file manually. Otherwise it would be ok to directly copy it across machines |
Nothing different, I've tried this several times including again just now. Whether the key comes from a copied file or pasting the output of
I've tried this too. I ran into the 3 system issue right away and immediately though must hove done something wrong, so I deleted my account from the server, nuked all local keys, sessions, and dbs and started again. I ran into the same problem again even though the second time through I was using two-out-of-three different systems. In the end I just started using it with 2 systems working and now I'm fairly invested in having a large history that I can use in predictable ways.
From one of the working 2 machines it looks like this: $ atuin status
[Local]
Sync frequency: 10m
Last sync: 2023-10-10 06:10:09.918222001 UTC
History count: 57565
[Remote]
Address: https://api.atuin.sh
Username: alerque
History count: 57641From a machine failing to sync, it looks more like this: $ atuin status
Sync frequency: 10m
Last sync: 1970-01-01 00:00:00 UTC
History count: 15618
[Remote]
Address: https://api.atuin.sh
Username: alerque
History count: 57641Both systems have the same key/session, as can be verified with the checksums being identical: $ sha256sum ~/.local/share/atuin/{key,session}
93e0bbd38ef66a9603c5da4b303b9b31c439c62f656c5141f1740004fec2cf98 /home/caleb/.local/share/atuin/key
b46e1c2c1b32506c06245346a0e84c6fffa30f393f0b9e948a4c0f3893c584b0 /home/caleb/.local/share/atuin/session |
|
Very strange. Sorry for the trouble. I'll make a branch with some testing ideas later today, if you're OK with installing it and trying it out? I've had to debug this once before for myself - in my case I had messed up the encoding while testing and had a few entries that were not decodable with later code We have a new implementation of sync on the way which should fix all of these problems for good |
|
Sure. I can build and test from a branch with any debug info that interests you. I currently have access to both working and failing machines. |
That's what I've been doing, I've been sending it over with syncthing and moving it another location I've defined in the config, just in case there's any sync errors |
I experienced similar situation too. ➜ ~ $ system_profiler SPHardwareDataType | grep "Model Identifier"
Model Identifier: MacBookPro16,1
➜ ~ $ sha256sum ~/.local/share/atuin/{key,session}
ffd420ca24b08716089f4c971f543ca89066b34d03f4e390fd53813cb436e0ee /Users/lssl/.local/share/atuin/key
caa8d00ba49fe131bf3cbf05b7f1b53da9b134e1528fc34ba00ab58e18d58e6c /Users/lssl/.local/share/atuin/session
➜ ~ $ atuin status
[Local]
Sync frequency: 10m
Last sync: 2023-10-11 20:34:24.971731 UTC
History count: 23774
[Remote]
Address: https://api.atuin.sh
Username: sheeeng
History count: 23909
➜ ~ $ atuin sync
0/0 up/down to record store
Sync complete! 23775 items in history database, force: false
➜ ~ $➜ ~ hostname
eb840
➜ ~ sha256sum ~/.local/share/atuin/{key,session}
ffd420ca24b08716089f4c971f543ca89066b34d03f4e390fd53813cb436e0ee /home/leonard/.local/share/atuin/key
caa8d00ba49fe131bf3cbf05b7f1b53da9b134e1528fc34ba00ab58e18d58e6c /home/leonard/.local/share/atuin/session
➜ ~ atuin status
[Local]
Sync frequency: 10m
Last sync: 1970-01-01 00:00:00 UTC
History count: 4434
[Remote]
Address: https://api.atuin.sh/
Username: sheeeng
History count: 23909
➜ ~ atuin sync
0/0 up/down to record store
thread 'main' panicked at 'failed to decrypt history! check your key: could not encrypt
Location:
/home/leonard/.cargo/registry/src/index.crates.io-6f17d22bba15001f/atuin-client-16.0.0/src/encryption.rs:132:22', /home/leonard/.cargo/registry/src/index.crates.io-6f17d22bba15001f/atuin-client-16.0.0/src/sync.rs:74:38
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
➜ ~ |
|
I'm having the same issue: Same trace, checked/tried/verified pretty much everything like the others did, BUT then I discovered something that's maybe related (or maybe it's a completely separate issue): I installed v16.0.0 on three computers and connected all three instances to a self-hosted Atuin server ( PS: On an |
|
@saturated-white could you try running your server with It's not going to be an auth-related issue, but could potentially be related to a server side response |
|
Sure @ellie! - Due to its size I added it as attachment: atuin-server_PLAIN.log Likely it's self explanatory, but just in case, I did following:
UPDATE: Since I did not spot anything suspicious in my server log file, I tried the following: I checked the But now I have a new problem: When a computer tries to upload a newly entered command to the server, the server receives: Noteworthy side-effects:
PS: I backed up the original history table, if anybody needs me to debug anything further on it. |
|
The order, in which one syncs their devices (for the first time) seemed to fix this issue. A total of three devices of mine were involved, one of which synced fine, two of which threw the same error. |
I found it's the order problem too. |
|
Have you got any examples of ordering that does/doesn't work? 🤔 Fwiw, I'm totally reworking sync in #1400, which will be opt-in for v18. It should be much, much less sensitive to this kind of thing 🙏 |
|
If anyone experiencing this issue could try the new sync, released as opt-in for v18, that would be great! Requirements
Setup
[sync]
records = true
At any time, run You will need to repeat these steps for every machine running Atuin TroubleshootingIf you run into any error about keys with the new sync, please run More info: https://forum.atuin.sh/t/sync-v2-testing/124 |
|
I've just migrated most of my hosts. Migration for me is a bit complicated because for a long time now I've been coping with the inability to connect more that 2 hosts by cheating hard: I have 2 host ids that I clone between machines and all my systems were self-identifying as one of those two hosts (the closest match of server vs. workstation so the "HOST" filtering had some limited usefulness). This has been working to get quite a few machines in sync, but obviously to actually test if this is working I needed to untangle that. I've kept 1 system each from the two host ids and blown the rest away, then restored the key file only, then logged in and synced again. So far I have 4 hosts hooked up and migrated to the v2 records. I actually have 4 hosts identified in the store status now as well as all the old history. This is better than I've ever been able to accomplish before v18 + v2 records. |
|
Ouch, I spoke too soon. I just ran into the error again connecting a 5th host having wiped out its previous local data. The login went fine, but the first sync threw a decrypt error again. Worse it has propagated to other hosts, the first sync from all the other 4 after that 5th host connected threw the error too. Different from my experiences with v17 however, subsequent syncs are not throwing the error. Verifying the store however does still panic: $ atuin store verify
Verifying local store can be decrypted with the current key
Failed to verify local store encryption: attempting to decrypt with incorrect key. currently using k4.lid.GjxE3O4OsA9asnqMkJmYl8vxDlqYl9AjxQ_gPZOwqvx8, expecting k4.lid.Cuot1SH3Y0Nk1VwBklmcvm8qJ9q8LSNpjcVrFzEUWC3g
Location:
atuin-client/src/record/encryption.rs:132:9The 5th host that I initially tried to sync currently succeeds in syncing, but |
Glad it got this far. Fwiw, the hostid used for the store does not have any relation to what's within the history itself. I've tried to decouple the two as much as possible to reduce brittleness.
Afaik this occurs with one of two things, seen by the kids shown
Once you've verified that all keys on all machines are correct, you can resolve the error with the following operations. It'll make life easier if you disable auto_sync temporarily. To be extra safe, make a copy of
The idea in the recovery there is to correct the store on one machine, and then ensure that all others match it. While it does delete data, it only deletes data that cannot be decrypted. |
|
Thanks for the walk through on the purge process. That right there seems to be the missing magic to recover from bad scenarios that v1 sync never had. I now have 5 machines all connected with the purged record based history and their stores verify. Somewhat to my confusion In any event at least for my problematic cases there is now a way out to a clean usage with the record based store. 💯 |
|
No worries! Happy to hear that sorted it for you.
There's a ~/.local/share/atuin/host_id file that tracks the ID, so you cleaning up some cloned hosts might have caused it. There's not currently a way to clean it up, but I am planning on making the output of the status command a bit neater so it is less likely to be confusing. |
|
Thank you @ellie! - The new opt-in syncing algorithm in v18 solved the issue for me. |
|
Great! Glad it worked for you. Seems like this fixed it for a bunch of people, so I'll close this issue |
Experienced the following error when I run
atuin sync.I have double checked the following values.
cat ~/.local/share/atuin/sessionhas the same value between two separate system.echo $ATUIN_SESSIONhas different value between two separate system.I have tried
atuin logoutandatuin login -u "${ATUIN_USERNAME}" -p "${ATUIN_PASSWORD}" -k "${ATUIN_KEY}"again on the same that has this issue, but to no avail.How we can further troubleshooting this issue?
The text was updated successfully, but these errors were encountered: