[clug] Automating SSH scripts with passphrase'd keys
u4178265 at anu.edu.au
Mon Mar 24 07:08:30 GMT 2008
Hi Michael, thanks for the advise,
I should mention that I was trying to do a "push" from my desktop to
the file server as I am attempting to perform the backup to multiple
locations (thus centralising the control, not needing to edit crontab
on multiple locations, etc). Incoming connections from the world
(outside my department) are blocked to my desktop so that's tricky too.
I did the ssh-agent stuff because this desktop is (somewhat) wide in
the open and the key might be easily obtainable (and yes I understand
the RAM stuff that Chris previously raised). Would there be any other
options (other than creating another key that is restricted on the
server end) to improve the setup?
On 24/03/2008, at 17:43:16, Michael Cohen wrote:
> Li Jie,
> Automated backup scripts should generally not be run using ssh-agent
> for a couple of reasons. You will probably need to unlock the keys
> manually for the ssh agent first, which means that your backup scripts
> will not run after a system reboot. The second problem is that once
> the backup script has access to the keys in the agent the user running
> the backup job has full access to the system you are trying to backup
> (backup jobs typically run as root on the remote system because they
> need to read all files).
> The usual way to set up backup jobs is as follows:
> 1) On the backup system you create a special backup user with their
> own key (ssh-keygen) Do not use any passphrase to protect this key.
> 2) On the system you are trying to backup add an entry to the root
> users .ssh/authorized_keys. The trick is that you must add the backup
> user's key but only allow it to do exactly one job - backup the
> system. The solution is to use the forced command feature to prefix
> the key with the exact command you want the backup user to run on the
> system as root (something like tar cz /home/ for whatever).
> This setup is way more secure because if the backup user was
> compromised, their key can only backup the server - they are unable to
> get an interactive or otherwise shell. Note that backup users
> obviously have access to some pretty sensitive info like everyones
> files regardless of permissions, so protect that user. The point is
> that if the backup user is compromised, they only can get another copy
> of the backup which will happen anyway soon enough.
> You must be careful whenever root key access is given. Typically
> automated tasks must never be allowed to do anything - if they are
> automated in the first place its predictable exactly what you want
> them to do so enforce it.
> On Mon, Mar 24, 2008 at 11:31 AM, Li-Jie Wong <u4178265 at anu.edu.au>
>> I've recently attempted to set up automated ssh scripts to perform
>> automated backups with a passphrase'd key. However it seems a little
>> tricker than I expected, and will attempt to share the various points
>> that I learnt in this attempt. I wouldn't be surprised if I took a
>> more roundabout way than necessary and would appreciate any tips on a
>> shorter way to go about it.
>> ssh-agent / ssh-add seems to have quite a short default time-out,
>> so I
>> created an auth script for me to run that runs "ssh-add -t 1w" to set
>> the time-out to one week.
>> However ssh-agent doesn't necessarily seem to start automatically
>> so I
>> added ssh-agent to the auth script and wrote the output to a file
>> Found out that my jobs in cron couldn't get the ssh-agent details
>> somehow, even though I had specified #!/bin/bash in my backup script
>> (which I think assumed would execute .bashrc) and have the ssh-agent
>> environmental variables sourced in .bashrc
>> I ended up sourcing the ssh-agent environmental variables again in my
>> backup script and it seems to work now.
>> I'm not sure if it's possible to get ssh-agent to run once (under my
>> user) on startup. Perhaps I could use sudo? Perhaps I should write a
>> weekly cron job to remind me to run auth before the time out.
>> Li-Jie Wong
>> [URL] http://eccentri.cc
>> linux mailing list
>> linux at lists.samba.org
More information about the linux