Again, I could well be wrong here, but: I believe the delay occurs when the ssh daemon cannot resolve the client IP address.
Updating the /etc/hosts file is the simplest way of ensuring that the client IP address is resolvable, but you could also use a DNS server. Just make sure that /etc/resolv.conf is up to date. Obviously you'll need to be running a DNS server somewhere for this to work! And it'll need to be configured with all of your client machines. I'm sure someone will jump in if I'm advising you wrongly! Regards Nick > -----Original Message----- > From: Doug Hite [mailto:[EMAIL PROTECTED] > Sent: 02 April 2003 16:15 > To: [EMAIL PROTECTED] > Subject: RE: [leaf-user] sshd taking too long ? > > > I added 192.168.3.50 to the hosts file, and this seems to > have eliminated the delay. Strange that the log at the > debug level did not show any errors. Is there a config > change in sshd that would eliminate the delay without > the need for me to put in every ip I might access my > router from in the hosts file ? > > thanks - doug > ======================= > >>> Nick Taylor <[EMAIL PROTECTED]> 03/31/03 03:25PM >>> > I seem to recall that this happens if the connecting machine > (the client) doesn't have an entry in the Bering machine's (the > host) /etc/hosts file. > > Have you made sure that: > > 192.168.3.50 > > exists in the /etc/hosts file on the Bering box? > > Regards > > Nick > ======================== > > > > Hello all - > > > > I am trying to troubleshoot my Bering 1.0 > > router install with sshd (from > > http://leaf.sourceforge.net/devel/jnilo/ ) > > The first time I try to connect with an ssh client > > it takes anywhere from 25 to 50 seconds. I can then > > immediately disconnect, and reconnect, and this time it does > > it almost immediately. I can leave it disconnected for a few hours, > > and then try again, and it will take 25 to 50 seconds to connect > > again. I have turned on the debugging - and have attached a > > sample of one of these long waits. I also included an entry > > that seems to be in the log about once per hour - where it > > is regenerating the RSA key. My working "guess" is that > > the long wait happens with the first connection after a new > > key has generated. Has anyone else had this problem ? > > I did look for an entry about reverse DNS lookup failing > > in the AUTH log, and did not find anything like that. Here > > is the log section- > > > > Mar 31 12:11:08 firewall sshd[30296]: Generating new 768 > bit RSA key. > > Mar 31 12:11:09 firewall sshd[30296]: RSA key generation complete. > > Mar 31 13:24:25 firewall sshd[9276]: Connection from > > 192.168.3.50 port 1509 > > Mar 31 13:24:25 firewall sshd[30296]: debug1: Forked child 9276. > > Mar 31 13:24:26 firewall sshd[9276]: debug1: Client protocol > > version 1.99; client software version 3.2.2 SSH Secure Shell > > for Windows > > Mar 31 13:24:26 firewall sshd[9276]: debug1: no match: 3.2.2 > > SSH Secure Shell for Windows > > Mar 31 13:24:26 firewall sshd[9276]: debug1: Enabling > > compatibility mode for protocol 2.0 > > Mar 31 13:24:26 firewall sshd[9276]: debug1: Local version > > string SSH-1.99-OpenSSH_3.5p1 > > Mar 31 13:24:26 firewall sshd[9276]: Failed none for root > > from 192.168.3.50 port 1509 ssh2 > > Mar 31 13:24:30 firewall sshd[9276]: Accepted password for > > root from 192.168.3.50 port 1509 ssh2 > > Mar 31 13:24:30 firewall sshd[9276]: debug1: > > monitor_child_preauth: root has been authenticated by > > privileged process > > Mar 31 13:24:30 firewall sshd[9276]: debug1: newkeys: mode 0 > > Mar 31 13:24:30 firewall sshd[9276]: debug1: newkeys: mode 1 > > Mar 31 13:24:30 firewall sshd[9276]: debug1: Entering > > interactive session for SSH2. > > Mar 31 13:24:30 firewall sshd[9276]: debug1: fd 3 setting O_NONBLOCK > > Mar 31 13:24:30 firewall sshd[9276]: debug1: fd 5 setting O_NONBLOCK > > Mar 31 13:24:30 firewall sshd[9276]: debug1: server_init_dispatch_20 > > Mar 31 13:24:30 firewall sshd[9276]: debug1: > > server_input_channel_open: ctype session rchan 0 win 10000 max 512 > > Mar 31 13:24:30 firewall sshd[9276]: debug1: input_session_request > > Mar 31 13:24:30 firewall sshd[9276]: debug1: channel 0: new > > [server-session] > > Mar 31 13:24:30 firewall sshd[9276]: debug1: session_new: init > > Mar 31 13:24:30 firewall sshd[9276]: debug1: session_new: session 0 > > Mar 31 13:24:30 firewall sshd[9276]: debug1: session_open: channel 0 > > Mar 31 13:24:30 firewall sshd[9276]: debug1: session_open: > > session 0: link with channel 0 > > Mar 31 13:24:30 firewall sshd[9276]: debug1: > > server_input_channel_open: confirm session > > Mar 31 13:24:30 firewall sshd[9276]: debug1: > > server_input_channel_req: channel 0 request pty-req reply 0 > > Mar 31 13:24:30 firewall sshd[9276]: debug1: > > session_by_channel: session 0 channel 0 > > Mar 31 13:24:30 firewall sshd[9276]: debug1: > > session_input_channel_req: session 0 req pty-req > > Mar 31 13:24:30 firewall sshd[9276]: debug1: Allocating pty. > > Mar 31 13:24:30 firewall sshd[9276]: debug1: session_pty_req: > > session 0 alloc /dev/ttyp0 > > Mar 31 13:24:30 firewall sshd[9276]: debug1: > > server_input_channel_req: channel 0 request shell reply 1 > > Mar 31 13:24:30 firewall sshd[9276]: debug1: > > session_by_channel: session 0 channel 0 > > Mar 31 13:24:30 firewall sshd[9276]: debug1: > > session_input_channel_req: session 0 req shell > > Mar 31 13:24:30 firewall sshd[9276]: debug1: fd 4 setting > TCP_NODELAY > > Mar 31 13:24:30 firewall sshd[9276]: debug1: channel 0: rfd 7 isatty > > Mar 31 13:24:30 firewall sshd[9276]: debug1: fd 7 setting O_NONBLOCK > > Mar 31 13:24:30 firewall sshd[15082]: debug1: Setting > > controlling tty using TIOCSCTTY. > > Mar 31 13:24:30 firewall sshd[9276]: debug1: > > server_input_channel_req: channel 0 request window-change reply 0 > > Mar 31 13:24:30 firewall sshd[9276]: debug1: > > session_by_channel: session 0 channel 0 > > Mar 31 13:24:30 firewall sshd[9276]: debug1: > > session_input_channel_req: session 0 req window-change > > Mar 31 13:24:58 firewall sshd[15082]: debug1: > permanently_set_uid: 0/0 > > > > ** notice the time is only a few seconds until that > > last step - 28 seconds. What is happening here ? > > addtional note : router is a Pentium 233 - 32 meg running > > from a 5 meg compact flash. > > 2 different ssh clients tested - they both seem to have the > > same wait issue. > > > > Doug > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: ValueWeb: > Dedicated Hosting for just $79/mo with 500 GB of bandwidth! > No other company gives more support or power for your dedicated server > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ > -------------------------------------------------------------- > ---------- > leaf-user mailing list: [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/leaf-user > SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html > ------------------------------------------------------- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
