[WestCoastJustin]

There are many cases where you do not want, or cannot have a password protected ssh trust. For example, say you have a central nagios host monitoring a network, that nagios host needs to connect to remote machines to run interesting monitoring scripts (disk % full, raid controller query, mpio checks, etc), in these cases you do not want to have a password blocking the ssh trust. You will also find this type of thing happening in many continuous deployment workflows as bits are moving from one machine to the other. This is very common practice.

[egil]

In that case, you would lock down the key so it could only be used to execute the strict subset of commands to do its job. It is very common practice, but is not mentioned at all in the blog post.

[peteretep]

That does indeed sound like such a case. However, none of these cases appear to be what the article is addressing; it's just telling you to use non-password-protected keys, with absolutely no discussion of it.

[mverwijs]

No, in that case, you limit the commands that nagios is allowed to executed using this specific, passphrase-less key.

In this case you would limit this ssh-key to only be able to execute the nagios monitoring scripts. Nothing else.

You do this in ~/.ssh/config on the remote machine.

[rickr]

I believe you mean ~/.ssh/authorized_keys?

For anyone interested here's an SO question with an example: http://stackoverflow.com/questions/402615/how-to-restrict-ss...

[viraptor]

These sound like exactly the cases where you shouldn't use ssh. Use nrpe instead, or run the check on the target machine from cron and make it report back. There's no reason to use ssh for it and at scale ssh adds considerable load to the monitoring host when starting the connection.

For continuous deployment you can't easily work around using ssh, but at least the access can be limited to specific commands only.

[hf]

Both scenarios you mentioned would, I believe, benefit from using keychain (see below).

Let's suppose I have an account tests@host which runs the tests (scripts) that need to login to an array of machines.

In order for keychain to be helpful here, you need two prerequisites.

1) You need to be able to interactively login to tests@host once after bootup; after that you don't need to touch the machine again.

2) Then, the test scripts need to say

    . $HOME/.keychain/$HOSTNAME-sh

once before executing any ssh command (the line above simply imports the ssh-agent session variables into the current environment).

edit: I removed the Nagios references as other posters rightly point out that there are more endemic ways to collect information with Nagios.