sshd.exe waits repeatedly with SYN_SENT for inaccessible ldap

sshd.exe waits repeatedly with SYN_SENT for inaccessible ldap

[basinilya]

Hi. The problem first appeared ten days ago. It now takes minutes to login as a domain user. Tcpview shows that sshd.exe is trying to connect an inaccessible server on the port 389 (ldap). If I close the socket using Tcpview, successful login happens sooner. Both password and public key logins are affected, but with a public key sshd.exe tries to connect that server multiple times. Also, if I don't close the sockets repeatedly, ssh disconnects from the SSH server after 2 minutes of silence before the "last login" line appears:

    $ time ssh -vvv localhost
    ...
    debug1: Offering public key:
    debug3: send packet: type 50
    debug2: we sent a publickey packet, wait for reply
    
    
    debug3: receive packet: type 60
    debug1: Server accepts key: 
    debug3: sign_and_send_pubkey: RSA
    debug3: sign_and_send_pubkey: signing using rsa-sha2-512
    debug3: send packet: type 50
    
    
    Connection closed by ::1 port 22
    
    real    2m0.292s
    user    0m0.045s
    sys     0m0.122s



Besedes, sshd.exe has a live connection on port 389 to another server all the time.


I can't see anything interesting in sshd log. At least the ldap ip address does not appear in the log.

    ...
    <TimeCreated SystemTime="2021-01-22T18:52:09.7210295Z" /> 
    <Data>sshd: PID 1786: debug1: temporarily_use_uid: 1087042/1049089 (e=18/18)</Data> 
      
    <TimeCreated SystemTime="2021-01-22T18:52:51.9304939Z" /> 
    <Data>sshd: PID 1786: debug1: trying public key file /home/basin/.ssh/authorized_keys</Data> 
    ...
    
    <TimeCreated SystemTime="2021-01-22T18:53:21.6284471Z" /> 
    <Data>sshd: PID 1786: debug1: temporarily_use_uid: 1087042/1049089 (e=18/18)</Data> 
    ...
    
    
    <TimeCreated SystemTime="2021-01-22T18:54:03.7296838Z" /> 
    <Data>sshd: PID 1786: debug1: trying public key file /home/basin/.ssh/authorized_keys</Data> 
    ...
    
    
    <TimeCreated SystemTime="2021-01-22T18:54:03.7296838Z" /> 
    <Data>sshd: PID 1786: debug1: monitor_child_preauth: basin has been authenticated by privileged process</Data> 
    ...
    
    
    <TimeCreated SystemTime="2021-01-22T18:54:09.6686942Z" /> 
    <Data>sshd: PID 1652: debug1: main_sigchld_handler: Child exited</Data> 

BTW, is it possible to make sshd write to a log file instead of Windows Event Log?

Re: sshd.exe waits repeatedly with SYN_SENT for inaccessible ldap

[basinilya]

The problem is solved.
Our DHCP server was sending me a bad WINS server ip. After fixing the issue I had to reboot the PC (just refreshing the ip and restarting cygsshd was not enough).

On 22.01.2021 22:07, basinilya@gmail.com wrote:
> Hi. The problem first appeared ten days ago. It now takes minutes to login as a domain user. Tcpview shows that sshd.exe is trying to connect an inaccessible server on the port 389 (ldap). If I close the socket using Tcpview, successful login happens sooner. Both password and public key logins are affected, but with a public key sshd.exe tries to connect that server multiple times. Also, if I don't close the sockets repeatedly, ssh disconnects from the SSH server after 2 minutes of silence before the "last login" line appears:
> 
>     $ time ssh -vvv localhost
>     ...
>     debug1: Offering public key:
>     debug3: send packet: type 50
>     debug2: we sent a publickey packet, wait for reply
>     
>     
>     debug3: receive packet: type 60
>     debug1: Server accepts key: 
>     debug3: sign_and_send_pubkey: RSA
>     debug3: sign_and_send_pubkey: signing using rsa-sha2-512
>     debug3: send packet: type 50
>     
>     
>     Connection closed by ::1 port 22
>     
>     real    2m0.292s
>     user    0m0.045s
>     sys     0m0.122s
> 
> 
> 
> Besedes, sshd.exe has a live connection on port 389 to another server all the time.
> 
> 
> I can't see anything interesting in sshd log. At least the ldap ip address does not appear in the log.
> 
>     ...
>     <TimeCreated SystemTime="2021-01-22T18:52:09.7210295Z" /> 
>     <Data>sshd: PID 1786: debug1: temporarily_use_uid: 1087042/1049089 (e=18/18)</Data> 
>       
>     <TimeCreated SystemTime="2021-01-22T18:52:51.9304939Z" /> 
>     <Data>sshd: PID 1786: debug1: trying public key file /home/basin/.ssh/authorized_keys</Data> 
>     ...
>     
>     <TimeCreated SystemTime="2021-01-22T18:53:21.6284471Z" /> 
>     <Data>sshd: PID 1786: debug1: temporarily_use_uid: 1087042/1049089 (e=18/18)</Data> 
>     ...
>     
>     
>     <TimeCreated SystemTime="2021-01-22T18:54:03.7296838Z" /> 
>     <Data>sshd: PID 1786: debug1: trying public key file /home/basin/.ssh/authorized_keys</Data> 
>     ...
>     
>     
>     <TimeCreated SystemTime="2021-01-22T18:54:03.7296838Z" /> 
>     <Data>sshd: PID 1786: debug1: monitor_child_preauth: basin has been authenticated by privileged process</Data> 
>     ...
>     
>     
>     <TimeCreated SystemTime="2021-01-22T18:54:09.6686942Z" /> 
>     <Data>sshd: PID 1652: debug1: main_sigchld_handler: Child exited</Data> 
> 
> BTW, is it possible to make sshd write to a log file instead of Windows Event Log?
> 
> 

Re: sshd.exe waits repeatedly with SYN_SENT for inaccessible ldap

[Bill Stewart]

On Tue, Jan 26, 2021 at 6:31 AM Ilya Basin via Cygwin wrote:

> The problem is solved.
> Our DHCP server was sending me a bad WINS server ip. After fixing the issue I had to reboot the PC (just refreshing the ip and restarting cygsshd was not enough).

It's doubtful a reboot is required. Probably 'nbtstat -RR' would have
been sufficient (although this command does require elevation).

Bill

Re: sshd.exe waits repeatedly with SYN_SENT for inaccessible ldap

[Bill Stewart]

On Thu, Jan 28, 2021 at 12:06 PM Bill Stewart wrote:
>
> On Tue, Jan 26, 2021 at 6:31 AM Ilya Basin via Cygwin wrote:
>
> > The problem is solved.
> > Our DHCP server was sending me a bad WINS server ip. After fixing the issue I had to reboot the PC (just refreshing the ip and restarting cygsshd was not enough).
>
> It's doubtful a reboot is required. Probably 'nbtstat -RR' would have
> been sufficient (although this command does require elevation).

Sorry, that should have read 'nbtstat -R' (not 'nbtstat -RR').

Bill