[Techtalk] Incorporating ssh into a bash script

Travis Casey efindel at earthlink.net
Sat Jan 25 15:52:04 EST 2003


On Saturday 25 January 2003 2:39, Hamster wrote:

[Apologies to Hamster -- I'm used to mailing lists which set the reply-to 
to be the mailing list... didn't mean to send you two copies.]

> > Now that my back-up server is working fine, my boss
> > wants me to create a bash script that will ssh into
> > our remote database server, create a tar ball of the
> > database and copy the tar ball to the backup server.
> >
> > I have never written a script that initiates ssh to
> > access a remote server. I was wondering if someone
> > could please help me with the ssh part of the script.
> > I have searched the internet for examples but have
> > found none
>
> ssh can be invoked in the following manner:
>
> ssh -l root 192.168.100.1 tar - /some/directory >some.file
>
> ie, you can append the command to be run on the remote machine to the end
> of the ssh line.
>
> But in order for this to work in a shell script, you will have to set it
> up so that the remote machine doesnt ask you to login. This is achieved
> by setting up ssh to use pass-phrase-less keys for authentication.
>
> This means that instead of a username and password, the authentication is
> done by the exchange of keys.
>
> Once this is setup, you can have a shell script that includes something
> like the following (note this isnt the only way of doing it)
>
> ssh -l root 192.168.1.1 tar -c /some/dir > /root/name.of.tar
> scp root at 192.168.1.1:/root/name.of.tar /home/root
>
> If you need help understanding or setting up passphraseless keys, write
> back.

A couple of notes here:

1 - I'd recommend creating a user account for doing the backups -- "backup" 
or something like that -- and having the backup server log into that.  You 
can then give it just the minimum permissions it needs to do the backups.  
This is safer than allowing the backup server access to the root account 
without a password.

2 - You can make it a one-step process, using the fact that ssh redirects 
standard output across the network:

ssh backup at remote "tar czf - /some/dir" > /backup_dir/name.of.tar.gz

The tar is executed on the remote host, and the data is compressed in gzip 
format as well (the "z" option).  It's sent to standard output, which ssh 
is redirecting across the network to the backup server.  Standard output is 
being sent to the "/backup_dir/name.of.tar.gz" file on the backup server.

If you just want a copy on the backup server, and don't want to keep the 
backup on the remote server, this is easier than creating the file, copying 
it, and then deleting it.

On crontab, you shouldn't need to put the script in /bin -- put it 
whereever you want, and specify the full path to it in the crontab entry.  
Where I work, I have a backup server which nightly grabs a tar of the "etc" 
directory on all the Unix machines.  There's a "backup" user on all the 
systems, and the scripts are in the backup user's bin directory -- which 
makes it easy to know which scripts are involved in the backup.  The backup 
user's crontab runs them, which also makes it easy to see what's involved 
in doing the backups and when it runs.

Bonus note -- you can use the "date" command with options to dynamically 
create filenames.  E.g., in the above, you could use:

/backup_dir/backup.`date +%d%b%Y`.tar.gz

as the file to send things to.  You'd have backup files named like:

backup.25Jan2003.tar.gz

You could then have a crontab job run every night with:

find /backup_dir -mtime +7 -exec rm {}\;

This would delete backups older than seven days.  Now you have the last 
week of backups, all nicely date-stamped for you.  :-)

--
       |\      _,,,---,,_     Travis S. Casey  <efindel at earthlink.net>
 ZZzz  /,`.-'`'    -.  ;-;;,_   No one agrees with me.  Not even me.
      |,4-  ) )-,_..;\ (  `'-' 
     '---''(_/--'  `-'\_) 



More information about the Techtalk mailing list