A fundamental mechanism of BART is the use of the Secure Shell (SSH) and the Secure Copy (SCP) Linux utility programs to copy the backup and WAL files from the BART managed database servers to the BART host as well as to restore backups.The client/server SSH and SCP connections must not prompt for a password when establishing the connection.A password-less connection is accomplished by the use of authorized public keys, which is a list of public keys of client user accounts that are to be allowed to connect to the target server.Each client user account generates a public key, which must then be added to the target user account’s authorized public keys list on the target server.
• Depending upon the Linux operating system running the SSH server daemon, there may be different steps required to enable the usage of public key authentication, and hence, the capability to enable password-less SSH and SCP connections.In the SSH server daemon configuration file, /etc/ssh/sshd_config, check that the following parameter is set to yes and is not commented:Any of the following commands can be used instead of service sshd reload:Note: For any SSH or SCP errors or problems, examine the following log file:The target server to which a password-less SSH or SCP connection is to be made must contain an authorized public keys file. The file is named authorized_keys and is located under the USER_HOME/.ssh directory where USER_HOME is the home directory of the user account on the target server that is to be used to establish the remote session.On each client system that is to make a password-less connection to the target server, the client’s public key is generated while logged into the client system with the user account that is to request the SSH or SCP connection. The generated public key must be then copied to the target server and concatenated onto the USER_HOME/.ssh/authorized_keys file.Note: The public key should be appended onto the end of any existing authorized_keys file. Any existing authorized_keys file should not be replaced in its entirety.The following are the general instructions for generating a client’s public key file and then creating the target server’s authorized public keys file.Step 1: On the client system, log in as the user account that will be initiating the SSH or SCP connection.Step 2: Change to the user account’s home directory and check if there is an existing .ssh subdirectory. If not, create one as follows:chown user .sshchgrp usergroup .sshWhere user is the user account name and usergroup is the associated group of the user.Step 3: Generate the public key file with the following command. Accept all prompted defaults and do not specify a passphrase when prompted for one.The public key file named id_rsa.pub is created in the .ssh subdirectory.Step 4: By whatever means is available in your system environment, create a copy of file id_rsa.pub on the target server.For example, while logged into the client where you just generated the public key file, use SCP to make a temporary copy of it on the target server:scp ~/.ssh/id_rsa.pub target_user@host_address:tmp.pubStep 5: Log into the target server as target_user, again using whatever means is possible in your system environment.ssh target_user@host_addressStep 6: Change to the target user account’s home directory and check if there is an existing .ssh subdirectory. If not, create one as shown in Step 2.Step 7: Append the temporary, client’s public key file, tmp.pub, to the authorized keys file named authorized_keys. If an existing authorized keys file does not exist, create a new file, but do not completely replace any existing authorized keys file.Make sure the authorized_keys file is only accessible by the file owner and not by groups or other users. If the authorized_keys file does not have the required permission setting (600) or it was newly created, change the file permissions as follows:Step 8: Delete the temporary public key file, tmp.pub.Now, when logged into the client system as user there should be no prompt for a password when commands such as the following are given:ssh target_user@host_addressscp file_name target_user@host_address:directory_pathscp target_user@host_address:directory_path/file file_name
1. From each BART managed database server (SSH/SCP client) to the BART host (target SSH/SCP server) for supporting WAL archiving in the postgresql.conf or postgresql.auto.conf archive_command parameter.
2. From the BART host (SSH/SCP client) to each BART managed database server (target SSH/SCP server) for taking incremental backups and for supporting restoration of the full backup, the archived WAL files, and the modified blocks, which occurs when the BART RESTORE subcommand is given. Note: If backups are to be taken from a given database server host, but restored to a different database server host, the password-less SSH/SCP connections must be configured from the BART host to the database server host from which the backup is to be taken as well as from the BART host to the database server host to which the backup is to be restored.Note: WhileFor scenario 1, the SSH client in which the public key file (id_rsa.pub) is generated with the ssh-keygen –t rsa command is the database server. The public key file is generated by the user account running the database server.The target SSH server in which the public key file is to be appended onto the ~/.ssh/authorized_keys file is the BART host. The authorized_keys file is in the BART user account’s home directory.For scenario 2, the SSH client in which the public key file (id_rsa.pub) is generated with the ssh-keygen –t rsa command is the BART host. The public key file is generated by the BART user account.The target SSH server in which the public key file is to be appended onto the ~/.ssh/authorized_keys file is the database server. The authorized_keys file is in the home directory of the user account owning the directory where the database backup is to be restored.