From owner-freebsd-security@FreeBSD.ORG Thu Sep 5 18:43:13 2013 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2C7988C0; Thu, 5 Sep 2013 18:43:13 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id DC2FF27E6; Thu, 5 Sep 2013 18:43:12 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1VHeYP-00099F-Dc; Thu, 05 Sep 2013 22:45:17 +0400 Date: Thu, 5 Sep 2013 22:45:17 +0400 From: Slawa Olhovchenkov To: Dag-Erling Sm??rgrav Subject: Re: OpenSSH, PAM and kerberos Message-ID: <20130905184517.GB34714@zxy.spb.ru> References: <20130903083301.GF3796@zxy.spb.ru> <86y57euu8y.fsf@nine.des.no> <20130903093756.GG3796@zxy.spb.ru> <86ppsqutw7.fsf@nine.des.no> <20130903095316.GH3796@zxy.spb.ru> <86li3euovr.fsf@nine.des.no> <20130903115050.GJ3796@zxy.spb.ru> <864na2ujh7.fsf@nine.des.no> <5010498171.20130903174620@serebryakov.spb.ru> <86r4d6t2hl.fsf@nine.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86r4d6t2hl.fsf@nine.des.no> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: freebsd-security@FreeBSD.org, Lev Serebryakov X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 18:43:13 -0000 On Tue, Sep 03, 2013 at 04:16:06PM +0200, Dag-Erling Sm??rgrav wrote: > Lev Serebryakov writes: > > "Dag-Erling Sm??rgrav" writes: > > > Actually, sshd already does most of this by farming PAM out to a > > > child process. > > And, IMHO, proper way to fix this bug is to fix it here, as "most of > > things" is already done. > > Feel free to submit patches. Now I found next strange behaviour: for account with not found login class sshd refuse GSSAPIAuthentication. Telnet don't do this strange restriction. (I use login class 'me' in Kerberos/NIS setup).