If you're a Linux sysadmin, you frequently need to copy files from one Linux box to another. Or, you may need to distribute a file to multiple boxes. You could use FTP,but using scp has many advantages. For instance, scp is much more secure than FTP. scp travels across the LAN/WAN encrypted, while FTP uses clear text, even for passwords.

For this, you'll need openssh and keychain packages.

First of all, 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'm not going to give you a lecture here on the dangers of root, so if you don't understand them, choose a different user. Whatever you choose, log in as that user now and stay there for the rest of the procedure. Log in as this same user when you use scp later on.

1. Generate a key pair
2. Setup the Remote Host for RSA Authentication
3. Using SSH­AGENT
4. Using SSH­ADD
5. Using KEY­CHAIN
6. Using CRON

This document was compiled from different sources:
IBM
LinuxJournal
SSH­Lab PDF Created by Oliver Dario 2005

OpenSSH, by default, uses password authentication for users. However, a more secure method of for user authentication can done by using a public key cryptographic method such as RSA or DSA. This section guides you through the steps for creating an RSA key pair for sshuser1. When generating keys, be sure that you are currently logged in as the user that you want to make keys for.

The command for generating keys with openSSH is ssh­keygen. When using ssh­keygen to create keys, you will need to specify whether to create an RSA or DSA key pair. We will stick to creating only an RSA key pair for now. To do this, use the ­t option along with the parameter “rsa.”

[root@localhost ~]# ssh-keygen

Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
a2:cb:65:8c:c0:df:03:4d:52:47:02:45:72:c5:f2:42 root@localhost.localdomain

A prompt asking for a passphrase is printed to the screen. The passphrase that you enter will be used to encrypt part of your private key file using the 3DES encryption algorithm. If you choose SSH Authentication using RSA/DSA Encryption not to create a passphrase, then you will be able to enjoy ssh'ing into a remote computer without entering a password or a passphrase. Although this may sound like a great idea, it does introduce a few security issues (imagine someone next to you using your account to ssh into another computer that they are not authorized to use). I highly suggest that you create a passphrase for any key pair that you ever decide to create.

This output tells you two important things:

1. The location of your public and private keys, id_rsa.pub and id_rsa, respectively, and
2. the fingerprint for your keys. A fingerprint is normally used by someone to verify that they have your key in its original form. To print the fingerprint of your public key, use the following command:

[root@localhost ~]# ssh-keygen -l
 Enter file in which the key is (/root/.ssh/id_rsa):
 2048 a2:cb:65:8c:c0:df:03:4d:52:47:02:45:72:c5:f2:42 /root/.ssh/id_rsa.pub

Now that you have a public RSA key, you can start spreading it to computers that you trust. For this exercise, we will send our public key to sshuser2. One way to do this is to use the scp command to transfer your public key file, id_rsa.pub, to sshuser2's home directory. Here is an example:

[root@localhost ~]# scp ~/.ssh/id_rsa.pub sshuser2@remotehost:~/

Since this may be your first time using ssh to log into sshuser2 from sshuser1, you will see that the authenticity of the host computer cannot be verified. You are then asked if you want to still connect to that host. It is safe to answer “yes” at the prompt since sshuser2 is someone that you should know very well.

The RSA key for sshuser2's computer will then be added to a file called known_hosts. This file keeps a record of the hosts that you have allowed connections to and can be found in ~/.ssh. Here is what all of the output looks like:

The authenticity of host 'remote (192.168.1.2)' can't be established.
RSA key fingerprint is 41:  7c:d9:dd:d0:df:d0:ee:36:7a:fb:9e:b8:89:43:6e.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'remotehost' (RSA) to the list of known hosts.
sshuser2@remotehost's password:
id_rsa.pub                  100% 240 0.2KB/s 00:00

For oure user (root – user from the first step), we must take care of authentication on remote host. This is done this way:

in .ssh folder you must add to authorized_keys file, public key for user root (or whatever is named) uploaded with scp.

[sshuser2@remotehost ~]$ cat id_rsa.pub >> ~/.ssh/authorized_keys

You can verify that id_rsa.pub has been appended to authorized_keys by using vi or cat.
Since root's id_rsa.pub file is no longer needed, you may remove it from the ~/ directory.

Note: The ~/.ssh directory and the authorized_keys file must not be writable by group or other! For example, you can use chmod 700 permissions on ~/.ssh and 644 for authorized_keys.

Also, take a look at /etc/ssh/sshd_config on remote host. You must have uncommented these lines:

RSAAuthentication          yes
PubkeyAuthentication       yes
AuthorizedKeysFile         .ssh/authorized_keys

ssh­agent, included with the OpenSSH distribution, is a special program designed to make dealing with RSA and DSA keys both pleasant and secure. ssh­agent, unlike ssh, is a long­running daemon designed for the sole purpose of caching your decrypted private keys.

ssh includes built­in support that allows it to communicate with ssh­agent, allowing ssh to acquire your decrypted private keys without prompting you for a password for every single new connection. With ssh­agent you simply use ssh­add to add your private keys to ssh­agent's cache. It's a one­time process; after using ssh­add, ssh will grab your private key from ssh­agent, rather than bugging you by prompting for a passphrase.

First off, try running the ssh­agent command at the command line. The output should look like this:

[root@localhost ~]# ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-lmjSr14661/agent.14661; export SSH_AUTH_SOCK;
SSH_AGENT_PID=14662; export SSH_AGENT_PID;
echo Agent pid 14662;

As you can see, ssh­agent's output is actually a series of bash commands; if executed, these commands would set a couple of environment variables, SSH_AUTH_SOCK and SSH_AGENT_PID. Due to the included export commands, these environment variables would be made available to any additional commands run later. Well, all that would happen if these lines were actually evaluated by the shell, but right now they're simply printed to stdout. To fix this, we can invoke ssh­agent in the following way:

[root@localhost ~]# eval `ssh-agent`
Agent pid 14665

This command tells bash to run ssh­agent and then evaluate ssh­agent's output. Invoked this way (with back­quotes, not normal single quotes), the SSH_AGENT_PID and SSH_AUTH_SOCK variables get set and exported by your shell, making these variables available to any new processes you may start during your login session.

You can check there using:

[root@localhost ~]# env | grep SSH
SSH_AGENT_PID=14665
SSH_AUTH_SOCK=/tmp/ssh-lDSwp14664/agent.14664
SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass

But of course, ssh­agent starts up with an empty cache of decrypted private keys. Before we can really use ssh­agent, we first need to add add our private key(s) to ssh­agent's cache using the ssh­add command. In the following example, I use ssh­add to add my ~/.ssh/identity private RSA key to ssh­agent's cache:

[root@localhost ~]# ssh-add .ssh/id_rsa
Enter passphrase for .ssh/id_rsa:
Identity added: .ssh/id_rsa (.ssh/id_rsa)

Here are some extra commands that are pretty handy (for fingerprint and public keys)

[root@localhost ~]# ssh-add -l
2048 a2:cb:65:8c:c0:df:03:4d:52:47:02:45:72:c5:f2:42 .ssh/id_rsa (RSA)
[root@localhost ~]# ssh-add -L
ssh-rsa
AAAAB3NzaC1yc2EAAAABIwAAAQEA1zIwaq2FeUjeluQd33+P8Sh9ei6kgMJxAV5eKmGIe
pVaTPxJFl27wbjoNrPPJN0O3j4h6QhFyT3L4Nl+4x3cPn9wb4RHwY7nPihrnLJLdKc28p
MnaPSyVcZAVL0q6MkW/EDTo8bKCRu4XeAydwYlJjrJo+ilNILl180u4iPewSND5lAAws3
3X9gqb9SnBw583lZBzu3S79s4KWkqNoJqIARA/wSmEi08md7/Czyw0/RjmkEsiKAaG0lY
shB7g4XtFmV+QeE+LpF6EodeoWD82cuKbZ2jBEJPTuRrqMSsdermb4af0C14dytQh4OZ4
8tyj9qzL4bwaXuey6uPVHogt+YQuC7zvQ== .ssh/id_rsa

Not having to authenticate yourself manually is a great thing, but there are a few drawbacks to using this method.

Your “passphrase­less” SSH connection is only valid in the terminal window in which you enabled it. This means that you will have to redo these settings in any other terminal window that you use. You will have to redo your settings if you close the terminal where you initially made them. Although ssh­agent may now seem pointless to you now, there is a really neat solution…

Keychain is a bash shell script that allows one instance of ssh­agent to be reusedin other terminals. Previously, multiple eval `ssh­agent` commands would produce several instances of the ssh­agent process. On top of that, every time you log out and back into a particular account, another ssh­agent process is generated. In general, the ssh­agent seems like a wasteful little process.

After you succesfully installed keychain, add these lines to .bash_profile (assuming you're using bash)

keychain --clear
keychain ~/id_rsa
source ~/.ssh-agent > /dev/null
source ~/.keychain/localhost.localdomain-sh
source ~/.bashrc

A passphrase prompt for your private RSA key should have appeared. If not, then something is wrong. One thing that you might want to check are the files that are located in ~/.keychain for root (our user). The name of the file may be different from the one above but the last three characters will be the same. So, in .bash_profile, replace “localhost.localdomain­-sh” with the name of the file found in ~/.keychain. Otherwise, congratulations.

You are now able to use RSA/DSA encryption or SSH authentication by entering your passphrase whenever you login. If you really only want to enter your passphrase once per reboot, then you can simply remove “keychain –clear” from .bash_profile. The ­­clear option allows you to tell keychain to assume that every new login to your account should be considered a potential security breach until proven otherwise.

When you start keychain with the ­­clear option, keychain immediately flushes all your private keys from ssh­agent's cache when you log in, before performing its normal duties. Thus, if you're an intruder, keychain will prompt you for passphrases rather than giving you access to your existing set of cached keys. However, even though this enhances security, it does make things a bit more inconvenient and very similar to running ssh­agent all by itself, without keychain. Here, as is often the case, one can opt for greater security or greater convenience, but not both.

Despite this, using keychain with ­­clear still has advantages over using ssh­agent all by itself; remember, when you use keychain ­­clear, your cron jobs and scripts will still be able to establish passwordless connections; this is because your private keys are flushed at login, not logout. Since a logout from the system does not constitute a potential security breach, there's no reason for keychain to respond by flushing ssh­agent's keys. Thus, the ­­clear option an ideal choice for infrequently accessed servers that need to perform occasional secure copying tasks, such as backup servers, firewalls, and routers.

You can use cron to run scripts with scp command within, but you must take care of the following line (for root user; if other user, please correct the path):

source /root/.keychain/${HOSTNAME}-sh > /dev/null

This must be added in our script before scp/ssh operations. If not, you can receive errors like

 ...
 debug1: PEM_read_PrivateKey failed
 ...