1

I use an rsync wrapper script to synchronize or backup to/from various directories on different servers. The script invokes rsync (obviously), and in some configurations ln on the server.

Restricting the SSH access using the command parameter in authorized_keys for a single key with rrsync (as recommended here) or chrooting the user on the servers is not feasible, as I need to access (read or write) directories in many different places. Using a wrapper script for evaluating $SSH_ORIGINAL_COMMAND (as suggested here) would allow for static calls to rsync and ln, but not for all the different rsync parameters created by my local script.

Is there another way to lock down access under these circumstances?

Lingathoti Ashalatha
  • 49
  • 2
janeden
  • 291
  • 2
  • 13

1 Answers1

1

OpenSSH ForceCommand is secure because the server enforces the command and options. It will not allow remote user to issue a series of various commands. Such as your backup commands as doing a series of rsync and file related commands with various parameters. This is a similar challenge as Ansible automation tool, which generates and runs scripts, and so also has problems when its allowed commands are limited.

Wrapper scripts preinstalled on the remote could take care of it with one command. Say you wrote /usr/local/bin/custombackup, which knows the paths to backup and where to archive them. Allow the script in an authorized_keys command. Also disable shell by setting the user to nologin.

However you may have other scenarios or variations in what to backup and how. In less restrictive environments, this could be solved by extending the script to take options. However ForceCommand mandates a static command line. Consider installing another key with a different forced command, as silly as that might seem.

Beware of getting too clever with environment variable ${SSH_ORIGINAL_COMMAND}. If you were to run the original command unsanitized, that could be a command injection problem.

And if ultimately ForceCommand is not implemented, you can have additional defenses. Remove write access to most files from the backup user. Passphrase protect the private key, and audit all access to it in the secret system. Audit and log user logins, and be able to correlate them against scheduled backups. If the backup ssh key were suspected to be compromised, all secrets are to be rotated and new backups created from scratch.

John Mahowald
  • 36,071