From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 8 14:19:36 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A0BCB16A4BF for ; Mon, 8 Sep 2003 14:19:36 -0700 (PDT) Received: from episec.com (episec.com [198.78.65.141]) by mx1.FreeBSD.org (Postfix) with SMTP id ED8C143FAF for ; Mon, 8 Sep 2003 14:19:35 -0700 (PDT) (envelope-from edelkind-freebsd-hackers@episec.com) Received: (qmail 27593 invoked by uid 1024); 8 Sep 2003 21:17:10 -0000 Date: Mon, 8 Sep 2003 17:17:10 -0400 From: ari To: freebsd-hackers@freebsd.org Message-ID: <20030908211710.GH11860@episec.com> Mail-Followup-To: ari , freebsd-hackers@freebsd.org References: <3F589E94.1080508@xwave.com> <20030905154646.GA59881@rot13.obsecurity.org> <20030906213428.GF29217@spc.org> <3F5A8FDB.3050507@newsguy.com> <20030907015510.GG29217@spc.org> <20030908202727.GA49862@titan.klemm.apsfilter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030908202727.GA49862@titan.klemm.apsfilter.org> Subject: Re: PUzzling sshd behaviour X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2003 21:19:36 -0000 andreas@freebsd.org said this stuff: > On Sun, Sep 07, 2003 at 02:55:10AM +0100, Bruce M Simpson wrote: [...] > > > >But what about: > > > > VerifyReverseMapping > > > > Specifies whether sshd should try to verify the remote host > > > > name > > > > and check that the resolved host name for the remote IP > > > > address > > > > maps back to the very same IP address. The default is ``no''. [...] > > This sounds like a bug. Does anyone else agree? > > Yes and I really needed this functionality in a project for 12 Suns... > > But it didn't work as expected from the description. It's a common misconception that this option means the server should not attempt a reverse lookup. It doesn't. If the VerifyReverseMapping option is enabled, then after the server does a reverse lookup, it will then ensure that the hostname maps back to the same ip address that is associated with the socket, useful mainly for banning networks with lackluster admins or attackers who try to feign domain ownership using only reverse dns. The initial part of the description is a bit misleading, but the fact that setting this option to 'no' does not disable reverse lookups is not a bug. ari