Why hash ( clear text + Secret ) instead of hash (encrpt(clear text) [ + secret ] ) Here is an excellent article on how SSH Authentication and Encryption works.

While thinking about how MAC's work, I had the same doubt as one of the comments left on the post:

The client combines the decrypted number with the shared session key that is being used to encrypt the communication, and calculates the MD5 hash of this value. Any reason why the client combines the decrypted number with session key to calculate md hash? Why not calculate md hash directly for the decrypted value?

Is it just to avoid the negligible overhead of encrypting? 

(Which will any way get masked after hashing and add no protection or value--assuming the shared secret size makes no difference for the hashing function.)
There's a general principle in cryptographic protocols that every message should contain a value that depends on previous messages in the protocol. (This isn't an absolute rule, but it's usually the case.) Otherwise a man-in-the-middle might be able observe multiple runs of the protocol and combine parts of messages from different runs in unexpected ways.

I'm going by the description of the protocol on the tutorial you link to, which I think doesn't match the actual protocol (or is it SSH1? SSH2 uses the private key to sign, not to encrypt). The relevant steps are:


  3. If a public key with matching ID is found in the file, the server generates a random number and uses the public key to encrypt the number.
  4. The server sends the client this encrypted message.
  5. If the client actually has the associated private key, it will be able to decrypt the message using that key, revealing the original number.
  6. The client combines the decrypted number with the shared session key that is being used to encrypt the communication, and calculates the MD5 hash of this value.
  7. The client then sends this MD5 hash back to the server as an answer to the encrypted number message.  


In step 3, the server generates a nonce and encrypts it with the public key. In step 5, the client demonstrates that it possesses the private key by using it to decrypt the nonce. In step 7, the client sends a value to the server which demonstrates that it was able to decrypt the nonce.

Now consider an active man-in-the-middle, which the protocol is supposed to defend against. The MitM waits for the legitimate client to start a session to the legitimate server, but hijacks the messages so that the legitimate client is actually talking to the MiTM, and the MitM starts its own session with the legitimate server in parallel.


The legitimate server generates a nonce $N$ (step 3) and sends the encrypted nonce $E_{\mathrm{privkey}}(M)$ to the MitM (step 4).
The MitM receives the encrypted nonce and transmits that to the legitimate client instead of generating and encrypting its own nonce. (The MitM is an attacker, so it can cheat: it doesn't have to follow the protocol correctly.)
The legitimate client receives an encrypted nonce, decrypts it and generates a hash containing it $H(N || \ldots)$ (steps 5–7).
The MitM receives $H(N || \ldots)$ and sends that to the legitimate server.


If the hash only depended on the nonce, then the MitM would be able to send a value to the server that authenticated it as a client possessing the private key. This would be a bug in the protocol.

To avoid this attack, the hash also depends on the shared session key. This shared session key is generated by a Diffie-Hellman key exchange. The DH algorithm guarantees that the resulting key depends on inputs from both sides. Therefore the session key used between the MitM and the legitimate server is different from the session key used between the legitimate client and the MitM. Since the hash calculated at step 6 includes this session key, the proof of possession expected by the server at step 7 is different from every session, which prevents a man-in-the-middle from reusing the proof of possession from another session.