[PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1

[Dan Kaminsky]

> ??? scp has _zero_ to do with ssh.

(if you'd rather not read all the UI theory, just skip to the section that
says IMPORTANT.)

Markus, I really would like a -e mode for scp; if nothing else it would
unify my rsync and scp syntax which are now painfully different.  But
that -e is a nice toy doesn't obscure the truth about what scp means for
ssh.

SCP is *the* standard method of transfering files over SSH.  It is the only
method that has always shipped with SSH.  It is the only method I'm really
supposed to be able to expect to work.  It's the one method I have the right
to get angry about failing all the ding dong day.

Think about this -- an SSH server is either locked down or incorrectly
configured if it doesn't support scp.  That's *not* the case if it doesn't
support rsync, or tar, or whatever.  This is a major difference that you're
not giving enough credence to!

> scp just happen to call 'ssh'. it can use every 8bit clean channel.
>
> scp just does rcp over some transport protocol.

Let me put it this way.

ssh is more than just rsh over some 8bit clean channel
scp is more than just rcp over some 8bit clean channel

It's beyond what it carries, Markus.  It's user expectations.  ssh(secure
shell) transmits a shell securely, scp(secure copy) retrieves a file
securely.  When I configure ssh, I say what shell I want and how secure I
want it.  When I configure scp, I say what file I want and how secure I want
it.

I don't care if scp has all of ssh's functions duplicated internally(as
actually happens on most win32 implementation of scp) or if it borrows them
from an ssh binary.  All I care about is that I get a file just like I got a
shell.  (From a security standpoint, it's troublesome that being able to get
a file means I have the client to receive a shell, but we'll overlook that
for now.)

> but _you_ are linking scp to ssh, so you are leaking implementation
details.

I'm saying, from the user's point of view, scp is ssh for file transfer.  If
I type:

ssh user at host

to get into somewhere, I can type:

scp user at host:file .

to copy a file from the default login directory to my own folder.

If I type:

ssh -c blowfish -2 -X -e! user at host

I've configured the cryptography of the session -- blowfish and SSH2 on the
holy 8 bit link -- as well as traits of the session itself:  I want X11
forwarding enabled and I want a different escape character.  And that's
OK -- SSH handles both with aplomb.  Similarly, if I type:

scp -c blowfish -2 -r user at host:path .

Again, I've configured the cryptography of the session -- blowfish *and*
ssh2 on the 8 bit link* -- but I've also specified a trait of the session:
Execute a recursive copy.  Now, yes, we could do:

scp -e "ssh -c blowfish -2" -r user at host:path .

[IMPORTANT]

But, heh, we didn't have to separate out our cryptography options from our
session options with ssh, why should we have to with scp?  And why should we
now explicitly need to specify our chosen tunneler, when before we had no
need?

And thus, we find the real problem.  For all you say that scp has nothing to
do with ssh, there's a pretty serious presumption in all four of these:

scp -F ssh_config -r user at host:path .
scp -o Protocol=2 -o Cipher=blowfish -r user at host:path .
scp -s,-2 -s,-c blowfish -r user at host:path .
scp -2 -c blowfish -r user at host:path .

All four of these presume they can give the "8 bit channel" marching orders
as to what type of crypto to use.  The first thinks -F ssh_config will be
respected just like ssh would; the second thinks -o options will be
understood as anything more than random characters, and the third and fourth
presume command line syntax matches.  They're all tied, and you just can't
get away from that.  Hiding behind a segregated syntax doesn't lessen your
assumptions one bit.

Don't get me wrong, Markus.  I like the idea of a -e mode; it makes rsync
very easy to move over bizarre ssh tunnels (like rsync over reverse tunneled
http).  But everything but -e makes huge assumptions about the 8 bit tunnel,
as well it should -- this is _s_cp, not _r_cp.  I _expect_ security to be an
equal if not greater concern than whether or not the files get there.  I
_expect_ I can give security orders just as I can give file copying orders.
Now, if I want to override the default security encapsulator with a -e, and
give it my own options, that's my business, but if not I expect it'll still
be secure, because it's "secure copy".

Those are my expectations.  What do you expect?

> it does not support ipv6 addresses.

And it has problems if I'm trying to copy a numbered file from the user's
default home directory.  Hmmm.  Any idea how URLs are adapting to IPV6?

--Dan