Open MEitelwein opened 5 years ago
Still not fixed upstream. I hit this again as some manually patched Debian servers reinstalled the old unpatched scripts when upgrading to Debian Buster 10.4
bump
edit: we need to be careful here, in my tests I noticed problems at the restore.
Any update on this? Encountering this in Amanda version 3.5.1.
one year gone, still no reply from the responsible maintainers
I have since stopped using Amanda and moved to Restic. But Amanda stays in a special place in my heart. :)
Who are the "responsible maintainers"?
Who are the "responsible maintainers"?
I don’t know who specifically, but I would assume anyone with commit access to this repo counts.
Had the same issue; and as of 1/1/2022 it is now important to be sogis.eu compliant (EU version of a lot of the NIST federal processing regulation) - filed https://github.com/zmanda/amanda/pull/165
Still patching manually on backup servers :-(
It can be corrected by adding -pbkdf2 to the amcrypt-ossl calls to openssl:
if [ "$1" = -d ]; then # decrypt "${OPENSSL}" enc -pbkdf2 -d "-${CIPHER}" -nopad -salt -pass fd:3 3< "${PASSPHRASE}" else # encrypt pad | "${OPENSSL}" enc -pbkdf2 -e "-${CIPHER}" -nopad -salt -pass fd:3 3< "${PASSPHRASE}" fi
Still facing these issues. Applied that patch on a debian 11.3 machine, running amdump gives me a "FAIL" run with:
[missing size line from sendbackup]
Anyone else seeing this, any better workaround?
I have replaced my encryption needs with:
# cat /etc/amanda/encrypt
#!/bin/bash
AMANDA_HOME=~amanda
PASSPHRASE=$AMANDA_HOME/.am_passphrase # required
RANDFILE=$AMANDA_HOME/.rnd
export RANDFILE
if [ "$1" = -d ]; then
/usr/bin/openssl enc -pbkdf2 -d -aes-256-ctr -salt -pass fd:3 3< "${PASSPHRASE}"
else
/usr/bin/openssl enc -pbkdf2 -e -aes-256-ctr -salt -pass fd:3 3< "${PASSPHRASE}"
fi
pbkdf2 to fix the deprecated key derivation, aes-256-ctr for better and faster encryption (ctr can be parallelized). Also padding is not needed with this encryption method.
great. Let me add this one for completeness: the file defined in $RANDFILE has to be created and seeded like in:
backup:~$ dd if=/dev/urandom of=.rnd bs=256 count=1
Could that maybe even be done by the wrapper script itself?
Ah yes mine was probably already created long ago when i set up encryption. From what i have read the random file is not really needed on most systems as it is only there to help with low entropy systems (ie server that does nothing most of the time). Each time openssl runs it uses that file (if specified) for random seeds and at command end it replaces the file with 256 new bytes of randomness for the next invocation. It is not needed for decryption.
@exuvo thanks for the explanation. Correct, I see it replaced already. So it would make even more sense to add some block to the wrapper like "if not exists file $RANDFILE, dd some random bytes into it". This would help the initial configuration/setup (which I tend to put into some HOWTO somewhere).
This should do it:
if [ ! -f "$RANDFILE"]; then
dd if=/dev/urandom of="$RANDFILE" bs=256 count=1
fi
Yep, looks ok. Will test, thanks.
A whitespace before the closing bracket was missing, tiny correction:
if [ ! -f "$RANDFILE" ]; then
Edit: unfortunately I see "missing size line from sendbackup" in the amanda reports.
My quick tests show that this is with DLEs using amsamba
plus the encryption.
The simpler tar-based DLEs seem to work fine.
With last versions of openssl the warning message
is being produced by amcrypt-ossl.
It can be corrected by adding -pbkdf2 to the amcrypt-ossl calls to openssl: