EXTERNAL SENDER: Re: Issue with seteuid and openssh

[Dale Lobb]

Greetings All,

  I got the chance to work on this issue some more today.  Unfortunately, none of the suggestions helped.  What I tried:

  1.  I verified that that the windows firewall is allowing port 22 inbound for the cygsshd service.  This has not changed since system inception last year.

  2.  I verified that the cygsshd service has a dependency on the tcpip service and I set cygsshd to delayed automatic start:  no change in behavior after reboot.

  3.  I installed the cygserver service and set it to delayed automatic start.  I changed the cygsshd service back to normal automatic start and added a dependency on the cygserver service: again, no change in behavior after reboot.

  I also verified that a windows console login will end the embargo on cygsshd after reboot, just as an RDP session will.

  Any other ideas?

Best Regards,

Dale Lobb


> -----Original Message-----
> From: Cygwin <cygwin-bounces+dale.lobb=bryanhealth.org@cygwin.com>
> On Behalf Of Stephen Carrier
> Sent: Thursday, May 26, 2022 6:43 PM
> To: Achim Gratz <Stromeko@nexgo.de>
> Cc: cygwin@cygwin.com
> Subject: EXTERNAL SENDER: Re: Issue with seteuid and openssh
>
> In the 2019 occurence of a similar problem, cygserver wasn't being used,
> so I would be interested and happy to hear if running it and waiting for it
> are enough to fix this.
>
> --Stephen
>
>
> On Wed, May 25, 2022 at 07:51:14PM +0200, Achim Gratz wrote:
>>Check the dependencies on both the cygserver and sshd service definitions.
>> You must start them after the network is up (make them both depend
>> on tcp_ip and sshd depend on cygserver) or they won't work correctly.
>>  On domain machines that sometimes still isn't quite enough, so I've set
>> them to "delayed start" in those instances and that seems to have fixed it.
>>
>>Also check that the firewall allows connections through whatever port you've
>> configured sshd to use.
>>
>>Regards,
>>Achim.
>>
>>Dale Lobb wrote on 5/24/2022:
>>>Greetings All,
>>>
>>>  Has anyone seen an issue similar to this?
>>>
>>>  I have a VMWare virtual machine loaded with Windows Server 2016 OS and
>>>a Cygwin installation.  Cygwin runs an installed SSHD service via
>>>cygrunsrv.exe.  A data gateway engine on a different machine makes regular
>>>programmatic connections via SFTP to the server throughout the day.  This
>>>setup was established in 2021 and has run without issue for almost a year.
>>>
>>>  Last night, the server rebooted automatically after windows updates.
>>>After the reboot, the data gateway was then no longer able to connect to
>>>the server.  This condition persisted until I was informed of the issue
>>>this morning and connected to the Windows server using RDP to take a look
>>>at the issue, at which point the SSH connection suddenly started working.
>>>Further tests showed this to be entirely repeatable.  After rebooting the
>>>server, the SSHD daemon does not allow connections, neither with password
>>>nor public key authorization, until someone connects to the server via RDP,
>>>at which time the SSH connections suddenly starts working again.
>>>
>>>  The server's Windows application event log shows numerous errors from
>>>the SSHD daemon stating "sshd: PID <####>: fatal: seteuid 197108: No such
>>>device or address" during the time frame when SSH connection were not
>>>working.  The errors stop immediately when the RDP connection is recorded
>>>in the same event log.
>>>
>>>  A google search for the error message turned up something somewhat
>>>similar from this mailing list back in March of 2019, but there is no
>>>mention of RDP in that exchange.  Also, the advice given, to convert the
>>>SSHD service from running under the cyg_server account to LocalSystem, does
>>>not apply here, because the Cygwin installation is recent enough that it is
>>>already running under LocalSystem.
>>>
>>>  When this issue started, the server was running openssh-8.7p1-1.  The
>>>server was subsequently updated to the latest, openssh-9.0p1-1, but there
>>>has been no change in the observed behavior.
>>>
>>>Best Regards,
>>>
>>>Dale Lobb


________________________________

CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipients and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Dale Lobb.vcf
Type: text/x-vcard
Size: 4581 bytes
Desc: Dale Lobb.vcf
URL: <https://cygwin.com/pipermail/cygwin/attachments/20220714/5a37adf2/attachment.vcf>