1

I have the following situation and want to know what are the best practices to do such things without exposing myself to security issues

  1. I have two servers both use the same private key for login.
  2. Server 2 copies files to Server 1 via scp (currently I save the private key on Server 2)

If any hacker ever gets control of server 2 he will also get the private key and hence both the servers will get compromised.

I am pretty sure that this is a very common scenario for most of the configurations and want to know what are the best practices in such cases.

2

The best practices you should be concerned with here are:

  1. Don't re-use credentials for multiple purposes. The two servers should not be sharing a private key.
  2. Hobble automated processes. Make sure that the SSH channel that is being opened up by server2 is limited to only copying files, and only to the intended directory tree.

The latter is important. If you're saving the private key on the server 2 so it can be used via cron, you need to limit the damage that can happen on server 1 if someone takes control of server 2 and tries to use that key. Give them an interactive login? Very bad. Overwrite arbitrary files? Very bad. Overwrite files in one tree, using a pre-determined command? Much better. Modern sshd_config can be written to powerfully limit a specific login. Create a special-purpose login for this so that you can lock it down tight. Don't use root. No, really, don't use root.

| improve this answer | |
0

Saving the .pem file on the connecting server is really the only option in this instance.

But you can mitigate any threat by (a) creating a dedicated ssh key that is used for absolutely nothing else other than this process, and (b) adding restrictions in your authorized_keys file such that no action is even allowed on the remote server other than this process.

You're used to your authorized_keys file looking like this:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQA... user@host

But you can add parameters to limit what can happen during that connection. Like this:

command="/bin/myproc -foo" ssh-rsa AAAAB3NzaC1yc2EAAAADAQA... user@host 

There are other restrictions you can apply as well:

from="1.2.3.4",tunnel=0,no-pty,command="/bin/foo" ssh-rsa AAAAB3NzaC1yc2EAAAADAQA... user@host 

You can further restrict behavior by restricting the user's permissions, using chroot, process control groups, process capabilities, etc.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.