... if I enter my password and the client allows the connection, then it has authenticated the server.
Neither password based nor key based authentication of the client against the server will somehow authenticate the server. This is also true if the client's private key is protected by a password: the password will only be used locally on the client to use the private key on the client, but has nothing to do with successful or unsuccessful server authentication.
In other words: not properly authenticating the server opens you up to server impersonation or man in the middle attacks, no matter which client authentication method is used.
... a private password. I am not familiar with the internals of SSH, but I would hope that the password challenge goes in both directions when both sides share the same common secret.
That's not how password authentication in SSH works. With password authentication the server simply gets the password from the client and then checks it against the local (to server) authentication mechanism. Typically the password is not even known server side for checking it, but only a password hash is known. And maybe not even this, because the server might use an authentication backend like PAM, LDAP or Radius.
So when the client does not properly authenticate the server in this case, then the wrong server (attacker) might end up with the client's password and can use it against the real server.
A real shared common secret would be Pre-Shared Key, as known from WPA-PSK, IPSec or PSK authentication in TLS. In this mode the authentication can only succeed if both client and server know the same secret, but without some man in the middle able to sniff the secret. But PSK based authentication is not defined for SSH.