Linux Backup Server: Refining Rsync, Passwordless Authentication - page 2
Rsync Backup ScriptDoubtless you have noticed a flaw in this fine scheme, which is how will logins happen? You don't want to hang around just to type in a password. We are going to use password-less public key authentication. Create ordinary SSH keys with ssh-keygen on the source PC. Copy the public key to the appropriate user account on the backup server, and presto! No password required. I prefer this to ssh-agent/keychain because it survives reboots. If you're thinking this sounds unsafe, it isn't as long as your protect your private key. You can spew forth hundreds of copies of your public key, but it won't do anyone any good unless they have access to the PC with the private key. Wherever your private key is, that is where you must log in to the server from.
You can still copy files both ways once you're logged in, from your PC to the server or the server to the PC.
First create an RSA or DSA keypair, as the user they're going to belong to. I have heard so many arguments which one is better I no longer care. I like RSA because it supports a longer key length, which may or may not matter, depending who is arguing at you. DSA keys must be 1024 bits. RSA keys can be from 768-- 4096. The default is 2048-bit RSA. When prompted to create a password do not create one:
Generating public/private rsa key pair.
Enter file in which to save the key (/home/carla/.ssh/id_rsa): /home/carla/.ssh/id_rsa_carla_xena
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/carla/.ssh/id_rsa_carla_xena.
Your public key has been saved in /home/carla/.ssh/id_rsa_carla_xena.pub.
The key fingerprint is:
The key's randomart image is:
+--[ RSA 2048]----+ | | | | | | | | | S | | o . . | | . *.o o | | =o* =oo | | ..+oOBE+. | +-----------------+
Stay tuned for an article on what the randomart image and fingerprint are for, and how to retrieve them.
I am now the proud owner of a brand-new custom-named keypair, id_rsa_carla_xena and id_rsa_carla_xena.pub. You don't have to rename yours; I always do because it's an easy way to keep track. The .pub key is your public key, the one you can share. Never ever ever share your private key.
Now you must copy the public key from the client PC to the appropriate account on the backup server. My account on the backup server is carla_backup:
carla@xena:~/.ssh$ scp id_rsa_carla_xena.pub carla_backup@backup_server:~/.ssh/
100% 392 0.4KB/s 00:00
And finally, copy the public key into the authorized_keys file on the server. You can do this without logging in:
carla@xena:~/.ssh$ ssh carla_backup@backup_server "cat ~/.ssh/id_rsa_carla_xena.pub >> ~/.ssh/authorized_keys"
Note that I had to specify the full filepath of the public key. Now test your new keys. The -i option is how you specify which key to use:
carla@xena:$ ssh -i ~/.ssh/id_rsa_carla_xena carla_backup@backup_server
Last login: Mon Feb 28 16:24:59 2011 from xena.alrac.net
The Final Piece: Scheduling Wakeups, Backups and ShutdownsThat's it for today! Come back tomorrow for the final installment. We will assemble all of our pieces and schedule unattended wakeups, backups, and shutdowns.
Carla Schroder is the author of the Linux Cookbook and the Linux Networking Cookbook (O'Reilly Media), the upcoming Book of Audacity (NoStarch Press), a lifelong book lover, and the managing editor of Linux Planet and Linux Today.
Solid state disks (SSDs) made a splash in consumer technology, and now the technology has its eyes on the enterprise storage market. Download this eBook to see what SSDs can do for your infrastructure and review the pros and cons of this potentially game-changing storage technology.