ssh has provisions for just such considerations. You can let it do only
rsync. I can't remember exactly the way to say it, but i'll bet somebody
on this list does.
++++++++++++++++++from man sshd+++++++++++++++++++++++++++++++++++++++++++
AUTHORIZED_KEYS FILE FORMAT
The $HOME/.ssh/authorized_keys file lists the RSA keys that are
permitted
for RSA authentication in SSH protocols 1.3 and 1.5 Similarly, the
$HOME/.ssh/authorized_keys2 file lists the DSA keys that are
permitted
for DSA authentication in SSH protocol 2.0. Each line of the file
con-
tains one key (empty lines and lines starting with a `#' are ignored
as
comments). Each line consists of the following fields, separated by
spaces: options, bits, exponent, modulus, comment. The options field
is
optional; its presence is determined by whether the line starts with
a
number or not (the option field never starts with a number). The
bits,
exponent, modulus and comment fields give the RSA key; the comment
field
is not used for anything (but may be convenient for the user to
identify
the key).
Note that lines in this file are usually several hundred bytes long
(be-
cause of the size of the RSA key modulus). You don't want to type
them
in; instead, copy the identity.pub file and edit it.
The options (if present) consist of comma-separated option specifica-
tions. No spaces are permitted, except within double quotes. The
fol-
lowing option specifications are supported:
from="pattern-list"
Specifies that in addition to RSA authentication, the
canonical
name of the remote host must be present in the
comma-separated
list of patterns (`*' and `?' serve as wildcards). The list
may
also contain patterns negated by prefixing them with `!'; if
the
canonical host name matches a negated pattern, the key is not
ac-
cepted. The purpose of this option is to optionally increase
se-
curity: RSA authentication by itself does not trust the
network
or name servers or anything (but the key); however, if
somebody
somehow steals the key, the key permits an intruder to log in
from anywhere in the world. This additional option makes
using a
stolen key more difficult (name servers and/or routers would
have
to be compromised in addition to just the key).
command="command"
Specifies that the command is executed whenever this key is
used
for authentication. The command supplied by the user (if
any) is
ignored. The command is run on a pty if the connection
requests
a pty; otherwise it is run without a tty. A quote may be
includ-
ed in the command by quoting it with a backslash. This
option
might be useful to restrict certain RSA keys to perform just
a
specific operation. An example might be a key that permits
re-
mote backups but nothing else. Note that the client may
specify
TCP/IP and/or X11 forwarding unless they are explicitly
prohibit-
ed.
environment="NAME=value"
Specifies that the string is to be added to the environment
when
logging in using this key. Environment variables set this
way
override other default environment values. Multiple options
of
this type are permitted.
no-port-forwarding
Forbids TCP/IP forwarding when this key is used for
authentica-
tion. Any port forward requests by the client will return an
er-
ror. This might be used, e.g., in connection with the
command
option.
no-X11-forwarding
Forbids X11 forwarding when this key is used for
authentication.
Any X11 forward requests by the client will return an error.
no-agent-forwarding
Forbids authentication agent forwarding when this key is used
for
authentication.
no-pty Prevents tty allocation (a request to allocate a pty will
fail).
Examples
1024 33 12121...312314325 [EMAIL PROTECTED]
from="*.niksula.hut.fi,!pc.niksula.hut.fi" 1024 35 23...2334
ylo@niksula
command="dump /home",no-pty,no-port-forwarding 1024 33 23...2323
back-
up.hut.fi
++++++++++++++++++from man sshd+++++++++++++++++++++++++++++++++++++++++++
Tim Conway
[EMAIL PROTECTED]
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?"
Philip Mak <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
11/24/2001 01:18 AM
To: [EMAIL PROTECTED]
cc: (bcc: Tim Conway/LMT/SC/PHILIPS)
Subject: Authenticating the rsync server
Classification:
Scenario: I have a main website. I want to allow other people with web
servers to use rsync to synchronize mirror copies of my website.
When the mirror website uses rsync to connect to the server, how can it be
sure that the server is not an IP spoofing impostor that is serving up
altered files?
>From what I've read in the rsync documentation, the rsync server doesn't
seem to have a way of proving that it is the real server (e.g. by using
public key cryptography).
So, if I wanted to authenticate the rsync server, then I would have to use
rsync over ssh instead of running an rsync server over inetd, right?
I should then put the ssh public key of the server on the website,
available through https:// on my website. Someone who wants to setup a
mirror can download the ssh public key via https://, install that in their
ssh client, and then use ssh to connect to a shell account on my server to
run rsync.
What about security, though? I would essentially be giving a shell account
to anyone who wants to use it. This shell account would have to be
restricted: It is CHROOTed in the file area, it cannot write to any of the
files, and it can't run any program other than rsync. I'd guess I'd have
to set this account to some special restricted shell that does this.
Am I right about all of the above? If yes, does anyone know where I might
start looking for such a special restricted shell program? If no, where
did I go wrong (is there a simpler way to provide a relatively simple
thing such as authentication of the rsync server)?
