| Table of Contents |
|---|
Overview of Windows SSH connection
Dbvisit Standby version 5 and 6 uses Bitvise (www.bitvise.com) products software to enable the transfer of archive log files between the primary and standby servers. The Bitvise software is bundled together with the Dbvisit software.
The software components of Bitvise that are used are:
- WinSSHD this which is an ssh server running as a Windows service that runs in the background and accepts the accepts ssh client connections.
- Tunnelier which is an ssh client that initiates the connections and transfers the files.
Both products are installed and configured on the primary and standby servers. The installation and configuration is part of the Dbvisit Standby setup.
For the connection between the primary server to the standby server, the following components are used:
- On the primary server, sftpc.exe (Tunnelier) is called as the client which connects to WinSSHD on the standby server. WinSSHD on the standby server will be running as a Windows service.
...
- On the standby server, sftpc.exe (Tunnelier) is called as the client which connects to WinSSHD on the primary server. WinSSHD on the primary server will be running as a Windows service.
To setup the connection between Tunnelier and WinSSHD a combination of public and private keys are used. The keys need to match with the key (X_WinSSHDKeypair) that is loaded into WinSSHD. The Windows account username and password also needs to be loaded into WinSSHD so that when sftpc.exe connects it can execute the actual copy command on the target server.
The copy command that Dbvisit Standby uses from the primary to the standby server (ServerB) has the following format:
| No Format |
|---|
sftpc.exe ServerB -unat=y -hostKeyFile=B_SSH2PublicKey -keypairFile=A_TunnelierKeypair" -cmd="put -f ...." |
In the Dbvisit Standby trace file there is the actual copy command. You can copy and paste this onto a command prompt and run interactively to see if there is any further output:
| No Format |
|---|
UTIL_WIN32_copy_file_to_remote_server-> "C:\Program Files\Bitvise Tunnelier\sftpc.exe" ..... |
Testing the SSH2 connection between the primary and the standby server.
...
2. If the Dbvisit Standby Windows installer is no longer available, the System Readiness Check can be started manually with the following command:
| No Format |
|---|
dbv_functions.exe |
...
-a system_readiness |
This command should be run on both the primary and standby servers to test the connectivity going both ways.
...
If the default SSH Setup has not configured Bitvise WinSSHD correctly or if Dbvisit Standby returns the following error:]
| Section |
|---|
| Column | ||
|---|---|---|
| ||
|
| width | 95 |
|---|
| bgColor | CCC |
|---|
Remaining authentication methods: 'gssapi-with-mic,password'.ERROR: Session terminated on client's behalf :SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE
no authentication methods available SSH user authentication failure.
Please follow instructions in Dbvisit user manual under Resolving Windows SSH configuration issues.
If that does not resolve the issue, please contact Dbvisit support.
Dbvisit terminated.
Return code = 103On the standby server, the following message may also be seen in the Windows Event viewer:
| Section |
|---|
| Column | ||
|---|---|---|
| ||
|
| width | 95 |
|---|
| bgColor | CCC |
|---|
[030] WinSSHD 4.22: Session thread 4630 handling connection from 10.0.0.47:1637: Logon attempt 1 for user name 'oracle' with logon method 'publickey' failed: Login permission denied by WinSSHD settings.
Please follow the following resolution steps to resolving SSH2 configuration issues.
Resolution 1 – WinSSHD account not set
...
12. To test if WinSSHD on the primary server is configured correctly, the following command can be run on the standby server to test the connection from the standby server to the primary server:
| No Format |
|---|
dbvisit -ReverseCopy <DDC> |
Where
...
DDC
...
is
...
the
...
name
...
of
...
the
...
Dbvisit
...
Database
...
Configuration.
...
In
...
most
...
cases
...
this
...
is
...
the
...
same
...
as
...
the
...
database
...
name. DO NOT INCLUDE THE <>.
...
The
...
DDC
...
refers
...
to
...
the
...
DDC
...
file
...
name
...
which
...
is
...
in
...
the
...
form:
...
dbv_DDC.env
...
and
...
contains
...
the
...
Dbvisit
...
Standby
...
settings
...
for
...
a
...
particular
...
primary
...
and
...
standby
...
configuration.
13. More information about the configuring groups and accounts for WinSSHD can be found here: http://www.bitvise.com/wug-accounts
...
4. It is also recommended to repeat these steps on the primary server. This is in case the Dbvisit Standby process needs to be reversed.
Resolution
...
3a – Run the Configure SSH2 setup again (through Windows installer)
Rerun the Dbvisit Standby installer and only choose the "Configure SSH2" component.
1. On the primary server.
2. This sets up and loads the public and private key combination.
There are two option to configure and setup SSH2 again:
- Through the Dbvisit Standby Windows Installer.
- Manually running a Dbvisit Standby command (see Resolution 3b below) .
Both options produce the same end result. They configure the ssh connection between the primary and standby database by reloading the SSH keys and loading the password into the WinSSHD cache.
Setup SSH using the Dbvisit Standby Installer:
1. On the Primary Server, Double click on the Dbvisit Standby Installer and choose component "Configure SSH2" and "System Readiness Check". The "System Readiness Check" will test if the ssh has been correctly configured and will make a connection to the standby server.
...
6. Run Dbvisit Standby again on the primary server to test if the issue has been resolved.
Resolution 3b – Run the Configure SSH2 setup again (through command line)
Setup SSH using a Dbvisit Standby command:
The SSH setup can also be done manually by running a Dbvisit Standby command. This sets up and loads the public and private key combination.
1. On the primary server, start the Dbvisit Standby command console and type:
| No Format |
|---|
dbv_functions.exe -Y primary setupssh |
Follow the instructions.
2. On the standby server, start the Dbvisit Standby command console and type:
| No Format |
|---|
dbv_functions.exe -Y standby setupssh |
Follow the instructions.
3. Run the System Readiness Check to check the connection between the primary and standby servers:
| No Format |
|---|
dbv_functions.exe –a system_readiness |
This command should be run on both the primary and standby servers to test the connectivity going both ways.
Resolution 4 – Ensure all Dbvisit and Bitvise software is running from the same account
Ensure that the Dbvisit software and the Bitvise software are all installed and running under the same Windows user account. This includes the following software and components:
- Dbvisit Standby
- Dbvserver - This runs as a Windows Service and is a lightweight web server that allows Dbvisit Standby to be managed through a web interface (GUI). Ensure the Dbvserver service logs on as the same windows account as all the Dbvisit and Bitvise software.
- Bitvise WinSSHD - A Windows SSH2 server
- Bitvise Tunnelier - A Windows SSH2 client
Resolution 5 – Ensure Windows accounts are similar
...
...
Ensure the Windows user accounts are similar between the primary and the standby server. Both user accounts must be either domain accounts (within the same domain) or single user accounts.It is not possible to run Dbvisit Standby using a Windows domain account on the primary server and on the standby server run Dbvisit Standby using a standalone Windows user account or vice versa. This is a requirement of WinSSHD to establish a secure and trusted connection.If the standby server is not part of the same domain as the primary server, then the WinSSHD settings are a little different. The account in WinSSHD on the standby server should then be a virtual account and group. Please see http://www.bitvise.com/wug-accounts for more information and http://www.dbvisit.com/forums/showthread.php?p=2865
Resolution
...
6 – Please contact Dbvisit support.
Before contacting Dbvisit support please ensure ENSURE that you have followed above instructions carefully! They have worked for all customers.
The configuration and setup of SSH has been tried and tested to work for Windows under many different circumstances. All parameters must be set according to the instructions. SSH configuration is very specific in its settings and any deviations may not work.