restricting rsync over ssh

[Brian D. Hamm]

Worked like a charm, thanks.

The --server --sender options left me a little confused. I understand
what they stand for but these options are not in the help and they don't
appear to be variables.

After seeing the actual rsync cmdline in the output file on the remote
(mach3) it matched up with what -vv dumped out on the initiating server
(mach9).

mach9$ /opt/rsync/bin/rsync -e ssh -vv
admin at mach3:/home1/admin/rsyncdir/* 052002/mach3
opening connection using ssh mach3 -l admin rsync --server --sender -vv
. "/home1/admin/rsyncdir/*"
server_sender starting pid=......

So the authorized_keys file begins with (moved the "" around the whole
cmd)
command="rsync --server --sender -vv . /home1/admin/rsyncdir/*" 1024 33
109099............

After seeing this I think I will enhance the wrapper like you mentioned
to make it more flexible.  Just need to make sure the wrapper doesn't
have any erroneous output or I am sure I will see the friendly 'is your
shell clean?' msg.

Thanks again,

Brian D. Hamm, CISSP, CCNA
Network Design & Implementation
(o) 727-939-3080
(c) 727-424-4384
(f) 240-266-7185
(e) bdhamm at tampabay.rr.com
 

-----Original Message-----
From: Bennett Todd [mailto:bet at rahul.net] 
Sent: Wednesday, May 22, 2002 4:23 PM
To: Brian D. Hamm
Cc: rsync at lists.samba.org
Subject: Re: restricting rsync over ssh

2002-05-22-14:00:27 Brian D. Hamm:
> Is it true that when running rsync via ssh (i.e. rsync -e ssh ...)
> the rsyncd.conf file is not applicable [...]

Yup. Exactly right. When you're using ssh (or rsh, as far as rsync
is concerned they're interchangeable plug parts) the rsync client
you invoke from the shell establishes its rsync connection by
running something like

	ssh remotehost rsync [undocumented args here]

> If so, I am trying to find the best way to restrict rsync -e ssh on
the
> remote machine.  Prepending the authorized_keys entry with
> command='rsync ...' 1024... results in the 'Protocol mismatch - is
your
> shell clean?' error.

Perhaps the "..." after rsync isn't quite correct? Or perhaps the
path to rsync isn't in the default search path for sshd? I'd give a
full path to rsync in the command= invocation. The best way I know
to find the argument list is to use command=/path/to/wrapper where
wrapper looks like

	#!/bin/sh
	echo "$SSH_ORIGINAL_COMMAND" >>/tmp/foo
	exec $SSH_ORIGINAL_COMMAND

Then run your rsync of choice once. You'll see what cmdline rsync
makes up for firing up its "remote" end, depositing in /tmp/foo.
Then put that exact invocation in the command="...", that should
work fine.

If you want to allow a bit more flexibility, permitting some range
of cmds while rejecting others, you'll need to experiment with
different invocations and see what the cmdlines look like and try
and guess what parameter variations you want to allow; then make
command= point to a wrapper that checks $SSH_ORIGINAL_COMMAND
against whatever rules you have settled on, and if it looks Ok then
execs it.

NB: the cmdline argument list is undocumented for a reason; it's
private to rsync. This means that a future version of rsync
may use it differently, so if you upgrade rsyncs you may have
to change your hardwired invocation in authorized_keys or your
SSH_ORIGINAL_COMMAND-checking wrapper.

-Bennett