We recently setup Cygwin and sshd on one of our Windows servers to allow one of our Linux (RHEL6) servers to call a bat file on the Windows server. Since this will be automated from the Linux side I setup standard ssh trust from the Linux user to a Windows user. Testing the trust verified it works and can be used to execute Windows bat files.

The problem is that there is a specific bat file that is failing when the command it calls tries to login to the application (i.e. not OS level login) but appears to be running the other commands in the bat file properly.

The weirdness is that this failure only occurs when we call it using ssh trust to make the connection. If we make the connection without a trust so that it prompts for the OS level password the bat file then executes correctly including its application level login.

This suggests there is some environmental difference when ssh logs in with a password vs when it connects with a trust. I've checked the "set" and "env" Linux commands output as well as the DOS "set" command output and there is no difference between them when logged in via trust vs logged in via password.

To reiterate the “login” that is failing is something with the application not the OS user. The OS user works either way. Calling the bat file works either way – it is only this application “login” that is failing within the bat file when doing trust.

I also found sshpass allows one to feed the OS level password to the ssh call and using that also works when I call the bat file. This reinforces the idea of an environmental difference between password login and trust connection.

Has anyone seen this kind of behavior before and if so can you share what you did to resolve it for trusts?

No idea what this could be. Try running 'ssh -v' to show all of the steps for each login method. Maybe that will help track down the difference.

I did of course look at ssh -v (and -vvv) but those really don't tell me much other than connection information and methods. I've used them often for debugging failed ssh/sftp connections but as noted in my original post I am connecting successfully and am even able to execute the specific bat file. This isn't a connection issue but rather some subtle difference between the way it sees the user based on whether it came in via the trust or via password authentication.

In a simple cygwin on windows 7 sshd setup, I had to assign some additional user rights to the sshd service account, using the cygwin editrights program.

Google found this maillist thread on the subject: https://cygwin.com/ml/cygwin/2013-02/msg00185.html.

Thanks but that thread doesn't seem to apply to the issue I described. It is about sshd not starting and on our Windows server sshd is running fine. I can login either via password or via trust.

What is different for my issue is what occurs in one bat file after the login as I originally wrote. If there are specific sshd settings you think would account for the behavior I described please feel free to share them.

I got the answer from the Cygwin mailing list when I posted the question there today:

On doing the "passwd -R" (which is a Cygwin option as described in above link) to update the Registry and re-establishing the trust we found the problem to be solved when connecting via trust.

Thanks for the update. I was thinking maybe a problem because windows service accounts can't use the desktop without having that right assigned. This has been the case since NT4 afaik.