Could someone clarify if this is correct?
Yes, it is correct that the password is known to the server in plain text. RFC 4252, section 8 specifies the "Password Authentication" for SSH, and it writes (freely cited):
Note that [...] the cleartext password is transmitted in the packet [...].
I also wanted to provide an answer, not on the question itself, but on
Can you design a protocol which doesn't send the server the password or values equal to the password?
The answer to that is Yes.
You should ensure your protocol does the following:
- (more part of the implementation) The user has to have some means to confirm they aren't telling the password to the server. The smartest protocol is meaningless if the server can bypass it with displaying an text entry it can get the content of. This is a problem if your application is just a bare remote terminal, and the authentication is happening already during this "remote terminal mode", or if the server can "fake accept" the connection without a password entry, and then display its own. Another example would be a website with a html form. The http digest auth "dialog window pop ups" is designed with this problem in mind.
- You should use a challenge response protocol like SCRAM or SRP. If your password enrollment is designed in a way you don't provide a key to the server (or you trust the server at enrollment time, like in your example), both of them don't give values to the server they can use for login at other servers with the same password. For SCRAM, your salts have to be unique per server, SRP relieves you from that duty.
- You should use encryption together with Channel binding between your encryption layer and your challenge response layer. This will make infected servers not be abled to play "man in the middle" to a targeted server for the authentication part of the connection, then do their evil business after it. SRP supports this by its nature as its a key exchange protocol, and the official SCRAM RFC has support for channel binding too.
However, this is a mostly theoretical discussion. You should use ssh keys wherever possible, because they offer much better brute-force protection.