Testing and Resolving Windows SSH configuration issues

Owned by KrupeshD (Deactivated)
Last updated: Jun 28, 2015 by Anton Els (Deactivated)
8 min read

Overview of Windows SSH connection

Dbvisit Standby version 5 and 6 uses Bitvise (www.bitvise.com) 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 which is an ssh server running as a Windows service that 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.

For the connection between the standby server to the primary server, the following components are used:

  • 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:

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:

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.

1. Start the "System Readiness Check" by starting the Dbvisit Standby Windows installer and select the following option.


Follow the onscreen instructions to test the SSH2 configuration. This should be tested on both the primary and standby servers to ensure that the SSH2 configuration is working both ways.

2. If the Dbvisit Standby Windows installer is no longer available, the System Readiness Check can be started manually with the following command:

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.

Resolving Windows SSH configuration issues

If the default SSH Setup has not configured Bitvise WinSSHD correctly or if Dbvisit Standby returns the following error:

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 = 103

On the standby server, the following message may also be seen in the Windows Event viewer:

[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

The WinSSHD account information may not have been loaded.

1. On the standby (or remote) server.

2. Open the WinSSHD control panel (Start>Programs>Bitvise WinSSHD>WinSSHD Control Panel).

3. Choose "Settings Tab" and click on "Edit/View settings"

4. Click on "Access control" and then "Windows accounts". The windows account should contain one entry as follows (the Windows account name may be different to the one shown below):

5. If there is no entry in "Windows accounts", click on "Add".

6. Enter the Windows account name of the current Windows logon (the same acount that will be running Dbvisit Standby). In this example the Windows account name is "oracle".

Set "login allowed" to Yes
Set "Public key authentication" to Required
Set "Permit remote administration" to No
By default a Windows account domain is normally not required, but depending on your network and domain settings this may be required.

7. Click on "Public Keys" and click on "Import":

8. In the Open dialog box, navigate to Dbvisit Standby install directory (default c:\program files\dbvisit) and open directory ssh2. Choose file A_SSH2PublicKey and click on "Open":

9. Click on "Close" and click on "OK" until the main WinSSHD Control Panel is shown again. Click on "Close" to close the WinSSHD Control Panel.

10. Run Dbvisit Standby again on the primary server to test if the issue has been resolved.

11. It is also recommended to repeat these steps on the primary server. This is in case the Dbvisit Standby process needs to be reversed. The Public Key file name to import will be B_SSH2PublicKey instead of A_SSH2PublicKey.

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:

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

Resolution 2 – Password cache not set

It may also be possible that the Windows Account password is not set correctly in the WinSSHD cache.

1. On the standby (or remote) server.

2. Open the WinSSHD control panel (Start>Programs>Bitvise WinSSHD>WinSSHD Control Panel).

Choose "Settings Tab" and enter the Account name and Password for the current Windows account (the same account that will be running Dbvisit Standby). A Windows domain may also be required. WinSSHD will notify if a domain is required.

3. Run Dbvisit Standby again on the primary server to test if the issue has been resolved.

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. This sets up and loads the public and private key combination.

There are two option to configure and setup SSH2 again:

  1. Through the Dbvisit Standby Windows Installer.
  2. 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.

3. Follow the instructions. When asked "Is this the primary server" please answer "yes".

4. Once completed, start the Dbvisit Standby installer on the standby server 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 primary server.

5. Follow the instructions. When asked "Is this the primary server" please answer "no".

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:

 dbv_functions.exe -Y primary setupssh

Follow the instructions.

2. On the standby server, start the Dbvisit Standby command console and type: 

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:

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 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.