Using SSH as Primary Communication Layer for Dbvisit Standby

Follow
* Updated & Checked for relevance August 2023 *
 
Problem Description

When using Dbvisit Standby on Unix based systems, you can also configure the use of SSH instead of using Dbvnet. 

Note:  Using SSH on Unix based systems is 100% supported by Dbvisit Standby version 9 and version 10.  SSH is NOT supported in Dbvisit version 11.

On Windows based systems Dbvnet is the only option when using Dbvisit Standby.

This document will describe the steps to switch from Dbvnet to SSH for network communication.

Configure SSH Equivalency

The key requirement for using SSH is to ensure SSH user equivalence between the primary and standby servers. If using Oracle Linux or RHEL you can easily make use of the following commands:

To Generate the required keys:

ssh-keygen -t dsa

To Update the remote server's authorized keys file:

ssh-copy-id -i $HOME/.ssh/id_dsa.pub oracle@remote_server_name

For example, if you have two servers PrimaryNode and StandbyNode and are using the "oracle" Unix account you can follow these steps to enable SSH User Equivalence:

On PrimaryNode as the oracle Unix account:

  • Run the ssh-keygen command and press enter, accepting null values when asked for a pass-phrase (do not supply a pass-phrase). The required DSA keys will be created in the $HOME/.ssh/ directory

    ssh-keygen -t dsa
  • Run the ssh-copy-id command to update the local and remote authorized_keys files:

    ssh-copy-id -i $HOME/.ssh/id_dsa.pub oracle@PrimaryNode
    ssh-copy-id -i $HOME/.ssh/id_dsa.pub oracle@StandbyNode

On StandbyNode as the oracle Unix account:

  • Run the ssh-keygen command and press enter. Accept null values when asked for a pass-phrase (do not supply a pass-phrase). The required DSA keys will be created in $HOME/.ssh/ directory

    ssh-keygen -t dsa
  • Run the ssh-copy-id command to update the local and remote authorized_keys files:

    ssh-copy-id -i $HOME/.ssh/id_dsa.pub oracle@PrimaryNode
    ssh-copy-id -i $HOME/.ssh/id_dsa.pub oracle@StandbyNode

Following the above steps, you should now be able to SSH between the primary and standby servers without being asked for a password. For example, running the following you should not be asked for any passwords and should just echo back the date from the remote server:

On PrimaryNode: ssh PrimaryNode "date"

On StandbyNode: ssh StandbyNode "date"

If you do not have the option to use the ssh-copy-id command you can update the authorized_keys file manually.

Changes Required in DDC file to use SSH

Once you have SSH user equivalence configured, you can now update the following values in the Dbvisit Standby DDC file on the primary and standby server:

NETPORT = 22
NETPORT_DR = 22
CP = /usr/bin/scp
RSH = /usr/bin/ssh

If an SSH banner is used, you can use the following two parameters to skip the banner output: SSH_SKIP_OUTPUT and SSH_SKIP_OUTPUT_LINE. For example:

SSH_SKIP_OUTPUT_LINES=11

Or disable your banner completely.

Once the changes are implemented, you can check on primary server if all works as expected, by attempting to send manually archivelog to the standby database:

./dbvctl -d <DDC>

 

Have more questions? Submit a request

Comments

  • Avatar
    Riccardo

    We found a problem in the IPSec tunnel between the 2 hosts.
    One of the two tunnel is down, so this explains why some connection tests are working and other not.
    Please hang on ,while we try to solve the problem.

  • Avatar
    Riccardo

    The IPSec tunnel was the problem. It seemed ok but it was not.
    So, after VPN fix, all communications between dbv process are OK.
    Thank you for the support.

    Riccardo

  • Avatar
    Riccardo

    You can close the request