* Adar Dembo (firstname.lastname@example.org) [021218 03:02]: > I'm trying to create a backup script that will, when run, connect to > another computer, and rsync all of its partitions into the local computer. > > In order to be able to rsync properly and copy all the files, the user > logging in must be root. However, this poses a problem, as > PermitRootLogin was "no" in sshd_config. So here is how I went about > trying to solve the problem. > > First, some names. The source computer is called "dh3". The target > computer is "dh2". > > On dh2, I ran: > ssh-keygen -t rsa1 > ssh-keygen -t rsa > ssh-keygen -t dsa Just use one key, not 3. 3 keys is 3 times as many ways to get root on that other machine; your backup script only needs one. Let's just use "-t rsa" to make an ssh protocol version 2 rsa key. > Note the use of PermitRootLogin forced-commands-only which should allow > me to ssh in as root, using my keys, as long as I run a command afterwards. > > The actual command being run on dh2 (as root) is something to the effect of: > > ssh dh3.doggus.com rsync ..... No, that's not quite how it works. forced-commands-only will allow login with that key and will automatically execute the command listed in the authorized_keys file, ignoring anything specified on the ssh command line[*]. Your authorized_keys should look something like this: from="other.host",command="rsync --server something",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-rsa 1231241234123(key data) backup-key(comment) Just use one key, not 3, and set up some options to make it more secure, as in the above example. Invoke rsync from the client as rsync, which will try to use rsh (which is really ssh on your system, right? Or give rsync -e /usr/bin/ssh). That is to say you shouldn't be invoking "ssh other host rsync something" To figure out the rsync command to place in your authorized_keys file, use ssh -v to see the command rsync tries to run on the server side (it'll be rsync --server something) and stick that in the command="" option in your authorized_keys. [*] The original command line is placed in SSH_ORIGINAL_COMMAND in the environment of the executed command. This can be used e.g. in a wrapper script that needs variable arguments: it can parse $SSH_ORIGINAL_COMMAND and use the args specified on the ssh command line. For a backup script, you shouldn't need variable arguments at all: it'll be run the same all the time (assuming you're always backing up the same directories). good times, Vineet -- http://www.doorstop.net/ -- One nation, indivisible, with equality, liberty, and justice for all.
Description: PGP signature