From owner-freebsd-current Tue Jul 9 9:46:47 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E40737B418 for ; Tue, 9 Jul 2002 09:46:44 -0700 (PDT) Received: from horsey.gshapiro.net (horsey.gshapiro.net [209.220.147.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1B0743E54 for ; Tue, 9 Jul 2002 09:46:42 -0700 (PDT) (envelope-from gshapiro@gshapiro.net) Received: from horsey.gshapiro.net (gshapiro@localhost [IPv6:::1]) by horsey.gshapiro.net (8.12.5.Beta0/8.12.5.Beta0) with ESMTP id g69GkfdN056482 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 9 Jul 2002 09:46:41 -0700 (PDT) Received: (from gshapiro@localhost) by horsey.gshapiro.net (8.12.5.Beta0/8.12.5.Beta0/Submit) id g69GkesH056479; Tue, 9 Jul 2002 09:46:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15659.4976.851650.646333@horsey.gshapiro.net> Date: Tue, 9 Jul 2002 09:46:40 -0700 From: Gregory Neil Shapiro To: Dag-Erling Smorgrav Cc: "Andrey A. Chernov" , current@FreeBSD.ORG Subject: Re: PasswordAuthentication not works in sshd In-Reply-To: References: <20020702114530.GB837@nagual.pp.ru> <20020709124943.GA15259@nagual.pp.ru> <20020709133611.GA17322@nagual.pp.ru> X-Mailer: VM 7.03 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >> Normally OPIE not accepts plain Unix password remotely, and it is right, >> because of cleartext. But it is wrong for sshd, because no cleartext >> sended for PasswordAuth. It seems that opieaccess in pam.d/sshd should not >> fails by default or maybe even not present there. des> What if the client is untrusted? Do you find it reasonable to allow des> users to type their password on an untrusted client? Many of our des> users use OPIE for precisely this scenario - reading their mail on an des> untrusted machine in the USENIX terminal room. Interestingly enough, pam_opieaccess doesn't help at all in this situation. The remote user is still prompted for their plain text password, it just isn't accepted. However, the damage is already done -- a compromised ssh client would have already recorded the password typed in. For opie_access to be of any use, it would have to print a warning telling users not to type in their plain text password and cause ssh not to ask for that password after the OTP queries fail (effectively, disable password as one of the authentication techniques early on). Also, pam_opieaccess is broken at the moment anyway as /usr/src/contrib/opie/libopie/accessfile.c is not compiled with PATH_ACCESS_FILE defined. The maintainer of OPIE should add: #define PATH_ACCESS_FILE "/etc/opieaccess" to /usr/src/contrib/opie/opie_cfg.h. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message