In
this article I'll show you how to use scp without passwords. Then I'll
show you how to use this in two cool scripts. One script lets you copy
a file to multiple linux boxes on your network and the other allows you
to easily back up all your linux boxes.
If you're a linux sysadmin, you frequently need to copy files from one
linux box to another. Or you need to distribute a file to multiple
boxes. You could use ftp, but there are many advantages to using scp
instead. Scp is much more secure than ftp, as scp travels across the
LAN /WAN encrypted, while ftp uses clear text (even for passwords.
But what I like best about scp is that it's easily scriptable. Suppose
you have a file that you need to distribute to 100 linux boxes. I'd
rather write a script to do it than type 100 sets of copy commands. If
you use ftp in your script it can get pretty messy, because each linux
box you log into is going to ask for a password. But if you use scp in
your script, you can set things up so the remote linux boxes don't ask
for a password. Believe it or not, this is actually much more secure
than using ftp!
Here's an example demonstrating the most basic syntax for scp. To copy
a file named 'abc.tgz' from your local pc, to the /tmp dir of a remote
pc called 'bozo' use:
scp abc.tgz root@bozo:/tmp
You will now be asked for bozo's root password. So we're not quite
there yet. It's still asking for a password so it's not easily
scriptable. To fix that, follow this one time procedure (then you can
do endless "passwordless" scp copies):
1. Decide which user on the local machine will be using scp later on.
Of course root gives you the most power, and that's how I personally
have done it. I won't give you a lecture on the dangers of root here,
so if you don't understand them, use a different user. Whatever you
choose, log in as that user now for the rest of the procedure, and log
in as that user when you use scp later on.
2. Generate a public / private key pair on the local machine. Say What?
If you're not familiar with Public Key Cryptography, here's the 15
second explanation. In Public Key Cryptography, you generate a pair of
mathematically related keys, one public and one private. Then you give
your public key to anyone and everyone in the world, but you never ever
give out your private key. The magic is in the mathematical makeup of
the keys - anyone with your public key can encrypt a message with it,
but only you can decrypt it with your private key. Anyway, the syntax
to create the key pair is:
ssh-keygen -t rsa
3. In response you'll see:
"Generating public/private rsa key pair"
"Enter file in which to save the key ... "
Just hit enter to accept this.
4. In response you'll see:
"Enter passphrase (empty for no passphrase):"
You don't need a passphrase, so just hit enter twice.
5. In response you'll see:
"Your identification has been saved in ... "
"Your public key has been saved in ... "
Note the name and location of the public key just generated (it will always end in .pub).
6. Copy the public key just generated all your remote linux boxes. You
can use scp or ftp or whatever to do the copy. Assuming your're using
root (again see my warning in step 1. above), the key must be contained
in the file /root/.ssh/authorized_keys (watch spelling!). Or if you are
logging in as a user, e.g. clyde, it would be in
/home/clyde/authorized_keys. Note that the authorized_keys file can
contain keys from other PC's. So if the file already exists and
contains text in it, you need to append the contents of your public key
file to it.
That's it. Now with a little luck you should be able to scp a file to
the remote box without using a password. So let's test it by trying our
first example again. Copy a file named 'xyz.tgz' from your local pc, to
the /tmp dir of a remote pc called 'bozo'
scp xyz.tgz root@bozo:/tmp
Wow !!! It copied with no password!!
A word about security before we go on. This local PC just became pretty
powerful, since it now has access to all the remote PC's with only the
one local password. So that one password better be very strong and well
guarded.
Now for the fun part. Let's write a short script to copy a file called
'houdini' from the local PC to the /tmp dir of ten remote PC's, in ten
different cities (with only 5 minutes work). Of course it would work
just the same with 100 or 1000 PC's. Suppose the 10 PC's are called:
brooklyn, oshkosh, paris, bejing, winslow, rio, gnome, miami, minsk and
tokyo. Here's the script:
#!/bin/sh
for CITY in brooklyn oshkosh paris bejing winslow rio gnome miami minsk tokyo
do
scp houdini root@$CITY:/tmp
echo $CITY " is copied"
done
Works liek magic. With the echo line in the script you should be able to watch as each city is completed one after the next.
By the way, if you're new to shell scripting, here's a pretty good tutorial:
http://www.freeos.com/guides/lsst/.
As you may know, scp is just one part of the much broader ssh. Here's
the cool part. When you followed my 6 stop procedure above, you also
gained the ability sit at your local PC and execute any command you
like on any of the remote PC's (without password of course!). Here's a
simple example, to view the date & time on the remote PC brooklyn:
ssh brooklyn "date"
Now let's put these 2 concepts together for one final and seriously
cool script. It's a down and dirty way to backup all your remote linux
boxes. The example backs up the /home dir on each box. It's primitive
compared to the abilities of commercial backup software, but you can't
beat the price. Consider the fact that most commercial backup software
charges licence fees for each machine you back. If you use such a
package, instead of paying licence fees to back remote 100 PC's, you
could use the script back the 100 PC's to one local PC. Then back the
local PC to your commercial package and save the license fee for 99
PC's ! Anyway the script demostates the concepts so you can write you
own to suit your situation. Just put this script in a cron job on your
local PC (no script is required on the remote PC's). Please read the
comments carefully, as they explain everything you need to know:
#!/bin/sh
# Variables are upper case for clarity
# before using the script you need to create a dir called '/tmp/backups' on each
# remote box & a dir called '/usr/backups' on the local box
# on this local PC
# Set the variable "DATE" & format the date cmd output to look pretty
#
DATE=$(date +%b%d)
# this 'for loop' has 3 separate functions
for CITY in brooklyn oshkosh paris bejing winslow rio gnome miami minsk tokyo
do
# remove tarball on remote box from the previous time the script ran # to avoid filling up your HD
# then echo it for troubleshooting
#
ssh -1 $CITY "rm -f /tmp/backups/*.tgz"
echo $CITY " old tarball removed"
# create a tarball of the /home dir on each remote box & put it in /tmp/backups
# name the tarball uniquely with the date & city name
#
ssh $CITY "tar -zcvpf /tmp/backups/$CITY.$DATE.tgz /home/"
echo $CITY " is tarred"
# copy the tarball just create from the remote box to the /usr/backups dir on
# the local box
#
scp root@$CITY:/tmp/backups/$CITY.$DATE.tgz /usr/backups
echo $CITY " is copied"
done
# the rest of the script is for error checking only, so it's optional:
# on this local PC
# create error file w todays date.
# If any box doesn't get backed, it gets written to this file
#
touch /u01/backup/scp_error_$DATE
for CITY in brooklyn oshkosh paris bejing winslow rio gnome miami minsk tokyo
do
# Check if tarball was copied to local box. If not write to error file
# note the use of '||' which says do what's after it if what's before it is not # true
#
ls /u01/backup/$CITY.$DATE.tgz || echo " $CITY did not copy" >> scp_error_$DATE
# Check if tarball can be opened w/o errors. If errors write to error file.
tar ztvf /u01/backup/$CITY.$DATE.tgz || echo "tarball of $CITY is No Good" >> scp_error_$DATE
done
That's about it. In this article I've tried to give examples that
demonstate the concepts, not necessarily to be use "as is". Some of the
syntax may not work in all distros, but in the interest of brevity I
could not include all the possibilities. For example, if you are using
Red Hat 6.2 or before, the syntax will require some changes (I'd be
happy to give it to you if you email me). So be creative and hopefully
you can use some of this in your own environment.