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