CBHacking's answer is correct: just use TLS.
That said, hashing the password before sending, as you described, is a good step. This has saved my neck before when someone in school thought they were cool, did a passive intercept, and deleted half of a forum that I was an admin on (I was 17 and the free forum host did not offer HTTPS). The attackers got stuck when they didn't have the admin password to enter the admin panel (a million kudos to SMF Forums for implementing the hashing and extra password check).
Now consider this: you send the password hashed, but an attacker can observe the hash being sent. They do not know the original password, but they can replay the request. They can just send whatever you sent, and the server will accept it.
So another step is to make this a challenge-response system. This is what a lot of protocols use, for example NFC: the card (also known as 'tag') will generate a challenge and the reader has to respond correctly before being allowed to read the tag. This can be a secure authentication system.
You should also use slow hashing, such as Scrypt or Argon2 if possible. See: How to securely hash passwords? This makes it harder for an attacker to attack your password hash.
Next, you should encrypt and sign the traffic: it's great that you can authenticate securely, but an attacker can still modify the commands you are sending and see the data you are transmitting. Something like AES-GCM does both, or if you want to do it with more traditional methods, AES-CTR with HMAC is a common choice. You could use the solution to the challenge-response system as password, and instead of submitting the response, you encrypt the text "correctpassword" (or something like that) and send that to the server. If the server can decrypt it correctly, it knows that you had the right password.
Finally, an attacker can still do a replay attack: you have a good login, you have encrypted requests, you sign the requests... but what if an attacker just replays a random request? The server does not know that it is invalid. Therefore, you should include a sequence number on both sides (from the client to the server and vice versa).
You know what you just did? You just re-implemented a large part of TLS, basically the part after the key exchange. Now think of the history of vulnerabilities that TLS has had, which is huge, despite having experts working on it. It is fun to thinker with this sort of thing, but please do not use it for anything that matters! I'm just answering the question because it's interesting stuff, at least to me, not because I think you should actually use this in production! :)