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

[Dan Kaminsky]

> no, the equivalent is
> scp -e "ssh -2 -C -c blowfish" foo user at bar:/foo

Not supported in scp right now, though I was thinking it'd be a decent idea
for a while.  Now, I'm not so sure.

Mind you -- I *hate* using SCP -- but I finally figured out why it's not
entirely useless:  We can depend on it to exist on every system with a
correctly installed SSH daemon.  This is non-trivial -- not only can we not
depend on rsync being around, but we can't even depend on tar, cat, and ls:

    a) Existing at all (win32, for example)
    b) Behaving entirely predictably (as we've seen from "why doesn't this
graphical scp client do ls correctly?")

SCP is our backwards and forwards compatible method of knowing we can get
files from host a to host b using only what ships with OpenSSH.  It shares
ssh options because it *is* ssh, minus whatever options have zero bearings
on file transfer (like escape characters, or local port forwarding).

Perfect?  Hell no, that's why we're (slowly) migrating the world to SFTP.
_I_ don't use scp.  But I respect those who do, and I do understand what
needs others have.

The reason for needing -1 and -2 is at the intersection between user
interface and security -- essentially, if you pick the wrong SSH protocol,
your keys don't work, you don't connect, and you can't do anything.  That's
really painful when you're upgrading from SSH 1.2.27 to OpenSSH 3.0.2p2.
The solution is to be able to quickly look at the configuration options for
the tool and see an easily accessible option to twiddle.  The heirarchy of
these options is basically:

1) Start a secure link
2) Specify how secure you want that link
3) Start a file copy, with basic options
4) Specify detailed traits of that copy

Generally, the more critical an option, the more you want to make it easily
available to a user.  The -o set of options is nice to have, and certainly
can contain useful things -- but "without this, a good portion of connection
attempts will fail outright because you're using the wrong set of keys"
style configurations are much more critical and need to be "pushed to the
front", if you will.

In this typology, -1/-2 are level one critical, and clearly deserve to be
fronted.  -m and -l are mentioned by me for consistency in the UI -- they're
direct options in ssh that refer to security constraints at the same level
as -c and -C; they should be supported as they are in the genuine
lient.  -f is a toy that I can ignore.

Yeah, I did do UI design before I got into security :-)

--Dan