Subject: ssh authentication methods
To: None <tech-userlevel@netbsd.org>
From: Jun-ichiro itojun Hagino <itojun@iijlab.net>
List: tech-userlevel
Date: 01/17/2001 22:09:55
	we have upgraded ssh/sshd base version to openssh 2.3.0.  between
	2.2.0 and 2.3.0, it seems that there's certain change in
	authentication logic.  in short, (if s/key authentication is turned
	on) you will almost always contacted with s/key fake login prompt.
	some people seem to get annoyed with it.

	jwise propsed to disable s/key authentication by default, for
	both client and server side.  by doing so we will not see extra fake
	s/key prompts (this assumes that larger portion of users do not have
	s/key configuration).  s/key authentication can be enabled by
	/etc/ssh*conf at ease.  does it sound acceptable thing to do?


	details below:

	first, note that, in ssh, s/key authentication is not part of unix
	login password authentication.  client asks for it explicitly, and
	server resonds.

	if client asks for s/key authentication then unix password
	authentication, the following things would happen.

	for s/key:
	(1) if there's no such account, present fake s/key login prompt.
	    so that we do not give attackers any hint about if the account
	    exists or not.
	(2) if the account is present and s/key is not configured, again, 
	    present fake s/key login prompt.  (same reason as 1)
	(3) if the account is present and s/key is configured, try real
	    s/key login prompt.
	for unix password:
	(a) if there's no such account, present fake unix login prompt.
	    so that we do not give attackers any hint about if the account
	    exists or not.
	(b) if the account is not present, present real unix login prompt.

	so, for a valid user with s/key setting, (3) + (b) happens
	(real s/key prompt and real unix password prompt).
	for a nonexistent user account, (1) + (a) happens (both fake prompt).

	for a valid user without s/key setting, (2) and (b) happens.  he will
	be presented a s/key fake login prompt, and then real unix password
	prompt.

	it is to hide the fact if we have the valid account under the name
	"itojun" or not, to attackers.  i believe the behavior reasonable,
	but it is a bit away from normal login(1) behavior.


itojun


example: root@localhost do not have s/key configuration.

>debug: Doing skey authentication.
>otp-md4 57 star17055			<--- fake s/key prompt
>Response:
>debug: Doing password authentication.
>root@localhost's password:		<--- real unix password prompt