From owner-freebsd-stable@FreeBSD.ORG Sat Dec 24 19:42:02 2005 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9529916A41F for ; Sat, 24 Dec 2005 19:42:02 +0000 (GMT) (envelope-from freebsd-stable-local@be-well.ilk.org) Received: from mail1.sea5.speakeasy.net (mail1.sea5.speakeasy.net [69.17.117.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id D904F43D49 for ; Sat, 24 Dec 2005 19:42:01 +0000 (GMT) (envelope-from freebsd-stable-local@be-well.ilk.org) Received: (qmail 5711 invoked from network); 24 Dec 2005 19:42:01 -0000 Received: from dsl092-078-145.bos1.dsl.speakeasy.net (HELO be-well.ilk.org) ([66.92.78.145]) (envelope-sender ) by mail1.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 24 Dec 2005 19:42:00 -0000 Received: by be-well.ilk.org (Postfix, from userid 1147) id 11C4128423; Sat, 24 Dec 2005 14:42:00 -0500 (EST) Sender: lowell@be-well.ilk.org To: James Tanis References: <43ABF6E4.2090908@ll.mit.edu> <001301c607c4$e04e2540$80cea8c0@home1> <43AC0160.4070108@kernel32.de> <44irtf3mxr.fsf@be-well.ilk.org> <65dcde740512231426u199dea1aob6c54b89056c7a82@mail.gmail.com> From: Lowell Gilbert Date: 24 Dec 2005 14:42:00 -0500 In-Reply-To: <65dcde740512231426u199dea1aob6c54b89056c7a82@mail.gmail.com> Message-ID: <44oe36p9iv.fsf@be-well.ilk.org> Lines: 61 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: stable@freebsd.org, "Michael A. Koerber" Subject: Re: SSH login takes very long time...sometimes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stable@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2005 19:42:02 -0000 Don't top-post, please. James Tanis writes: > On 23 Dec 2005 09:30:56 -0500, Lowell Gilbert > wrote: > > Marian Hettwer 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.