A friend of mine managed to expose both id_rsa and id_rsa.pub file from his server via apache. I mentioned to him that this is serious security issue but he brushed this off like it was no big deal. Since I don't possess enough security knowledge to explain to him why this is bad can someone help me out here? Or maybe my friend is right and it is not as bad as I imagine it to be?
I suppose that these files are for "his SSH key" as a client.

Revealing the public key (id_rsa.pub) has no consequence: when we call it a public key we mean it. The private key (id_rsa) is of course the problem.

The way you use, as a client, your private key, is to push the corresponding public key into the server, in the .ssh/authorized_keys of the target account. When the public key is in this file, then whoever knows the private key may log into the server under that name. That's how the public/private keys work on the client side in SSH.

So there are basically three possible, rational reasons that would allow your friend to disregard the disclosure of his id_rsa file:


Maybe he never pushed the public key anywhere. When he logs into a server, he does it by typing his account password for that server, always. If his key pair is never used, then revealing the private key is harmless. But then, why would he have such a key pair?
Possibly, all the servers he connects to, with private key authentication, are located on a private network, with only non-hostile users, and strong isolation from the outside world.
It is conceivable that the private key is protected by a password (or "passphrase" in SSH terminology), which means that it really is encrypted with a key derived from the password; and your friend has great trust in the strength of his password.


Note that even if the private key is unprotected (or protected with a guessable password) and grants access to some servers reachable by attackers, then what the attackers can do is log in to these servers in the name of your friend (which is already a big problem). This does NOT grant to attackers the power to do a Man-in-the-Middle attack (MitM is double-impersonation, so a MitM attacker must know the private keys on both client and server); they cannot either decrypt past or future sessions that they eavesdrop on, or alter data of ongoing sessions (notably, the asymmetric keys in SSH are used for authentication, but the key exchange uses Diffie-Hellman).
