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

Dan Kaminsky dan at doxpara.com
Tue Jan 29 00:33:26 EST 2002


> On Mon, Jan 28, 2002 at 04:46:47AM -0800, Dan Kaminsky wrote:
> > I guess my question to you, Markus, is this:  When is an option
important
> > enough to add to the command line of ssh, but *not* for the exact same
> > reasons important enough to add to scp?
>
> always.

*laughs* Me, Mr. "Encapsulate it all and let God sort it out", arguing for
integration?  Quelle horror!

Look.  bin/ssh integrates shells, commands, and TCP port forwards into a
multiplexed cryptographically secure session.

bin/scp integrates file transfer into a multiplexed cryptographically secure
session.

We *could* encapsulate file transfer any number of ways -- we could TCP
forward HTTP, we could use my various cat/tar/ls hacks, we could do any
number of things.  Implementation-wise, we actually do encapsulate scp
inside of ssh.

But as far as the user knows, scp is the integrated alternative to various
other methods.  They chose the self-contained entity, distributed as part of
SSH, that provides rcp-style semantics to access files on remote hosts.
There are times where I want to deal with the various aspects of packaging
one system inside of another -- but the SSH way is to integrate to a point
and then encapsulate the rest.  We can depend on the ability to transfer
files, much as we can depend on the ability to forward ports or access our
remote shells with fully correct terminal support.

It's a different approach.  It's not the same as rsync, it's not the same as
tar.  But forcing scp into the encapsulation paradigm is conceptually
incorrect -- you're leaking implementation details into what is
psychologically just another entity ssh supports.  Sure, a different command
line is needed, and we need to specify files to move instead of commands to
remotely execute -- but in the end, "ssh supports file transfer, because
file transfer is important".

Heh.  I don't like SCP; I find it limiting.  But I see where its users are
coming from, and really, all it costs us to support command parity is the
non-usage of -rBSDf for file-transfer relevant options in ssh.  This is a
small piece of latitude for what is clearly a very important knob for users
to be able to easily tweak!

Regarding ports -- I built a patch a while back to allow this syntax.  Any
objection to it?

ssh user at host:port
scp user at host:port:/path .

this mirrors standard URL syntax pretty closely.

--Dan





More information about the openssh-unix-dev mailing list