Is it true that when running rsync via ssh (i.e. rsync -e ssh ...) the rsyncd.conf file is not applicable on the remote since rsync is launched via the ssh exec call once connected rather than from rsyncd as in a direct connect. 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. Thanks, Brian D. Hamm, CISSP, CCNA Network Design & Implementation (o) 727-939-3080 (c) 727-424-4384 (f) 240-266-7185 (e) bdhamm@tampabay.rr.com
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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available Url : http://lists.samba.org/archive/rsync/attachments/20020522/e7741951/attachment.bin
You're dealing with an ssh issue there. anybody who can't ssh can't
rsync
-e ssh. Maybe you could take the public keys from everybody you want to
use it, and put them into the account you want them to ssh into, in
authorized_keys, with the appropriate command restrictions.
Tim Conway
tim.conway@philips.com
303.682.4917
Philips Semiconductor - Longmont TC
1880 Industrial Circle, Suite D
Longmont, CO 80501
Available via SameTime Connect within Philips, n9hmg on AIM
perl -e 'print pack(nnnnnnnnnnnn,
19061,29556,8289,28271,29800,25970,8304,25970,27680,26721,25451,25970),
".\n" '
"There are some who call me.... Tim?"
"Brian D. Hamm" <bdhamm@tampabay.rr.com>
Sent by: rsync-admin@lists.samba.org
05/22/2002 12:00 PM
To: <rsync@lists.samba.org>
cc: (bcc: Tim Conway/LMT/SC/PHILIPS)
Subject: restricting rsync over ssh
Classification:
Is it true that when running rsync via ssh (i.e. rsync -e ssh ...) the
rsyncd.conf file is not applicable on the remote since rsync is launched
via the ssh exec call once connected rather than from rsyncd as in a
direct connect.
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.
Thanks,
Brian D. Hamm, CISSP, CCNA
Network Design & Implementation
(o) 727-939-3080
(c) 727-424-4384
(f) 240-266-7185
(e) bdhamm@tampabay.rr.com
--
To unsubscribe or change options:
http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
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
future.
command='/path/to/rsync'.
Tim Conway
tim.conway@philips.com
303.682.4917
Philips Semiconductor - Longmont TC
1880 Industrial Circle, Suite D
Longmont, CO 80501
Available via SameTime Connect within Philips, n9hmg on AIM
perl -e 'print pack(nnnnnnnnnnnn,
19061,29556,8289,28271,29800,25970,8304,25970,27680,26721,25451,25970),
".\n" '
"There are some who call me.... Tim?"
Bennett Todd <bet@rahul.net>
Sent by: rsync-admin@lists.samba.org
05/23/2002 06:57 AM
To: "Brian D. Hamm" <bdhamm@tampabay.rr.com>
cc: rsync@lists.samba.org
(bcc: Tim Conway/LMT/SC/PHILIPS)
Subject: Re: restricting rsync over ssh
Classification:
On Wed, May 22, 2002 at 10:01:27PM -0400, Brian D. Hamm
wrote:> 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.
Yes indeed, as I tried to indicate, rsync has a private protocol, based on
the
use of undocumented cmdline options, for talking to itself in various
settings.
I believe it's pretty near obligatory to presume that such a private
protocol
is kept undocumented so as to reserve the right to the rsync developers to
change it without notice in future versions; that's why I cautioned that
doing
this sort of restriction puts you in the position of perhaps having to
revisit
it when another release comes around, and having to do some guesswork if
you
want a wrapper to parse the cmdline to provide restricted flexibility in
permitted invocations.
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? Combined with such
tricks as
the authorized_keys command="..." plus SSH_ORIGINAL_COMMAND this would
provide
us a documented way to provide fine-grained restrictions over what is
allowed.
I really like doing this; e.g. I've set up backup facilities where the
server
that's being backed up can _only_ update its own mirror area, and the
history
of previous contents (as well as everything else on the system) are
inaccessible to it.
-Bennett
--
To unsubscribe or change options:
http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Dave Dykstra writes:> On Wed, May 22, 2002 at 02:39:00PM -0700, Mike Rubel wrote: > > This brings up an interesting question. Does anyone use the server > > version of rsyncd with an ssh tunnel? In other words: > > > > On the server, bring up sshd listening on *:22, and rsyncd accepting > > connections from localhost only, port 873. > > > > Then, on the client machine, set up an ssh tunnel: > > > > ssh server -L 1873:server:873 > > > > (I just picked 1873 for convenience; you could use any open > > user-accessible port). > > > > Then rsync to localhost:1873, letting ssh carry the connection over the > > tunnel to the server: > > > > rsync rsync://user@localhost:1873/path/to/source dest > > Does anyone use this approach? Are there any advantages/disadvantages? > > I didn't see any respones to your message so I guess it isn't very widely > done. I haven't tried it but I don't see why it wouldn't work. You could > probably use "hosts allow = localhost" to disallow people from using port > 873 directly.Somewhat belatedly, I can report that I use rysnc in daemon mode in conjunction with an SSH tunnel, but using remote port forwarding. I use the method to distribute password and shadow files. On the server, SSH is needed for other purposes, so its daemon runs all the time, but the rsync daemon only ever runs for as long as it takes to serve all of the clients once. I restrict access to the module through a secrets file and change the password for every client, using some random data out of /proc. From a regular cron job, the server starts the rsync daemon, contacts each client in turn using a passphraseles key, specifying remote port forwarding, and passing the password to SSH on standard input; the rsync daemon is shut down once every client has been dealt with. The clients have a forced command for the key in their authorized_keys files which extracts the password from standard output into a file and runs: rsync --password-file <that file> localhost::module DEST Jim