Recover fails to use SSH key

[jmwilkinson]

I'm running barman within a docker container, attempting to verify the recovery procedure.

I can ssh in normally:

root@39d945918f05:~/.ssh# ssh barman@$PG_RECOVERY_TARGET
Last login: Fri Apr  5 17:51:45 2024 from 10.10.2.2

However, when I try to run a barman recover command, it prompts me for the password:

root@39d945918f05:~/.ssh# barman --log-level DEBUG recover   --remote-ssh-command "ssh barman@$PG_RECOVERY_TARGET"   $PG_BACKUP_SERVER latest $PGDATA
barman@--host--'s password:

Eventually, if I type in the password repeatedly, I get to see the error at the end of the process:

Warning: Identity file /root/.ssh/id_rsa not accessible: Permission denied.

I've tried explicitly forcing the SSH key:

barman --log-level DEBUG recover   --remote-ssh-command "ssh barman@$PG_RECOVERY_TARGET -i /root/.ssh/id_rsa"   $PG_BACKUP_SERVER latest $PGDATA

It has the same result.

I've checked the server logs during this process, and at no point is the SSH key used (which is implied by the error message). It appears to be a client side decision to ignore the key.

The permissions are correct on the key:

~/.ssh# ls -la
total 12
drwx------. 1 root root   78 Apr  5 21:18 .
drwx------. 1 root root  138 Apr  4 22:46 ..
-rw-------. 1 root root 2610 Apr  5 21:18 id_rsa

Also, rsync can operate normally using the key without issue:

# rsync -Pav test barman@$PG_RECOVERY_TARGET:/tmp
sending incremental file list
test
              3 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=0/1)

sent 104 bytes  received 35 bytes  92.67 bytes/sec
total size is 3  speedup is 0.02

So it appears barman is doing something unusual that is causing this, possibly switching the user the subprocess is running under? Which if this is the case, I was unable to find any documentation referencing it, and certainly not in relation to setting up the SSH configuration.

[martinmarques]

This is not to solve your problem, but I am curious to know why you are using the root user to recover a backup. Have you tried using the barman user for this?

[martinmarques]

You should check the sshd logs on the $PG_RECOVERY_TARGET node to see why it's not picking up the ssh keys. You could also make ssh more verbose with -vvv and see if there are any hints in the output.

I haven't looked at the code, but I don't recall barman switching users when running rsync. That's homework for me, but I'm busy with incremental backup in postgres reviews 😉

[jmwilkinson]

@martinmarques Thanks for the replies.

As stated in the issue:

I've checked the server logs during this process, and at no point is the SSH key used (which is implied by the error message). It appears to be a client side decision to ignore the key.

I would copy paste the server logs, but there isn't anything really to paste- when I follow sshd logs and then run this process, there is no output before prompting for the password (no handshake, no negotiation, nothing), indicating there was never an attempt to use the key. I have the sshd log level set to debug.

I'm using the root user because I'm running in a docker container, and did not see a reason to create a non-root user in that context. There is no barman user inside the container.

[bazaah]

Just encountered this issue myself, though on a VM.

I 'fixed' it by chown-ing the pub+priv key files to barman (which did have a local user on the system), but the lack of errors / diagnostic information even with --log-level DEBUG made it difficult to figure out what was failing.

So, TLDR: unix uid/gid issues, seemingly barman drops perms or switches users somewhere before invoking --remote-ssh-command.

Version: 3.5.0 Barman by EnterpriseDB (www.enterprisedb.com)