[clug] Automating SSH scripts with passphrase'd keys
scudette at gmail.com
Mon Mar 24 07:52:02 GMT 2008
Creating a special user on the server end is the best way to go -
something along this for a forced command might be best: dd
and then on the desktop you would do a cron job which does:
tar cz /home/ | ssh backup at server whatever
for example. The "whatever" is any command it doesnt matter as it will
be ignored anyway (the server will always run the forced command) but
is needed to make ssh not try to bind a pty (i.e. so it knows its not
an interactive shell).
If someone was to compromise the desktop they could send the server
tar files securely thats about it because they can not issue any other
command on the server than the dd command. If you want to get more
sophisticated you can write perl/python scripts to do anything based
on lots of parameters obtained via the environment of the forced
command like source ip, and even the command that the desktop wants to
run (the "whatever" above). This btw is how scponly is implemented to
allow scp services only to certain hosts, from ips, only upload no
download and lots of other policies.
On Mon, Mar 24, 2008 at 5:08 PM, Li-Jie Wong <u4178265 at anu.edu.au> wrote:
> 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?
> Li-Jie Wong
> [URL] http://eccentri.cc
> 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.
> > Michael.
> > On Mon, Mar 24, 2008 at 11:31 AM, Li-Jie Wong <u4178265 at anu.edu.au>
> > wrote:
> >> 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
> >> https://lists.samba.org/mailman/listinfo/linux
More information about the linux