Solaris 10: How to Copying Files with scp

In The Name Of Allah The Beneficent The Merciful 

The OpenSSH suite of programs is one of my favourite toolkits for administration of servers on a LAN. I routinely use the scp command to copy files between systems and move stuff around as required. In effect, it replaces the old rcp command, but it much more secure as well as more convenient to use.
To copy files between two machines, say 192.168.1.101 and 192.168.1.100, sit at 192.168.1.101 and use the following command:
scp * 192.168.1.100:

Simple as that! Assuming you are the same user id on both machines, this will copy all files in the current directory to your home directory on the destination machine, 192.168.1.100. The first thing the command will do, though, is ask you for your password on the remote system - once you supply that, then you'll see the files copied, with progress bars.
Now, if you want to copy only some files, e.g. all txt files, use a standard wildcard, like this:
scp *.txt 192.168.1.100:

Suppose you want to copy them to a destination directory other than your home directory, use:
scp *.txt 192.168.1.100:/home/username/directory

Of course, you have to have write permission on the target directory.
Suppose you want to copy files from the other machine back to the one you're on - then use this syntax:
scp 192.168.1.100:*.txt .

If you have a DNS or hosts file set up, then you can (and should) use hostnames in the command, like this:
scp mail/* mailsrvr:/home/joe/mail

This will copy the contents of the mail subdirectory (of the current directory) on this machine, to the directory /home/joe/mail on the machine mailsrvr.
How Does It Work?
In general, the syntax for scp (as for cp) is:
scp [option...] source destination

where source and destination can each take the form:
[hostname:][dir-path][filespec]

or

[ip-addr:][dir-path][filespec]

The [ ] indicates something is optional. The big difference from the cp command is the use of a hostname or IP address on either the source, destination or (unusually) both. Notice that the hostname or IP address must be followed by a colon; a common mistake (I do it all the time) is to type something like:

scp fubar.zot 192.168.1.100


but the file doesn't turn up on 192.168.1.100. So what happened? Answer: you created a file called "192.168.1.100" that contains the same thing as fubar.zot!
If you find the password prompting is a nuisance, then you can create a private/public key pair, upload the public key to the remote system, and then use the SSH agent to supply your private key automatically.

Creating an RSA key for SSH v2 Protocol

• 1. Pair up with another student so that you are able to work on each other's systems. One of you will use the tux1 account and the other should use the tux2 account. The following instructions are written from the perspective of the user at the linux.group3.pvt machine, creating a private key for tux1 to log into linux.group4.pvt. You should be careful to modify the instructions to suit your particular classroom environment.
• 2. Log in as either tux1 or tux2 (the password should still be the word "password").
• 3. To create a 1024-bit RSA key for use with the version 2 protocol, give the command:

ssh-keygen -t rsa -b 1024

You will be asked for the file in which to save the key. Accept the default ot ~/.ssh/id_rsa. Enter a passphrase (for this exercise, to avoid confusion, use the passphrase "openssh"). Enter the passphrase a second time to confirm it. You should now see messages like this:
Your identification has been saved in /home/tux1/.ssh/id_rsa/
Your public key has been saved in /home/tux1/.ssh/id_rsa.pub.
The key fingerprint is:
6a:f5:19:11:6a:ab:46:4b:61:67:31:e8:11:9e:eb:16 tux1@linux.group3.pvt

The identification is the private key (in fact, for the SSH version 1 protocol, the file used to be called 'identity').

• 4. Copy your public key to the remote system, using the scp command and authenticating by password (after all, there is no public key on the remote system yet):

scp .ssh/id_rsa.pub linux.group4.pvt:.ssh/
The authenticity of host 'linux.group4.pvt (192.168.0.4) can't be established.
RSA key fingerprint is 22:68:47:8b:a3:e3:f8:61:c7:10:0f:80:eb:78:45:d3.
Are you sure you want to continue connecting (yes/no)?

Answer yes (careful: you must type "yes", not "y" or just enter). Warning: Permanently added 'linux.group4.pvt,192.168.0.4' (RSA) to the list of known hosts.
tux1@linux.group4.pvt's password:

Enter the correct password.
id_rsa.pub     100% |***************************************|  242   00:00

• 5. Log in to the remote host, using ssh:

[tux1@linux tux1]$ ssh linux.group4.pvt
tux1@linux.group4.pvt's password:
[tux1@linux tux1]$ cd .ssh
[tux1@linux .ssh]$

Now concatenate your public key onto the end of the authorized_keys2 file. If this file does not exist, then it's simplest to just: [tux1@linux .ssh]$ cp id_rsa.pub authorized_keys2

However, if the file exists, then concatenate the new public key with the command:
[tux1@linux .ssh]$ cat id_rsa.pub >>authorized_keys2

• 6. Now log out, and then ssh back into linux.group4.pvt:

[tux1@linux .ssh]$ logout
[tux1@linux .ssh]$ ssh linux.group4.pvt

Now, one of two things is going to happen. You might see: Enter passphrase for key '/home/tux1/.ssh/id_rsa':

In which case, congratulations! Or you might see
tux1@linux.group4.pvt's password:

which means you are being asked to authenticate by password, rather than your new private key. Why is this? If you provide the password and log in, then su to root, you can investigate by looking at the tail of /var/log/messages:
[tux1@linux .ssh]$ su -
Password:
[root@linux root]# tail /var/log/messages
. . .
. . .
Apr 29 14:24:07 linux sshd[26222]: Authentication refused: bad ownership or modes for file /home/tux1/.ssh/authorized_keys2
Apr 29 14:24:12 linux sshd[26222]: Accepted password for tux1 from 192.168.0.3 port 33640 ssh2
Apr 29 14:24:07 linux sshd[26222]:

The second-last line provides the clue: Bad modes is the usual reason why private-key authentication fails for first-time setup. If you check the permissions on the file, you will see the problem:
[tux1@linux .ssh]$ ls -l
total 7
-rw-r-----    1 les      les           710 Jun  2 20:19 authorized_keys2
-rw-r--r--    1 les      les           242 Jun  2 20:08 id_rsa.pub
-rw-r--r--    1 les      les          3784 May 31 15:40 known_hosts
-rw-r--r--    1 les      les           225 May 31 15:40 known_hosts2
[tux1@linux .ssh]$

The authorized_keys2 file must be rw for its owner and not accessible by others. You should also check the permissions on the .ssh directory itself, which should be drwx------. So:
[tux1@linux .ssh]$ chmod 700 .
[tux1@linux .ssh]$ chmod 600 authorized_keys2
[tux1@linux .ssh]$ logout

[tux1@linux .ssh]$ ssh linux.group4.pvt
Enter passphrase for key '/home/tux1/.ssh/id_rsa':

Now you're in business!
Eliminating the Passphrase Prompts
When working at a desktop machine, particularly under the X environment where you might have multiple windows open (and keep closing and reopening windows), the constant prompting for passphrases as you log into other systems can become tedious. You can eliminate those prompts by using the ssh-agent program.

• 1. Log out of the remote host that you are currently logged in to, so that you are back to working on your own machine again.

logout
[tux1@linux tux1]$

• 2. Use the ssh-agent program to load your private key for once and for all:

[tux1@linux tux1]$ ssh-add
Enter passphrase for /home/tux1/,ssh/id_rsa:
Identity added: /home/tux1/.ssh/id_rsa (/home/tux1/.ssh/id_rsa)
[tux1@linux tux1]$

• 3. Connect to your remote target - you should not be prompted for a password:

ssh linux.group4.pvt
[tux1@linux tux1]$

• 4. Log out of the remote system, and then remove all local private keys from the agent:

logout
[tux1@linux tux1]$ ssh-add -D
All identities removed.
[tux1@linux tux1]$

If you attempt to log into the remote system, you will now be prompted for the passphrase on any applicable private key, or for a password. If you want to temporarily lock the agent while away from your desk (in which case, why aren't you either locking the entire X session or logging out completely?), you can do it with the command ssh-add -x. You can use ssh-add -X to unlock it upon your return.