borg not accepting passphrase (keyfile blake2)

[exlumine]

Have you checked borgbackup docs, FAQ, and open GitHub issues?

Yes. Neither the documentation, nor FAQ, nor existing issues match my problem.

Is this a BUG / ISSUE report or a QUESTION?

Mainly a questions, but it may become a bug.

System information. For client/server mode post info for both machines.

Your borg version (borg -V).

borg 1.2.7

Operating system (distribution) and version.

The backups were done on Archlinux (fresh update). I tried to access via Debian 12 (fresh install) and currently try a Fedora 39 (fresh install).

Hardware / network configuration, and filesystems used.

Local machine: Lenovo X230, cable connection to remote SMB share. X230 uses ext4. Remote machine: Synology DS414j with dedicated SMB share for the X230 backup. SMB Share uses ext4.

How much data is handled by borg?

Raw data to backup was approx. 0.3-0.4 TB.

In the past, a performed regularly borg prune as well as every 2-3 months a borg check --verify. borg check always ended silent/ without errors.

Full borg commandline that lead to the problem (leave away excludes and passwords)

Any command to access the remote archive fails due to "exceeded maximum password retries". borg list path/to/repo borg info path/to/repo

Describe the problem you're observing.

After my old SSD died, I tried to access my remote backup (keyfile, blake2). Therefore, I used a print of the keyfile (base64; direct print of the original keyfile) and typed it in a new file. I named that file according to the old keyfile and put it into the .config/borg/keys folder. I am pretty sure that the typed key is correct: I typed it 2 times in different files, checked each against the printout and performed a diff on the files, no deviations.

The password of the original keyfile was not changed in the past. I am also pretty sure that I typed the passphrase correct. I even tried to change between DE and US keyboard layout.

Each try ends in 3 times entering the passphrase and receiving the message "exceeded the maximum password retries".

That is, I currently am not able to access my backup with the keyfile and the passphrase.

Can you reproduce the problem? If so, describe how. If not, describe troubleshooting steps you took before opening the issue.

Yes, happend under Debian, happens under Fedora.

Include any warning/errors/backtraces from the system logs

There are no error messages or backtraces.

[ThomasWaldmann]

The behaviour of borg you see usually happens if the passphrase is wrong, that's why it asks again and again.

Can you please at least show the first 2 lines and the last line of the keyfile contents? Also the file size.

You may leave out the middle part (the key is encrypted, so if you have a good passphrase, there is no risk in publishing it completely. but as I am only interested in the format of the file, these 3 lines should be enough for me to see for now).

I also need the "id" line from the repo_dir/config file.

[ThomasWaldmann]

BTW, borg key export --qr-html ... offers a printable version that includes a QR code and also checksums for manually typing it in, so that might be easier and more fail-safe to use than the direct keyfile printout you used.

But in the end, the only thing that counts is that the keyfile contents and the passphrase are both correct for that repo (and that you put it into .config/borg/keys/ as you did).

[exlumine]

Here the ID in the repo file (at the mounted SMB share /mnt/backup/x230/config):

id = f91b51be33cf562b999242874c364ff825295ecd4c30c526607da6e21d3ffca5

And here the snippet from my keyfile (at ~/.config/borg/keys/mnt_x230):

BORG_KEY f91b51be33cf562b999242874c364ff825295ecd4c30c526607da6e21d3ffca5
hqlhbGdvcml0aG2mc2hhMjU2pGRhdGHaAZ4jaAW7B3BQeG1rK3RLHtibk1JwVswOt0tZFY
favDNTZGv9aVQfNElseJ32F+OIvc2Wsz5ghPC2hlVhMymoNz+qEOTordwBzEG3swtt1jQO
naL8MXuDvmveolpknB9Re2dVoxX/q7mimCOSg8G8WcksQD3WM7WYu2TVvjLWC2PFIDEHm/
[...3 lines deleted...]
ZvUbR3cUP8YBEY1CbBBWbHA6MAyw+/i2Y2Mb5cDaTmo0JjwRLfRToVbxHyxofVcTWtr/hP
OBzhHEanmwi53c43njixkXLtoeJ1WwI4NYyE0rgChOj61Az9VJYc9/hnkLhg081UAs60Xn
8QPAxaEeSBoY/75RehZOXMrt5dSkaGFzaNoAIOShVlOm9FQvY/hUTWzBWFn/1KBk6AVmwQ
knTUUI4Jt9qml0ZXJhdGlvbnPOAAGGoKRzYWx02gAgUAhX1319FFlO/Zi1D7ZSGIQQz3qW
a2zac49aXy01iVWndmVyc2lvbgE=

The keyfile has a size of:

~$ ls -l .config/borg/keys/mnt_x230 
-rw-------. 1 exlumine exlumine 813  5. Jan 14:45 .config/borg/keys/mnt_x230

[ThomasWaldmann]

OK, the format of the key file looks correct and the id matches the repo id. Also line count and file size looks good.

Please check that there is only one (correct) key file for this repo id:

grep f91b51be33cf562b999242874c364ff825295ecd4c30c526607da6e21d3ffca5 ~/.config/borg/keys/*

Also make sure the key file is inside the correct home directory, especially if you use sudo.

When borg ask for the key passphrase, it tells you the key path. Check if that path is the file you were creating/editing.

As you typed in the file contents, please check if you confused some chars. Use a good font, so you can better see differences, like e.g.:

• O vs 0
• 1 vs l
• ...

The easiest way I could reproduce your issue is by changing 1 char in the key blob.

[exlumine]

Grep confirmed 1 keyfile for this ID:

exlumine@localhost-live:~/.config/borg/keys$ grep f91b51be33cf562b999242874c364ff825295ecd4c30c526607da6e21d3ffca5 ~/.config/borg/keys/*
/home/exlumine/.config/borg/keys/mnt_x230:BORG_KEY f91b51be33cf562b999242874c364ff825295ecd4c30c526607da6e21d3ffca5

To detect any character confusion I checked as discribed above (typing into 2 seperate files, check each of them against the paper, and perform a diff of those two files). Unfortunately, I cannot bolster my claim by a checksum.

When using borg list <repo>, the correct keyfile is challenged:

exlumine@localhost-live:~/.config/borg/keys$ borg list /mnt/backup/x230/
Enter passphrase for key /home/exlumine/.config/borg/keys/mnt_x230: 
Enter passphrase for key /home/exlumine/.config/borg/keys/mnt_x230: 
Enter passphrase for key /home/exlumine/.config/borg/keys/mnt_x230: 
exceeded the maximum password retries

[ThomasWaldmann]

The easiest explanation is that you consistently misread your printout, so both key files contain the same typo(s). Check the easy to confuse chars.

[ThomasWaldmann]

Guess it won't help, but with this patch you can see the unpacked encrypted key data.

Due to the way how it works, it can not tell you which of passphrase or key is wrong.

diff --git a/src/borg/crypto/key.py b/src/borg/crypto/key.py
index 36855198..9ad67e8a 100644
--- a/src/borg/crypto/key.py
+++ b/src/borg/crypto/key.py
@@ -710,6 +710,7 @@ def decrypt_key_file(self, data, passphrase):
         unpacker = get_limited_unpacker('key')
         unpacker.feed(data)
         data = unpacker.unpack()
+        print(f"encrypted borg key data: {data!r}")
         enc_key = EncryptedKey(internal_dict=data)
         if enc_key.version != 1:
             raise Error("encrypted key version %d is not supported by this borg version." % enc_key.version)
@@ -719,6 +720,8 @@ def decrypt_key_file(self, data, passphrase):
         data = AES(key, b'\0'*16).decrypt(enc_key.data)
         if hmac.compare_digest(hmac_sha256(key, data), enc_key.hash):
             return data
+        else:
+            print("hmac.compare_digest failed, borg key or borg passphrase wrong!")
 
     def encrypt_key_file(self, data, passphrase):
         salt = os.urandom(32)

BTW, it is expected that it spills out one key decryption attempt before asking for a passphrase.

[ThomasWaldmann]

Any news?

[exlumine]

Not yet, still playing the permutation game. As I will be busy the next days, i will try to switch characters in the key via script but need to think that approach through first. Thanks for the hints and care so far, Thomas, i will come back to this threat when I have a clearer picture.

FYI: the patch works, I removed the fedora packaged borg version and installed a virtual env version which then received your patch.

[exlumine]

Hi Thomas,

you were right, I was wrong. Wrong in 2 places of the key (switch between 1 and l).

That is, I close this thread as it was not a bug. I've got my backup archive back and running.

Thank your for the support and keep up the good work. :)

Best

[exlumine]

Issue was not a bug, key file was wrong. Corrected key file did work properly as intended.

[ThomasWaldmann]

@exlumine Did you now use the "paper" key export? That should avoid such trouble.

[exlumine]

Sure. First thing when I had my key back... after reading the manual more carefully than the first time.