This is with openssh-2.5.1p1-7.  I haven't tested with 2.5.2p2, but it
looks from the source code that the problem will still be there.

Changing PasswordAuthentication to no in /etc/ssh/sshd_config does not
preclude logging in using an encrypted clear-text password as it should
when ssh protocol version 2 is used because ssh falls back to an
authentication method called "keyboard-interactive" which also allows
plain-text passwords to be used.

Turning off KbdInteractiveAuthentication doesn't work either because
openssh turns it back on if challenge-response authentication is enabled.

This is easy to reproduce.  Install openssh-* on a server and use the
default /etc/ssh/sshd_config.  As a user with no .ssh directory, ssh to
that server with

ssh -2 -v server

In my case, my login is ejb and my server is gwendolyn.ql.org.

The last few lines preceding the password prompt are as follows:

debug: authentications that can continue:
publickey,password,keyboard-interactive
debug: next auth method to try is publickey
debug: key does not exist: /home/ejb/.ssh/id_dsa
debug: next auth method to try is password
ejb.org's password: 

Notice that publickey, password, and keyboard-interactive are all listed as
valid authentications.  Now, if you change /etc/ssh/sshd_config to say 

PasswordAuthentication no
KbdInteractiveAuthentication no

and restart sshd (with /etc/rc.d/init.d/sshd restart) you get this:

debug: authentications that can continue: publickey,keyboard-interactive
debug: next auth method to try is publickey
debug: key does not exist: /home/ejb/.ssh/id_dsa
debug: next auth method to try is keyboard-interactive
Password: 

Note that password is gone as a valid method, but keyboard-interactive is
still there.  At this point, typing ejb.org's password works.

A quick read of the source shows that the problem is that
keyboard-interactive authentication is always forcibly enabled, overriding
whatever is in the configuration file, if challenge-response authentication
is enabled.  It is therefore necessary to also turn set

ChallengeResponseAuthentication no

in order to disable use of ordinary passwords.  Turning all three of these
off does in fact do the trick.

Being able to disable password authentication on the server is very
important.  Without this, someone who knows another user's password can ssh
in as that user.  With this, you can require that the user knows the
password on the private key and has a copy of said key -- much tighter
especially when firewalls are concerned.  I am fully aware that no password
is ever sent in the clear across the network, but I still think this is an
important security issue.

The documentation gives no clue as to the fact that keyboard-interactive
authentication could be used for anything other than s/keys.  It also
appears, though I have not tested or attempted to verify this, that it
would currently be impossible to allow s/key authentication but not plain
text password authentication.  Take that with a grain of salt though -- I
haven't studied the code carefully enough to be sure.

Note that this is a little harder than usual to find in the code because
the variable that controls challenge-response authentication is called 

challenge_reponse_authentication

In fact, this typo (reponse vs. response) is quite prevalent in the openssh
code.  One has to assume the use of emacs dynamic abbreviations -- one of
the most powerful typographical error propagation features there is. :-)

Seriously, if the ssh bug is too subtle to fix right, at the very least,
the comments in RedHat's sshd_config could mention that to fully disable
tunneled clear-text passwords, it is necessary to turn off
PasswordAuthentication, KbdInteractiveAuthentication, and
ChallengeResponseAuthentication.