Neither scheme, as described, is secure against man-in-the-middle attacks. In particular, an attacker who wants to impersonate the client can simply relay the server's challenge to the real client, pretending to be the server, and then relay the real client's reply to the server. After that, they're free to keep pretending to be the client.
However, scheme B can be rather trivially modified into a simple key-exchange protocol that does protect against such an attack. Specifically, instead of sending the random number back to the server in the plain, the client should use it (or something derived from it, using a KDF) as the key for a symmetric (authenticated) encryption scheme, and encrypt all subsequent communications with the server using that key. Thus, the server can be confident that any messages encrypted with this key really come from the same client that successfully decrypted the original encrypted key — effectively, the two parties have established a secure channel.
Of course, the scheme still only authenticates the client to the server, but not the server to the client.* A simple way to fix this would be to provide the server with a private signing key, whose corresponding public key is known to the client, and have the server sign the initial message after** encrypting it with the client's public key.
Alternatively, you could have both the client and the server generate a random secret number, encrypt them with each other's public key, exchange them, and then hash the two numbers together to derive a shared key for symmetric encryption. This takes an extra message from the client to the server, but avoids the need for signatures. And you can eliminate the extra message overhead by cleverly combining messages: as soon as one party has received the other's random number, they can combine it with their own random number to generate the symmetric key, and start using it to transmit actual data even in the same message that also carries their own random number.
(Yet another option, if you want to have a mutually authenticated secret channel using only signature keys, would be to use something like Diffie–Hellman to first establish an anonymous secure channel, and then have both parties sign (a hash of) the D-H shared secret and exchange the signatures, thereby confirming both their identity, and also the fact that they're really talking over the same encrypted channel, with no middle-man attacker in between.)
*) I'm following your usage of the names "client" and "server" here, even though they're kind of backwards from the usual case. Typically, it's the client that initiates the communication, and knows the server's public key, rather than vice versa.
**) The reason why you need to sign after encryption is to prevent another MitM attack, where the attacker impersonates the server by first connecting to the real server as a client, obtaining a signed key, decrypting it and re-encrypting it with the target client's public key, and passing it on to the target client.
