risk of using ssh public keys

I have server A and server B(backup), and I was wondering, if somebody breaks into server A, could this be potentially dangerous to break into server B if I have configured passwordless login using ssh public keys?

I'm trying to setup rsnapshot.

Thanks

Yes, this is one of the problems with passwordless SSH keys. If you store a private key on server A that allows you to connect to server B, gaining access to server A is effectively gaining access to server B. (Not the reverse is not true - gaining access to server B wouldn't result in an immediate compromise of server A, assuming you didn't also have SSH keys set up to allow passwordless logins in that direction.

There are a few things you can do to mitigate this:

• If the process doesn't need to be fully automated, add a password to your SSH keys. (This probably won't work for you, since you note it's for a backup)
• For passwordless logins under your own account to multiple machines, I recommend creating a passworded key for each machine you physically type on, and use an SSH agent to store the key in-memory while you use it. Agent forwarding should allow you to "hop" from host to host without creating keys on each remote host.
• For automated, passwordless SSH keys, I recommend restricting the commands the key can run. In your authorized_keys file, prefix your each key with:
  command="<allowed command line here>",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty

8-9 years ago I worked in an shared user environment with hundreds of local users, and SSH key-based logins were disabled because there was no way to enforce password policies on the keys. So long as you're controlling the scenario fully, nowadays SSH keys are definitely better than just using passwords.

Yes, most guides on the internet stop at getting passwordless ssh to work, rather than getting it to work safely. This guide does a good job of showing what can be done to reduce the risks. Basically (to quote the article):

• create a single purpose role account for the job: i.e. a user dnssync on each machine
• if feasible, make the files writable by that user, rather than relying on being root
• for those bits that really need privileged access, create a script to do it, and use sudo
• use command= and from= options in authorized_keys files to restrict the passphrase-less keys
• for doing the file transfer, write a script to do it using rsync, on the receiving machine, so that remote access can be read-only
• if this means that access back to the initiating machine is needed from the remote machine, use ssh-agent rather than creating a second passphrase-less key

There are a couple of problems with ssh keys:

No centralized way to revoke a key.

No way to enforce password policies on keys (is your private key encrypted, and if so is it encrypted with a good password?).

These are the problems kerberos solves. It introduces others, though, namely it is more complex to implement and requires a real user management infrastructure to deploy and manage.

In any case, although ssh authorized_keys allow for morris-worm type attacks, it is still better than .r services and telnet by miles (light-years)

In any environment that I've had control of, I have always been a real stickler for minimum possible privilege for service accounts.

In this case, I'd suggest ensuring that the user account on the remote server is only permitted to run the a small, tightly defined set of executables. You could use multiple accounts on the remote side and sudo to accomplish this.

Even in this case, you're still subject to the local privilege escalation bugs, so be meticulous and keep track of security bugs tightly.