Does ssh send the password over the network?
Yes. The password is sent over the encrypted connection, but it's in plaintext to the remote server.
The usual way to authenticate is for the server to calculate a hash of the password and to compare it to a value saved on the server. There are several ways of saving hashes, and with current implementations, the client doesn't know what the server uses. (see e.g. the crypt man page). (Even if it did, simply sending a hash of the password would make the hash equivalent to the password anyway.)
Also, if the server uses PAM, the PAM modules might implement authentication with just about any method, some of which may require the password in plaintext.
Authentication using public keys doesn't send the key to the remote host, however. (Some explanation and links about this in a question on security.SE)
There are also password-based authentication algorithms like SRP, that don't require sending the password in plain text to the other end. Though SRP appears to be only implemented for OpenSSH as an external patch.
If you're using password authentication, then SSH sends the password over the network. The connection is encrypted, so eavesdroppers can't see the password. The connection is authenticated, provided that you don't click blindly through a “The authenticity of … can't be established” message, so your password won't be sent to anyone except the legitimate server.
The boring answer to “why” is that this is what the SSH protocol requires.
The less boring answer is that password authentication has to work that way. There are ways to perform authentication that don't work this way but this is no longer simple password authentication.
Most authentication protocols that are more advanced than simple password authentication have the nice property that the client doesn't send any secret data to the server that a malicious server could use to impersonate the user on some third server. With SSH public key authentication, the most common SSH authentication method other than passwords, this works because the client sends a signature (requiring the private key) of data that includes the session identifier; if the malicious server tried to authenticate to a third server, it would have to generate a signature of data including a different session identifier, which it would be unable to do without the private key that stays on the client.
Note that if you use public key authentication, and you have to type a password to use the key, this is not password-based authentication. The password to use the key is used exclusively on the client side, to read the key from the key file. When using public key authentication, the server does not know or care whether the key was stored in an encrypted file.
Password authentication requires sending the password to the server. Sending a hash of the password instead of the password itself does not help, because then the password becomes the hash: an attacker wouldn't need to find the actual password, only the hash. An attacker could attack by finding the actual password, so there is no improvement. But if the attacker found the hash but not the password, in your proposed scheme, that would be enough. In contrast, with normal password-based authentication, the attacker must know the password, knowing the hash is not good enough, and if the password is strong enough then the attacker won't be able to find the password from the hash. In practice, the reason the attacker might know the hash but not the password is that the attacker managed to extract the database of password hashes from the server, possibly from an unprotected backup or via a vulnerability on the server. Such vulnerabilities on websites make the news pretty often.
Your proposed protocol is less good than the standard one. Don't roll your own crypto!
Yes, ssh sends the password over the network, but after end-to-end encryption has been negotiated. See section 8 of RFC 4252 which says that a password authentication message contains plaintext password in ISO-10646 UTF-8 encoding [RFC3629]