Date: 24 Dec 2005 14:42:00 -0500 From: Lowell Gilbert <freebsd-stable-local@be-well.ilk.org> To: James Tanis <jtanis@pycoder.org> Cc: stable@freebsd.org, "Michael A. Koerber" <mak@ll.mit.edu> Subject: Re: SSH login takes very long time...sometimes Message-ID: <44oe36p9iv.fsf@be-well.ilk.org> In-Reply-To: <65dcde740512231426u199dea1aob6c54b89056c7a82@mail.gmail.com> References: <43ABF6E4.2090908@ll.mit.edu> <001301c607c4$e04e2540$80cea8c0@home1> <43AC0160.4070108@kernel32.de> <44irtf3mxr.fsf@be-well.ilk.org> <65dcde740512231426u199dea1aob6c54b89056c7a82@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Don't top-post, please. James Tanis <jtanis@pycoder.org> writes: > On 23 Dec 2005 09:30:56 -0500, Lowell Gilbert > <freebsd-stable-local@be-well.ilk.org> wrote: > > Marian Hettwer <MH@kernel32.de> writes: > > > > > Hej there, > > > > > > Kobi Shmueli wrote: > > > > 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). > > > > > > > alternativly to check out wether it's dns related, you use set the > > > Option "UseDNS no" in your sshd_config, so sshd won't try a reverse > > > dns lookup. > > > Give it a shoot. Usually ssh timeouts are related to DNS... > > > > That should be a last resort; the hostname checks are there for a > > reason... > What reason is that? A reverse-lookup is no longer really a valid way > of filtering out the undesireable unless your lucky enough to be > dealing only with those who have the knowledge and ability to control > those entries. [It doesn't filter anybody out; the DNS lookup will time out and the user can log in anyway.] What it does is helps you to know who you're dealing with. The fact that only the people who are *really* responsible for the IP delegation can control the reverse entry is a feature, not a bug. > Most residential ips either have no reverse-lookup or > it's set to some long painful textual conglomeration devised by the > isp (although at the isp I work at we will set it per some users > requests..). It doesn't matter *what* it is, just that there is one. And remember that you are not matching a forward mapping to a reverse one, but the other way around. It's fine if you use a host name that doesn't match your reverse name mapping, as long as the reverse name mapping gives a hostname that in turn points to you. > Anyway, to make a long story short, you end up locking > out or at the very least delaying (for up to several minutes) the very > people who use it. I can definately see the sysadmin side of it though > were its used perhaps to remotely access a data center from a > satellite location -- you don't much want or care that a residential > ip has problems connecting to the server. It just definately doesn't > seem to me a "last resort" option, at the drop of a hat someone can > change their hostname to match their reverse dns and back again -- As I explained earlier, that's not the check that is being made. > setting up a good packet filter to filter out all but the desired ip > ranges seems a much more reliable method. They are not exclusive.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44oe36p9iv.fsf>