The problem is, ssh daemon doesn't know anything about user password. It uses existing libraries to supply login and password in clear form (like Linux PAM) and they check if it's valid. How this check is done, is abstracted too: it could be /etc/shadow file lookup, it could be LDAP request or really anything.

On the other side, it could be possible to create sshd implementation which will use its own user database. But it's probably not convenient.

->ssh daemon doesn't know anything about user password

And neither should it. auth system creates a one time usable "ticket" which is a one way function of the user password and a nonce. The server gives the nonce to the user, who creates his own ticket based on the nonce and his password, gives his ticket to the server, which then checks if the two tickets match, if they do -> authenticated. -> at no point is the actual user password transmitted.

Kerberos extends this further (allows authentication across multiple servers with a single login)

But as far as I know the ticketing system is standard ssh protocol.

Looking at the spec however: https://tools.ietf.org/html/rfc4252#page-10

It appears I am not correct.

might be SSHv2

The ssh auth protocol is extensible, the client and server negotiate which methods they support, so it is possible to implement new methods.

What system are you thinking of? Which works with existing crypt(3) based system used on Unix?

If you are willing to tell anyone who connects your salt, you could, in principle, run a balanced PAKE using the crypt output.

You could go one step further and have the server store an augmented PAKE authenticator derived from the crypt(3) output.

Here's half an answer: Kerberos.

Which SSH does support, btw.