All, I have three machines that have had 5.4 and 6.0 installed. Two of the three machines have very well behaved "ssh". However, the machine (laptop) named OBOE does not. Specifically "ssh oboe" will (most of the time) hang for around one minute before asking for a prompt. However, if I'm logged into OBOE and "ssh BSD" (one of the other machines) a password is requested within a couple seconds. (I said most of the time, since on occasion I can reboot OBOE and ssh will work just fine...hmmm.) I have looked through the /var/log files for clues and skimmed "man ssh" for time out related stuff, but no luck. Where should I start looking for clues? All machines have had clean installs from "newfs'd" drive under both 5.4 and 6.0 so I'm sure no left over configs are getting propagated. -- --------------------- Dr Michael A. Koerber x3250
On 12/23/05, Michael A. Koerber <mak@ll.mit.edu> wrote:> All, > > I have three machines that have had 5.4 and 6.0 installed. Two of the three machines have very > well behaved "ssh". However, the machine (laptop) named OBOE does not. > > Specifically "ssh oboe" will (most of the time) hang for around one minute before asking for a > prompt. However, if I'm logged into OBOE and "ssh BSD" (one of the other machines) a password is > requested within a couple seconds. (I said most of the time, since on occasion I can reboot OBOE > and ssh will work just fine...hmmm.) > > I have looked through the /var/log files for clues and skimmed "man ssh" for time out related > stuff, but no luck. > > Where should I start looking for clues? >Most probably it's a reverse dns issue. You can either check your dns/hosts setup or tcpdump the traffic when you try to login a machine. -- Joao Barros
Michael A. Koerber wrote:>All, > > I have three machines that have had 5.4 and 6.0 installed. Two of the three machines have very >well behaved "ssh". However, the machine (laptop) named OBOE does not. > > Specifically "ssh oboe" will (most of the time) hang for around one minute before asking for a >prompt. However, if I'm logged into OBOE and "ssh BSD" (one of the other machines) a password is >requested within a couple seconds. (I said most of the time, since on occasion I can reboot OBOE >and ssh will work just fine...hmmm.) > > I have looked through the /var/log files for clues and skimmed "man ssh" for time out related >stuff, but no luck. > > Where should I start looking for clues? > > All machines have had clean installs from "newfs'd" drive under both 5.4 and 6.0 so I'm sure no >left over configs are getting propagated. > >Check your DNS (or reverse DNS really) on the laptop (OBOE). Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------
Michael A. Koerber wrote:> I have three machines that have had 5.4 and 6.0 installed. Two of thethree machines have very> well behaved "ssh". However, the machine (laptop) named OBOE does not. > > Specifically "ssh oboe" will (most of the time) hang for around oneminute before asking for a> prompt. However, if I'm logged into OBOE and "ssh BSD" (one of the othermachines) a password is> requested within a couple seconds. (I said most of the time, since onoccasion I can reboot OBOE> and ssh will work just fine...hmmm.) > > I have looked through the /var/log files for clues and skimmed "man ssh"for time out related> stuff, but no luck. > > Where should I start looking for clues?Try checking /etc/resolv.conf on oboe first, adding a static entry to /etc/hosts of the remote ip/host should speed dns checks as well. You can also run ssh in verbose mode (ssh -v oboe) or/and run sshd in debug mode (sshd -d). -Kobi.
For whatever reason, I have had a similar problem which was solved by entering the machines that you are logging in from into the hosts file. I'm guessing it attempts a reverse lookup and your (as well as my) dns/hostname does not match its reverse lookup entry. On 12/23/05, Michael A. Koerber <mak@ll.mit.edu> wrote:> All, > > I have three machines that have had 5.4 and 6.0 installed. Two of the three machines have very > well behaved "ssh". However, the machine (laptop) named OBOE does not. > > Specifically "ssh oboe" will (most of the time) hang for around one minute before asking for a > prompt. However, if I'm logged into OBOE and "ssh BSD" (one of the other machines) a password is > requested within a couple seconds. (I said most of the time, since on occasion I can reboot OBOE > and ssh will work just fine...hmmm.) > > I have looked through the /var/log files for clues and skimmed "man ssh" for time out related > stuff, but no luck. > > Where should I start looking for clues? > > All machines have had clean installs from "newfs'd" drive under both 5.4 and 6.0 so I'm sure no > left over configs are getting propagated. > -- > --------------------- > Dr Michael A. Koerber > x3250 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >-- James Tanis jtanis@pycoder.org http://pycoder.org
Hi, I had submitted a bin/62139 PR because of the same problem about a year ago. I still think there is a bug somewhere in a resolver(3) library or in libc functions like gethostbyname(). Because of this bug the gethostbyname() doubles the number of its reverse resolving requests, in a case the DNS server isn't responding. The other reason for very long waiting is a default configuration of resolver(5). In most other systems RES_DFLRETRY is defined as 2, but in FreeBSD it is defined as 4. In a case the DNS server isn't responding the gethostbyname() makes 8 (eight!) reverse resolving attempts for one (!) non-responding DNS server before it returns error. And this is by default. All that is still true for my current 6.0-STABLE. http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/62139 As a workaround I may suggest addind "options attempts:2" or even "options attempts:1" line to the /etc/resolver.conf