Ssh – Automated ssh login with passphrase

key-authenticationpasswordSecurityssh

Logging onto a machine over ssh typically requires a password to be entered before access is granted. Alternatively, a key/certificate (without a passphrase) can be installed onto the remote machine so that logging on no longer requires a password. This is particularly useful for automated or scripted solutions.

However, it is considered inadvisable and unsafe to create a key/certificate without a passphrase. Solutions involving ssh-add and ssh-agent are proposed as a means to enter a passphrase only once per session, but to still use a key/certificate with a passphrase.

What is the solution for automated connections between machines? How can a machine automatically update from a remote Bazaar repository (via bzr+ssh?) on a regular basis, as in a cron job? How can a machine automatically backup data from another machine (via rsync) as part of a cron job? rsyncd? This would not be encrypted though, which is a major disadvantage. I haven't looked at Bazaar daemon/server options.

Best Answer

For automated logins you have to use keyless ssh keys as you would have to manually intervene at the startup and provide a pass-phrase and have to resupply it after an restart.

To secure such keys there are multiple solutions - see man sshd for more details:

Restrict the remote host for the key with the from= parameter, e.g:
```
from="*.example.com" ssh_key
```
this will only allow machines from example.com
Specify which command will be executed with the command= parameter, e.g:
```
command="some command" ssh_key
```
Use a dedicated user with an restricted shell or only with the necessary permissions, e.g. for backup the user can only run rsync with sudo.

Restrict the commands that can be invoked by the key

If an SSH key is going to be used by any kind of automated or unattended task, you should restrict what commands it is able to execute on a remote machine, no matter what decision you make about how and where to store the key.

Use something like this in ~/.ssh/authorized_keys:

command="/usr/sbin/the-backup-daemon" ssh-rsa AAAAAAAAAAAABBBBBXXXXXX.....

That way, at least the key should not be able to, as you say, wreak havoc. It can only access what it's supposed to access, etc... It can most likely still do damage, but it should have less than full access to the remote system.

You can also restrict the IP addresses that are allowed to connect using that key and disable a bunch of other SSH features like port forwarding for connections where that key is used:

from="10.1.2.3",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="/usr/sbin/the-backup-daemon" ssh-rsa AAAAAAAAAAAAXXXXXX.....

All that has to go on a single line in ~/.ssh/authorized_keys.

Protecting the key

It depends on what your threat model is.

If you're worried about the key being stolen while "cold", for example, having the computer where it is saved physically stolen, then you won't want to save it without a passphrase in that location.

You could start a kind of background SSH agent manually after the server boots, add the key to that agent, and record the agent's $SSH_AUTH_SOCK for future use by the cron job, but honestly that sounds like more trouble than it's worth. You might as well just store the unencrypted key in a tmpfs filesystem and have the cron job access it from there. Either way the key lives in memory only (if you have no swap or encrypted swap). Of course you should chown and chmod the file so only the target user can access it.

Then again, if you're worried about that, you've probably already set up this computer with an encrypted root filesystem and swap (e.g. luks) so you may not need to worry about it as such.

If you're worried about the key being stolen while "hot" (loaded in memory) then there's not much you can do about that. If the cron job can access it, then so can something else that has managed to gain the same access. It's that, or give up the convenience of unattended job execution.

In conclusion, you should treat a backup server as a very privileged system since it will, by necessity, be given read-only access to the complete filesystems of all the computers it backs up. Your backup server should not be accessible from the Internet, for example.

Best Answer

Related Solutions

SSH Cron – Should Auto-Running Cron Job Keys Have No Passphrase?

Restrict the commands that can be invoked by the key

Protecting the key

Related Question