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
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).
- Authentication / Access Control
People who possess his credentials might be able to login into systems impersonating him.
Others will be able to sign messages as him, and he will not be able to deny sending them.
All his private communications can be decrypted and leaked.
Previous documents can be already and re-signed / re-hashed being no longer integer as in the last version prior to the incident.
Long story short – he has to get it revoked ASAP and get a new one.
SSH private keys are usually (by default) encrypted with a strong symmetric cipher. In some circumstances (not production use, of course) it may be viable to have those keys in an accessible shared location for ease of operation. This barely reduces the strength of the key to the strength of the password it is encrypted with, which may be tolerable, depending on the use pattern of the aforementioned keys and servers they belong too.
Just had to play the devil's advocate here.;)