restricting rsync over ssh
bet at rahul.net
Wed May 29 12:05:01 EST 2002
On Wed, May 29, 2002 at 11:04:37AM -0600, tim.conway at philips.com wrote:
> I don't know ssh well enough to know whether it passes parameters besides
> the ones specified in authorized_keys. I think it passes parameters,
> though, because rsync over ssh is the basis of the IBM Content Promotion
> Tool (along with DCE/DFS), and it is TIGHTLY controlled. It couldn't work
> if parameters like "--server -lWHogDtprRz --bwlimit=128 --force .
> /wan/pri-tools1/big1/cadappl1/hpux/iclibs/CMOS12/PcCMOS12xcorelib" (an
> example from currently running stuff on one of my systems)can't be passed.
> You don't want to try to preparse the args. They will change in the
What you place in .ssh/authorized_keys is the _full_ commandline. Command and
all arguments. Neither the original command (if any) nor any additional
arguments are passed to the command when you use command= in authorized_keys.
Instead, the full original command is passed in the environment variable
SSH_ORIGINAL_COMMAND. Since it's passed as a string, any quoting is lost, as
far as I know.
This means there are three reasonable choices:
(1) You can allow only one single invocation of rsync, one cmdline; you
hardwire that into authorized_keys. This is one I like for backups.
(2) You allow any command, and just use a wrapper to e.g. log it; perhaps
logger [args] "$SSH_ORIGINAL_COMMAND"
(3) You allow a restricted range of commands, by using a wrapper that parses
$SSH_ORIGINAL_COMMAND, and decides whether to allow or not.
This mechanism cannot be used to restrict rsync invocations without wiring in
knowlege of the cmdline. In practice this means that if you want to upgrade
rsync, you might have to adjust the wired-in knowlege. That's why I wrote:
> > What say, rsync developers, any chance that the details of this cmdline
> > invocation --- the one rsync runs over rsh or ssh or whatever to establish
> > it's connection --- could be formally documented?
More information about the rsync