1. The receiver send the sender a random text string. The sender concatenates this string with his private data and sends the SHA1 back. The receiver then does the same and compares the results;
This is vulnerable to a man-in-the-middle attack: when the receiver sends the sender a random string N1, Mallory (the attacker) intercepts this request and forwards it to the sender. The sender replies SHA1(N1||K)†, which Mallory also intercepts and forwards to the receiver. The receiver now thinks Mallory knows the secret.
If the receiver and the sender are both willing to initiate the protocol (from their point of view) with anyone (which is presumably the case, since we're assuming the receiver trusts nothing about the sender initially), then Mallory does not need to intercept any communication. Mallory merely needs to ask the receiver to send a random string (pretending to be a sender), then forward that string to the sender (pretending to be a receiver) and continue being a man-in-the-middle without needing to have any control over the network.
If the participants are symmetric in this setting, specifically if the receiver can also act as a sender, then Mallory may forward the receiver's request to itself, so Mallory may be able to pretend to know the secret even though only the receiver is present.
2. The sender creates a random text string, concatenates it with the private data and sends both the random text string and the SHA1 of the concatenation to the receiver.
This protocol is as vulnerable to a man-in-the-middle attack as the previous one.
Additionally, this protocol is vulnerable to a replay attack. Eve (the attacker) eavesdrops on one message sent by a sender. Eve later sends that message again, and the receiver will accept it. The first protocol is not vulnerable to such an attack, provided the receiver never sends the same random text twice.
You can protect against a passive replay attack by having the receiver never accept the same random text twice. The protocol would still be vulnerable to a man-in-the-middle attack; an attacker who is not capable of suppressing packets could nonetheless exploit an accidental packet loss.
You are looking to prove that the sender knows a shared secret that is known to a receiver. This is an authentication problem, not a key exchange problem. Your protocol 1 is at heart a challenge-response protocol. What you're missing is a way to tie the challenger and the responder to their respective roles: if your protocol 1 completes successfully, all the challenger knows is that a responder is present. You are presumably performing this protocol in order to exchange data between the two parties; how are you going to do this?
You can salvage this approach if you realize that it doesn't matter if Mallory is relying packets, provided that you do not consider “who am I connected to” to be trustworthy. In other words, let Mallory participate all she wants, but ensure that she can only relay the actual conversation, not change messages. Then Mallory is no longer more than a router.
You can do that if you authenticate each and every message in the conversation; including the HMAC of each message (using the shared secret as the key) is a good way to do that. Authenticating each message is not sufficient: all it proves is that a participant knowing the shared secret once sent such a message. Each message must also contain a reliable indication of its place in the conversation. In broad terms, a good way to do that is to have each side include a random string as part of their first message (to protect against replay attacks), and include a digest of message N in message N+1.
(Final warning: as usual, this message is for discussion only. I do not condone writing your own protocols. As a practical matter, use a well-known, generally-approved protocol such as SSL/TLS or PGP/GPG-signed email.)
† This is not the right cryptographic operation to use here. You're looking for a message authentication code; SHA1 of a concatenation is close but not good enough.