[ale] ssh to Cygwin sshd bat file fails when trust established but works with password

Lightner, Jeffrey JLightner at dsservices.com
Fri Sep 2 11:00:23 EDT 2016


This is fairly bizarre.

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 users.   Testing the trust verified we can execute Windows bat files.

The problem is that there is a specific bat file that is failing when the command it calls tries to an application level (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.

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?

CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20160902/42752e42/attachment.html>


More information about the Ale mailing list