search

EnterpriseDB / repmgr

A lightweight replication manager for PostgreSQL (Postgres)
https://repmgr.org/
Other
1.58k stars 252 forks source link

ssh connection problem: barman user #866

Closed greg42300 closed 1 month ago

greg42300 commented 1 month ago

hello, I reproduced the following architecture, with a slave server (pg2). the secondary server must go get its backup from the barman server. https://medium.com/@kiwiv/implement-replication-with-repmgr-and-barman-f1643d3ba9b7

With the following hosts : Debian 11 uptodate, postgres-13 + repmgr 5.2.0 + barman 2.21 pg1 : 192.168.0.19 (master) pg2 : 192.168.0.21 (slave) barman : 192.168.0.25

after running repmgr -h pg1 -U repmgr -d repmgr -F standby clone: no errors then when launching postgres on the pg2 server, I understand that pg2 must connect to the barman server to recover the backup. The postgres service takes a long time to launch.

The ssh connection tests are ok: on the barman host : .ssh/config : Host pg1 pg2 User postgres IdentityFile ~/.ssh/id_rsa_barman

on the other pg1,pg2 hosts: .ssh/config de la sorte : Host barman User barman IdentityFile ~/.ssh/id_rsa_postgres

From the pg1,pg2 hosts to barman serveur, with postgres user:

ssh barman@barman : login ok, with no passphrase and no password

And From the barman host to pg1 et pg2, with the barman user:

ssh postgres@pg1 : login ok, with no passphrase and no password

#ssh postgres@pg2 : login ok, with no passphrase and no password

however on the pg2 server when I restart my postgres server, it takes a long time so I investigated:

logs from postgresql-13-main.log: 2024-10-14 20:31:49.323 CEST [7592] LOCATION: WalReceiverMain, walreceiver.c:408 2024-10-14 20:31:49.323 CEST [7592] FATAL: XX000: could not receive data from WAL stream: ERROR: requested WAL segment 000000010000000000000029 has already been removed 2024-10-14 20:31:49.323 CEST [7592] LOCATION: libpqrcv_receive, libpqwalreceiver.c:801 ERROR: Connection problem with ssh ERROR: Connection problem with ssh

on the barman server in the auth.log logs here is what we see after activating the DEBUG mode of sshd: do you have any leads on the authentication problem of the barman user on the ssh server? it seems to send a user (with or without password) whereas it is a key that would be desirable

Oct 14 20:13:57 barman sshd[4052]: debug1: match: OpenSSH_8.4p1 Debian-5+deb11u3 pat OpenSSH* compat 0x04000000 Oct 14 20:13:57 barman sshd[4052]: debug1: permanently_set_uid: 106/65534 [preauth] Oct 14 20:13:57 barman sshd[4052]: debug1: list_hostkey_types: rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] Oct 14 20:13:57 barman sshd[4052]: debug1: SSH2_MSG_KEXINIT sent [preauth] Oct 14 20:13:57 barman sshd[4052]: debug1: SSH2_MSG_KEXINIT received [preauth] Oct 14 20:13:57 barman sshd[4052]: debug1: kex: algorithm: curve25519-sha256 [preauth] Oct 14 20:13:57 barman sshd[4052]: debug1: kex: host key algorithm: ecdsa-sha2-nistp256 [preauth] Oct 14 20:13:57 barman sshd[4052]: debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: compression: none [preauth] Oct 14 20:13:57 barman sshd[4052]: debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: compression: none [preauth] Oct 14 20:13:57 barman sshd[4052]: debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth] Oct 14 20:13:57 barman sshd[4052]: debug1: ssh_packet_send2_wrapped: resetting send seqnr 3 [preauth] Oct 14 20:13:57 barman sshd[4052]: debug1: rekey out after 134217728 blocks [preauth] Oct 14 20:13:57 barman sshd[4052]: debug1: SSH2_MSG_NEWKEYS sent [preauth] Oct 14 20:13:57 barman sshd[4052]: debug1: Sending SSH2_MSG_EXT_INFO [preauth] Oct 14 20:13:57 barman sshd[4052]: debug1: expecting SSH2_MSG_NEWKEYS [preauth] Oct 14 20:13:57 barman sshd[4052]: debug1: ssh_packet_read_poll2: resetting read seqnr 3 [preauth] Oct 14 20:13:57 barman sshd[4052]: debug1: SSH2_MSG_NEWKEYS received [preauth] Oct 14 20:13:57 barman sshd[4052]: debug1: rekey in after 134217728 blocks [preauth] Oct 14 20:13:57 barman sshd[4052]: debug1: KEX done [preauth] Oct 14 20:13:57 barman sshd[4052]: debug1: userauth-request for user barman service ssh-connection method none [preauth] Oct 14 20:13:57 barman sshd[4052]: debug1: attempt 0 failures 0 [preauth] Oct 14 20:13:57 barman sshd[4052]: debug1: PAM: initializing for "barman" Oct 14 20:13:57 barman sshd[4052]: debug1: PAM: setting PAM_RHOST to "192.168.0.21" Oct 14 20:13:57 barman sshd[4052]: debug1: PAM: setting PAM_TTY to "ssh" Oct 14 20:13:57 barman sshd[4052]: debug1: userauth-request for user barman service ssh-connection method password [preauth] Oct 14 20:13:57 barman sshd[4052]: debug1: attempt 1 failures 0 [preauth] Oct 14 20:13:57 barman sshd[4052]: Failed none for barman from 192.168.0.21 port 52562 ssh2 Oct 14 20:13:57 barman sshd[4052]: debug1: userauth-request for user barman service ssh-connection method password [preauth] Oct 14 20:13:57 barman sshd[4052]: debug1: attempt 2 failures 1 [preauth] Oct 14 20:13:57 barman sshd[4052]: Failed password for barman from 192.168.0.21 port 52562 ssh2 Oct 14 20:13:57 barman sshd[4052]: debug1: userauth-request for user barman service ssh-connection method password [preauth] Oct 14 20:13:57 barman sshd[4052]: debug1: attempt 3 failures 2 [preauth] Oct 14 20:13:57 barman sshd[4052]: Failed password for barman from 192.168.0.21 port 52562 ssh2 Oct 14 20:13:57 barman sshd[4052]: Connection closed by authenticating user barman 192.168.0.21 port 52562 [preauth]

greg42300 commented 1 month ago

sorry, you can close the issue, it's a problem with 'barman-wal-restore' command and ssh-key.