On 2002-01-22 at 21:14 -0500, Greg Ward wrote:
> Personally, I would use scp for the transfer, but that's a side issue.
It is a side issue, but since it has been recommended publically, I'd
like the archives to contain a warning.
Using "scp" to transfer data has a number of risks. It's the old "rcp"
protocol run over SSH. "rcp" uses newline-termination of commands. If
a transferred filename has a newline in it, then you have problems. If
the scp client doesn't check for this (many older ones) then a
maliciously-constructed filename can result in sending arbitrary scp
commands to the remote side. If it's a newer client, then the transfer
will just fail.
SSH.com's scp client uses the SFTP protocol when run over SSHv2. This
is better.
If available, sftp should be used. Always. It's a significantly better
protocol which is cleanly designed and does not have security-issues
designed in. It's _possible_ to write a clean secure uncrippled client
that uses SFTP, but not for SCP.
The sftp(1) command which is part of OpenSSH unfortunately does not
allow pushing a file to a remote host non-interactively, unless you use
complicated wrappers to supply interactive commands. Files can at least
be retrieved from one command-line easily.
If it's a once-off transfer and you can lock the data down (eg, shutting
down the MTA) for a little longer, then tar(1) it up, then send it. scp
will be fine, since it's one specified filename, which you've chosen.
Then untar it. This handles the behaviour which seems to be needed
here.
(For repeated transfers of arbitrary files, the current easy good
solution is rsync-over-ssh).
--
PHB: It needs to be so easy that your mother could use it.
Dilbert: My mother isn't a moron. Maybe we could use your mother as a test.
PHB: What makes you think my mother is a moron?
Dilbert: She fed you.
