openssh bugs - Apr 2006 - [Bug 1184] remote ssh command runs very slow on windows 2003

http://bugzilla.mindrot.org/show_bug.cgi?id=1184

           Summary: remote ssh command runs very slow on windows 2003
           Product: Portable OpenSSH
           Version: 4.3p2
          Platform: Other
        OS/Version: Cygwin on NT/2k
            Status: NEW
          Severity: major
          Priority: P2
         Component: sshd
        AssignedTo: bitbucket at mindrot.org
        ReportedBy: shaick.pop at gmail.com
                CC: shaick.pop at gmail.com


I installed cygwin ( CYGWIN_NT-5.2 ) on windows 2003 and windows XP. On
remote I can run the commands very fast on the XP machine. Buf from
remote machine the command execution take very long to complete. Simple
date command take 25 seconds to return the output. Even from the local
2003 server running command via ssh takes 20+ sec to give output.

Following is the debug output of sshd in the windows 2003 server.
2003

$ /usr/sbin/sshd -d
debug1: sshd version OpenSSH_4.3p2
debug1: private host key: #0 type 0 RSA1
debug1: read PEM private key done: type RSA
debug1: private host key: #1 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #2 type 2 DSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
Generating 768 bit RSA key.
RSA key generation complete.
debug1: fd 4 clearing O_NONBLOCK
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7
debug1: inetd sockets after dupping: 3, 3
Connection from 130.35.185.57 port 4902
debug1: Client protocol version 2.0; client software version
OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-1.99-OpenSSH_4.3
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user ntregres service ssh-connection
method none
debug1: attempt 0 failures 0
Failed none for ntregres from 130.35.185.57 port 4902 ssh2
debug1: userauth-request for user ntregres service ssh-connection
method publick
ey
debug1: attempt 1 failures 1
debug1: test whether pkalg/pkblob are acceptable
debug1: temporarily_use_uid: 11114/10513 (e=11114/10513)

=================HANGS about 10 secs ====================
debug1: trying public key file /home/ntregres/.ssh/authorized_keys
debug1: matching key found: file /home/ntregres/.ssh/authorized_keys,
line 1
Found matching RSA key: 35:32:64:ef:b0:fe:52:6a:82:3d:1b:a6:a5:8e:96:39
debug1: restore_uid: 11114/10513
Postponed publickey for ntregres from 130.35.185.57 port 4902 ssh2
debug1: userauth-request for user ntregres service ssh-connection
method publick
ey
debug1: attempt 2 failures 1
debug1: temporarily_use_uid: 11114/10513 (e=11114/10513)
debug1: trying public key file /home/ntregres/.ssh/authorized_keys
debug1: matching key found: file /home/ntregres/.ssh/authorized_keys,
line 1
Found matching RSA key: 35:32:64:ef:b0:fe:52:6a:82:3d:1b:a6:a5:8e:96:39
debug1: restore_uid: 11114/10513
debug1: ssh_rsa_verify: signature correct
Accepted publickey for ntregres from 130.35.185.57 port 4902 ssh2
debug1: monitor_child_preauth: ntregres has been authenticated by
privileged pro
cess
debug1: Entering interactive session for SSH2.
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan 0 win 131072 max
32768
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: init
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: server_input_channel_req: channel 0 request exec reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req exec

=================HANGS about 10 secs ====================

debug1: Received SIGCHLD.
debug1: session_by_pid: pid 2652
debug1: session_exit_message: session 0 channel 0 pid 2652
debug1: session_exit_message: release channel 0
debug1: session_by_channel: session 0 channel 0
debug1: session_close_by_channel: channel 0 child 0
debug1: session_close: session 0 pid 0
debug1: channel 0: free: server-session, nchannels 1
Connection closed by 130.35.185.57
debug1: do_cleanup
Closing connection to 130.35.185.57




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1184





------- Comment #1 from dtucker at zip.com.au  2006-04-22 20:16 -------
Delays like that are often caused by DNS reverse-resolution problems. 
Does adding "UseDNS no" to sshd_config (and restarting sshd) and/or
putting the client's IP address in the hosts file make any difference?




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1184





------- Comment #2 from dtucker at zip.com.au  2006-04-23 16:41 -------
*** Bug 1185 has been marked as a duplicate of this bug. ***




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1184





------- Comment #3 from shaick.pop at gmail.com  2006-04-23 19:22 -------
With some more analysis this happens only for a domain user. For the
windows 2003 localuser the SSH commands runs faster.

But I can login without any delay in terminals. Is there any way to
solve this.

I added "UseDNS no" to sshd_config and IP in /etc/hosts file, but it
issue exist for the domain user.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.