David Brown wrote:
> On Fri, May 30, 2008 at 05:07:30PM -0700, SJS wrote:
>> begin quoting [EMAIL PROTECTED] as of Fri, May 30, 2008 at
>> 04:51:35PM -0700:
>>> On Fri, May 30, 2008 at 02:02:33PM -0700, markw wrote:
>>> > Don't do it. ssh-agent has nothing to do with cron jobs. If it's
>>> > "passphraseless" then if the box with the private key is hacked, who
>>> > ever gets the private key has full privileges where ever that key is.
>>> > So, create a user for the job, if it has to be root, limit it via the
>>> > authorized_keys file, you can limit the commands run, etc. I use
>>> > passphraseless keys for rsnapshot.
>>>
>>> Yea I guess passphraseless RSA keys don't need ssh-agent. That's right.
>>> Ooops. But passphraseless RSA keys are a nice way to have cron jobs
>>> be able to move date to/from other machine. It would be a good idea
>>> to look
>>> into locking down what is possible with these keys on remote machine.
>>
>> no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="command"
>> key
>
> And you have to make sure that I can't use sftp to overwrite files in your
> .ssh directory and then allow other things.
>
> It's amazingly difficult to make sshd allow a small number of things but
> still be basically secure.
So, sticking to the original idea of an rsync job, I gather that rsync
over ssh actually executes an rsync command ("single use daemon mode",
it says in the man page) on the server. I believe you're saying you
want to prevent a rogue execution of the initiating rsync to overwrite
the .ssh/authorized_keys file (among other things). Would another level
of indirection help? Make rsync a wrapper that runs the real rsync as
yet another user? I'm _assuming_ that the a_k file has a command="rsync
.." clause that satisfies the rsync operation.
This sort of thing makes one's head hurt!
Regards,
..jim
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
