4 Answers
4

The values in .ssh/authorized_keys are public keys -- these are mathematical objects, each of them being linked with another mathematical object called the private key. When the nagios server connects to one of the monitored servers, it uses its private key: the nagios server demonstrates its knowledge of the private key through a mathematical operation (a digital signature), which the target server verifies using the corresponding public key.

The magic of the construction is that the public key can be made public: although the private and public key share a common structure, that structure is "hidden" and cannot be rebuilt from the public key alone (here, "cannot" means "you would need a computer bigger than the whole state of Wyoming, and programmed by Chuck Norris").

So, to log into the target servers, you do not need to grab the public key, but the private key -- and that one never leaves the entrails of the nagios server.

(On the other hand, if you can get a read access to the nagios server, e.g. you can have a look at a backup tape, then you may get the private key, and access all the servers. Attacker's Nirvāṇa. That can be a serious security issue: protect your backups !)

It is secure because in order to log in you need both the public and the private keys and the server only needs the public key to verify that you have the private key. So, if the server is set up correctly you can only get the public key from it but you will still not have the private key. And by design it is not feasible to compute the private key from only the public key.

Say you somehow gain access to the server in question (either physically or remotely). There might be an nagios.pub file in /root/.ssh/authorized_keys/ and your question is, what happens if you replace the nagios.pub file with attacker.pub (only obviously renamed)? The answer is that you would then be able to log into that server using the attacker's private key (you would also deny the legitimate user access to the system).

The question then is, what have you gained. Well nothing really as you already had access to the system in the first place. Maybe you've gained remote access, but there are a million ways to do that once you have physical access. Maybe you've gained persistent access, but again there are plenty of other methods to do this that are less trackable (e.g., rootkits).

I don't know if I get you right, but SSH certificate authentication works in a way that you have to configure your SSHD with trusted certificates so, in order to add your certificate as trusted by the server, you have to be able to access it in a first place.