WinSSHD authentication errors

[Arjen Visser]

If you receive the following message from running Dbvisit Standby:

Bitvise Tunnelier 4.24 - sftpc - free for individual use only, see EULACopyright (C) 2000-2007 by Bitvise Limited.Portions Copyright (C) 1995-2003 by Wei Dai.Connecting to SSH2 server backupserver:22.Connected.Starting first key exchange.Server version string: SSH-2.0-1.82 sshlib: WinSSHD 4.23New host key received. Algorithm: ssh-dss, Size: 1024 bits, MD5 Fingerprint: 98:88:55:ba:2e:a9:9f:5c:a9:87:04:ee:42:df:f8:c1, Bubble-Babble: xelep-rofyn-nosaf-girik-mipin-didud-zyzos-mycib-hehyt-kudus-zixox.First key exchange completed.Key exchange: diffie-hellman-group14-sha1. Session encryption: aes256-cbc, MAC: hmac-sha1, compression: none.Attempting 'publickey' authentication. Using keypair at position 1.Warning: Authentication failed. Remaining authentication methods: 'publickey,gssapi-with-mic,password'.ERROR: Session terminated on client's behalf:SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILAB LEno 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

Please follow these steps:

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.

If this does not solve the issue and to understand why WinSSHD is rejecting that public key, please look at the WinSSHD log file.
WinSSHD log will be in c:\Program Files\Bitvise WinSSHD\Logs.

Different domains for the primary and standby server
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.

[Arjen Visser]

Esnure 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 stand alone Windows user account or vice versa. This is a requirement of WinSSHD to establish a secure and trusted connection.

WinSSHD need to have the account and password set in its cache. This is done as part of the Dbvisit Standby setup but can be manually set as well by starting the WinSSHD Control Panel. See: WinSSHDCacheSet.jpg

To reconfigure the entire SSH setup again there are two options:

1. Start the Dbvisit Standby Windows Installer and only select "Configure SSH". Run this on both the primary and standby servers. See: ConfigureSSH.jpg.
   OR:
2. Start the Dbvisit Standby Command Console on the primary server and run:
   dbv_functions -Y primary setupssh
   Start the Dbvisit Standby Command Console on the standby server and run:
   dbv_functions -Y standby setupssh

[Mike Donovan]

The following is feedback from a customer who was working through the steps outlined above to resolve a WinSSHD 103 error:

I've managed to resolve the SSH keys problem. I used the WINSSH control panel to re-enter userid/passwd. Basically the problem was with the service. We need to stop it before entering the userid/passwd and then start service again. This has solved the problem.

[Mike Donovan]

Further problem solving strategies:

Manually try to make a connection from the primary to the standby. You do have to change 1 setting in WinSSHD on the standby to allow this to happen.

• On the standby, start the WinSSH Control panel
• Go to settings
• Click on Edit/View settings
• Under Access control, click on Windows accounts
• Double click on the user you have configured

Recently a couple of Win2008 users discovered that the root of this problem for them was that the domain was not set for user in the SSHD settings. After manually adding this it worked fine.

[Arjen Visser]

It is important to understand the transfer process Dbvisit Standby uses on Windows so that the issues can be further diagnosed.

If you copy from primary to the standby then:
sftpc.exe (Tunnelier) is called on primary and connects to WinSSHD on the standby server.
It uses a combination of public and private keys passed with the copy command and this need to match with the key (B_WinSSHDKeypair) that is loaded into WinSSHD on the standby server. The Windows account username and password need to be loaded into WinSSHD on the standby server so that when sftpc.exe connects it can execute the actual copy command on the standby server.

The dbv_functions -Y primary setupssh and dbv_functions -Y standby setupssh functions loads the appropriate key into WinSSHD and also loads the Windows account, domain and password into WinSSHD so that Tunnelier can execute the command.
Dbvisit Standby runs the "dbv_functions setupssh" commands as part of the SSH setup step in the Dbvisit Standby Windows Installer.
These commands can be run manually:
1) The dbv_functions -Y primary setupssh command on the primary server loads the A_WinSSHDKeypair into WinSSHD on the primary server and loads the The Windows account and password.
2) The dbv_functions -Y standby setupssh command on the standby server loads the B_WinSSHDKeypair into WinSSHD on the standby server and loads the The Windows account and password.

The "dbv_functions setupssh" commands are actually running WinSSHD commands in the background and these can be run interactively through the WinSSHD control panel.

1. The Windows account and password can be set manually by going to "Settings" in the WinSSHD control panel and filling the information for "Password cache for Windows usernames".
2. The key file can be loaded manually. This can be done by going to:
   WinSSHD control panel > Settings > Edit/View Settings > Windows Accounts > Edit > Public Keys > Import

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 trace file there is the following command which 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" .....

[Arjen Visser]

If using a domain account
Ensure the domain name is set in:
WinSSHD control panel > Settings > Edit/View Settings > Windows Accounts > Edit
Add the domain to "Windows account domain"

This should be on both the primary and standby server.

Also see http://www.dbvisit.com/forums/showthread.php?t=1420