Date: Fri, 1 Nov 2002 09:02:58 -0600 From: "DaleCo Help Desk" <daleco@daleco.biz> To: "FreeBSD Questions" <freebsd-questions@FreeBSD.ORG>, "joe" <joe-dated-1036562434.640dd6@dubium.com> Subject: Re: SSH Delay problems Message-ID: <01d601c281b7$c4ec1640$fa00a8c0@DaleCoportable> References: <200210312158.47996.joe@dubium.com>
next in thread | previous in thread | raw e-mail | index | archive | help
From: "joe" <joe-dated-1036562434.640dd6@dubium.com> To: "FreeBSD Questions" <freebsd-questions@FreeBSD.ORG> Sent: Thursday, October 31, 2002 11:58 PM Subject: SSH Delay problems > I apologize for this repeat as I was following this issue on the last a > few months ago. I tried to find the thread but was not successfull. > > There is a significant delay before ssh connects and returns a prompt. > I am on a private network, attempting a 192.168.0.XXX 192.168.0.YYY > connection. There is a distinct 1:15 min delay before the password > prompt appears. I have included the log of a specific session. > > Each of the machines is represented in each other's hosts file > > 21:51:38.045289500 debug1: Server will not fork when running in > debugging mode. > 21:51:38.047896500 Connection from 192.168.0.1 port 1035 > 21:51:38.064663500 debug1: Client protocol version 2.0; client software > version OpenSSH_3.4p1 FreeBSD-20020702 > 21:51:38.074117500 debug1: match: OpenSSH_3.4p1 FreeBSD-20020702 pat > OpenSSH* > 21:51:38.074136500 debug1: Enabling compatibility mode for protocol 2.0 > 21:51:38.074146500 debug1: Local version string SSH-1.99-OpenSSH_3.5 > 21:51:38.077985500 debug1: permanently_set_uid: 22/22 > 21:51:38.080636500 debug1: list_hostkey_types: ssh-rsa,ssh-dss > 21:51:38.080652500 debug1: SSH2_MSG_KEXINIT sent > 21:51:38.082392500 debug1: SSH2_MSG_KEXINIT received > 21:51:38.082408500 debug1: kex: client->server aes128-cbc hmac-md5 none > 21:51:38.082418500 debug1: kex: server->client aes128-cbc hmac-md5 none > 21:51:38.175276500 debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received > 21:51:38.190669500 debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent > 21:51:38.254235500 debug1: dh_gen_key: priv key bits set: 136/256 > 21:51:38.274923500 debug1: bits set: 1663/3191 > 21:51:38.274941500 debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT > 21:51:38.274951500 debug1: bits set: 1572/3191 > 21:51:38.343734500 debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent > 21:51:38.344789500 debug1: kex_derive_keys > 21:51:38.345390500 debug1: newkeys: mode 1 > 21:51:38.345973500 debug1: SSH2_MSG_NEWKEYS sent > 21:51:38.346486500 debug1: waiting for SSH2_MSG_NEWKEYS > 21:51:38.384126500 debug1: newkeys: mode 0 > 21:51:38.384900500 debug1: SSH2_MSG_NEWKEYS received > 21:51:38.385463500 debug1: KEX done > 21:52:53.516241500 debug1: userauth-request for user joe service > ssh-connection method none > 21:52:53.517158500 debug1: attempt 0 failures 0 > 21:52:53.520349500 Failed none for joe from 192.168.0.1 port 1035 ssh2 > 21:52:53.521330500 Failed none for joe from 192.168.0.1 port 1035 ssh2 > 21:53:06.125032500 debug1: userauth-request for user joe service > ssh-connection method password > 21:53:06.126400500 debug1: attempt 1 failures 1 > 21:53:06.130573500 Accepted password for joe from 192.168.0.1 port 1035 > ssh2 > 21:53:06.133102500 Accepted password for joe from 192.168.0.1 port 1035 > ssh2 > 21:53:06.133122500 debug1: monitor_child_preauth: joe has been > authenticated by privileged process > 21:53:06.151826500 debug1: newkeys: mode 0 > 21:53:06.152826500 debug1: newkeys: mode 1 > 21:53:06.153577500 debug1: Entering interactive session for SSH2. > 21:53:06.154434500 debug1: fd 7 setting O_NONBLOCK > 21:53:06.155633500 debug1: fd 8 setting O_NONBLOCK > 21:53:06.155649500 debug1: server_init_dispatch_20 > 21:53:06.155658500 debug1: server_input_channel_open: ctype session > rchan 0 win 65536 max 16384 > 21:53:06.155669500 debug1: input_session_request > 21:53:06.156407500 debug1: channel 0: new [server-session] > 21:53:06.165227500 debug1: session_new: init > 21:53:06.166135500 debug1: session_new: session 0 > 21:53:06.166149500 debug1: session_open: channel 0 > 21:53:06.166158500 debug1: session_open: session 0: link with channel 0 > 21:53:06.166168500 debug1: server_input_channel_open: confirm session > 21:53:06.166916500 debug1: server_input_channel_req: channel 0 request > pty-req reply 0 > 21:53:06.170842500 debug1: session_by_channel: session 0 channel 0 > 21:53:06.170860500 debug1: session_input_channel_req: session 0 req > pty-req > 21:53:06.170870500 debug1: Allocating pty. > 21:53:06.170880500 debug1: session_new: init > 21:53:06.170888500 debug1: session_new: session 0 > 21:53:06.172490500 debug1: session_pty_req: session 0 alloc /dev/ttyp1 > 21:53:06.181828500 debug1: server_input_channel_req: channel 0 request > shell reply 0 > 21:53:06.186718500 debug1: session_by_channel: session 0 channel 0 > 21:53:06.186736500 debug1: session_input_channel_req: session 0 req > shell > 21:53:06.186747500 debug1: fd 4 setting TCP_NODELAY > 21:53:06.186756500 debug1: channel 0: rfd 10 isatty > 21:53:06.186764500 debug1: fd 10 setting O_NONBLOCK > 21:53:06.188922500 debug1: Setting controlling tty using TIOCSCTTY. > > -------------------------------------------------------- > Joe Sotham > -------------------------------------------------------- > Christianity got over the difficulty of furious opposites > by keeping them both and keeping them furious. > - G.K. Chesterton Eliminating the possibility of "DNS problems" should be easy. If it is a routing/network/DNS issue, it should show up with slow connections to other services as well. Open up a couple daemons on one box and test. What about ping? Is it OK? What does "netstat -r" say? etc., etc., etc., In reading the contents of the log, it appears that it COULD be routing/network/DNS, but also that it could be incorrect config of the requesting machine. The logging machine doesn't seem to grok the type of authentication to be used in establishing the session. I'd maybe ask for help on -security, but I don't know. It's quieted down a bit there recently, and they seem to think it's only for "drastic" announcements. If I were more of a crypto genius, I'd try and give more help.... KDK To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?01d601c281b7$c4ec1640$fa00a8c0>