0

Note: This system is standalone so I can not pull any logs or files off of it, I can only write down what I am seeing in the log.

We have two systems that are identical for the most part. Each system has a windows 2008R2 server with our software on it, and a RHEL6 server to perform telephony tasking. When we need to startup the system from a powered off state, the Windows server attempts to send a configuration file to the RHEL server. This is done using a third party library, nSoftware IP*Works! SSH. In order to send the configuration file, we use the SSHSFTP method with password authentication. This has been working fine for years.

We just installed a new pair of systems this week, and for some reason, even though we did a complete checkout of the system prior to shipping including many startups, now onsite one of the systems can no longer perform the SSHSFTP file transfer. The message I get in the windows logs is "IPWorks SSHSFTPException: Cannot authenticate with the provided credentials" "The following authentication methods are available for this user, public Key, gssaprkeyx, gss[illegible]mic, password"

Wireshark shows the starting exchange that looks something like this:

SSHv2 Client: Key Exchange Init SSHv2 Server: Key Exchange Init SSHv2 Client: New Keys SSHv2 Server: New Keys

I can use putty to SSH into the server from windows without any issues. I have no idea what could have changed. IS there a seperate SFTP credential that this is failing on? OR is it the SSH session that is failing? Any thoughts on this?

5
  • Loads on thoughts on this, but it would probably more effective to check your SSH server's logs. You could also try setting up a debug session with /usr/sbin/sshd -Dd -p 2222 and connecting with SSH on port 2222.
    – mtak
    Aug 8, 2017 at 6:27
  • Is IPWorks SSHSFTP providing the hostname/domain where the remote user resides? E.g. When Windows tries to authenticate using a remote user's credentials you have to provide in the form domain\user or remoteIp\user?
    – Kinnectus
    Aug 9, 2017 at 11:53
  • Things got more interesting yeterday, when we came back to the system. booted it up, and tried again, and everything worked fine!! Even though we went through multiple reboots earlier. The kicker is now the issue has started on the other standalone system that was working fine a day ago. The RHEL has some RHEL VM's running on it, and I used one to test an SFTP session with the correct credentials and that worked fine.
    – kuhnto
    Aug 11, 2017 at 4:01
  • pastebin.com/4V1z7Xxh
    – kuhnto
    Aug 11, 2017 at 4:11
  • This issue happened again. The only way to clear the issue seems to be that you need to "Power Off" the server. You can not just reboot it. Once it is physically shut down and restarted, the systems can communicate again. The /var/logs/secure shows enteries for "unknown user"
    – kuhnto
    Aug 21, 2017 at 15:27

0

You must log in to answer this question.

Browse other questions tagged .