Dryice Liu’s Blog

(originally posted at www.linuxboxadmin.com )

This time we’ll talk about transferring files using OpenSSH. The most
common ways to transfer files between Unix hosts are: rcp, ftp, and
rsync.

• rcp and its SSH version: scpThe command rcp works like cp, but it can copy files to and from
  remote files. For example, if you want to copy a “test” file in the
  current directory from your localhost to ~/temp in your remote
  machine, you can do a command like this:

The key is the last parameter. It specifies the machine to which you
want to copy to, and the login name on that machine. The part after
“:” is the path. If it starts with “/”, is an absolute path, else
it’s a relative path against the HOME directory of the account. Of
course you can copy files from a remote machine to the local machine,
or even copy files from one remote machine to another remote machine.

However, there are some drawbacks using rcp.

First, as we stated in the first part of this article, rcp transfer
the files without encryption. Which means someone could read you
files on the fly. Second, rcp is based on rsh. And using rsh requires
the remote running the rshd server. Based on the “more service, more
security holes” statement, many sysadmins won’t run rshd. Thus the
machines you could rcp to/from is limited. More than that, rshd
checks /etc/hosts.equiv first to see if the machine you are on is
trusted. This limits more.

The scp command, as the ssh version of rcp, works exactly like rcp:

This will do the same as the rcp command example above. But want
happened is different: It will invoke ssh to login to the remote
machine, asking your password or ssh key passphase depending on which
authorization method you use, and then copy the files, with the files
encrypted, and finally close the connection using ssh.

The advantages over rcp is:

1. The files are encrypted.
2. Most machines now running the OpenSSH service, so you can copy to
   remote machines as long as you can ssh to that machine.
3. Mort than that, you can use the “-C” flag to transfer the file
   compressed. This saves bandwidth and time.

• ftp, sftp, and ftp over sshFTP is one of the most commonly used program/protocol on the Internet
  and I don’t think I’ll need to say anything about it. If you want to
  transfer files as you are using FTP, but with encryption, you can try
  sftp.SFTP is a subsystem of OpenSSH. First it need to be enabled on the
  server. For this you’ll need to add or un-comment the following line
  in /etc/ssh/sshd_config:

The 3rd part points to the sftp-server program, and may vary on
different distros.

Now more and more FTP clients support SFTP, the command line
lftp(http://ftp.yars.free.net/projects/lftp/), the graphic gFTP
(http://gftp.seul.org/), and FileZilla
(http://filezilla.sourceforge.net/). If your favorite client doesn’t
support SFTP, switch to some program that thinks more for your
security

Well, I’m kidding. If you insist on using your favorite FTP client
and you want the security of OpenSSH, or sftp-server is not
configured on the remote host, there is a way: Using the port forward
of OpenSSH. I’ll talk more about port forwarding in the next article,
but here’s a simple howto:

First, we need to setup the tunnel:

Here “-f” makes ssh to folk to background. Thus you won’t waste a
terminal. The key information is after “-L”. It’s a three field
parameter. The first filed specifies the port number on the localhost
that the ssh tunnel will bind to. Make sure you use port numbers
greater than 1024. Because on most Linux distros only the root user
can bind to port number less than 1024, and most of these numbers are
well known and reserved for server programs. The second field is the
remote host name or IP address. It should be the same as in
“user-name@remote-host”. The third field is the port number on which
the ftp server on the remote host is listening. By default (RFC959)
it is 21 (The command socket, if you are really a geek). The last
part of this example is a random command. Because without a command
ssh won’t goto background. “tail -f /etc/motd” is a good choice.

With these all set, now you can set your favorite client: change the
port number to 1234 or whichever number you choose above, and change
the server to “localhost”. For example, if you are using lftp, you
could use something like

Note you’ll need to use “-u” to specify the username, or lftp with
use “anonymous” as default.

• rsync, and rsync via ssh”rsync” is a very useful tool if you have access to several
  machines. It can “sync” two directories, on two different
  machines. Because it compares the two directories first, and only
  transfers the files that are different, and use compression when
  transferring, it is very fast compared to FTP.”rsync” used to use rsh for remote shell, and some modern versions
  use ssh as the remote shell. So this really depends on how your
  system is configured. However, you can always use the “-e” option or
  set the RSYNC_RSH environment variable to use ssh as the remote
  access shell. The following two examples are doing the same thing:

They all “sync” the /local/directory on local machine and the
/remote/directory on the remote-machine. Note I’m using bash like
syntax for export. Csh users should be a little different.

• Save some key strokes, and time: using ssh agentIf you use the most secure way of ssh: key based authorization with a
  passphase to protect the private key, and you use the file transfer
  command we talked above alot, there is a problem: You need to type in
  the passphase every time you issue a command. And this comes boring
  quite soon.This is where ssh-agent comes handy: it will hold your private
  keys. And when some command need the key, it will provide it. This is
  just the idea how ssh-agent helps, actually ssh-agent will never
  send a private key out. instead, ssh-agent will perform the
  authorization operation, and send the result back to the command that
  uses ssh. This is for security reason: To protect our private key.If you run ssh-agent, it will print some shell script, like this:

This is for sh-like shells, for csh user, use the “-c” option:

The SSH_AUTH_SOCK variable holds the unix-domain socket for the agent, and only the user who started the agent (or root) can access it.

The SSH_AGENT_PID variable holds the PID of the agent.

Later ssh commands will use these environment variable to find the agent. So we’ll need to make these available:

The “-s” option will make sure ssh-agent print in sh-like syntax,
which is the default on most systems.

“ssh-agent” command only starts the agent. And we’ll need “ssh-add”
command to add the private keys to the agent. It will find all your
private keys, ask passphase if necessary, and then add them to the
agent.

It is recommend to start the agent when you first login, before
starting X or screen(1). So all your following commands will be aware
of the agent and no longer ask the passphase. However there is a
security problem: If you left your screen unlocked, someone may act
as you and do bad things on remote machines. This is something to
balance, and you should never left your screen un-locked.

Ssh-agent will exit if you terminate the shell where ssh-agent is
started. If setting up ssh-agent on every login is boring for you
too, there is keychain (http://www.gentoo.org/proj/en/keychain/) to
help you. It will re-use the agent across logins. This is really
useful on a remote server, which typically runs several hundreds days
uptime.

Share This

Tags: freebsd, ftp, openssh, rcp, rsync, scp, sftp, ssh, ssh-agent