Open jmwilkinson opened 6 months ago
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?
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 😉
@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.
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)
I'm running barman within a docker container, attempting to verify the recovery procedure.
I can ssh in normally:
However, when I try to run a barman recover command, it prompts me for the password:
Eventually, if I type in the password repeatedly, I get to see the error at the end of the process:
I've tried explicitly forcing the SSH key:
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:
Also, rsync can operate normally using the key without issue:
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.