wow. im not sure i believe this...
there is no need to send the password to the server to authenticate a password in this day and age. i thought ssh was one of the first protocols to not do this.
there is no need to send the password to the server to authenticate a password in this day and age. i thought ssh was one of the first protocols to not do this.
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.
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
You could go one step further and have the server store an augmented PAKE authenticator derived from the crypt(3) output.
Which SSH does support, btw.