add scp path to _PATH_STDPATH

[Ishikawa]

>
> > I think a good solution would be define a new entry
> > in the sshd_config file which would be something like
> >
> >     PATH  subsystem-name  full-path-to-the-executable [, ...]
> >
>
> v2 protocol has no issues with this.  Since 'subsystem' defines out
> such things (One could more then likely tweak scp to work as a
> 'subsystem' with every little effort).
>

I am not that familiar with v1 protocol and so
this may be indeed very difficult to retrofit to the existing v1 protocol.

> Attempting to 'guess' the users intent is not always a good thing.

Generally speaking, this is true.

> ssh '/path/to/scp file machine:file'  .. Do we really want to strip
> the '/path/to/' off of that line and replace it with our path?  how
> do we know that /path/to/  is actually right?  It could be a modified scp
> that is in a different directory for a special task (not saying it's wise
> =).  Do you really want to remove the ability of the end-user to 'fix' scp
> if the ISP/shell provider has a broken one?  Maybe I wrote an add-on to
> scp and I wish to use my special version bewteen home and my
> ISP?  Changing standard behaviors is touchy.
>

Here I was a little confused and actually hoped someone would
clear this up when I wondered  if ssh_config (not sshD_config) was
needed.

Are you saying  that mean that the perceived scp problem
is only on the caller's side?
If so, I have no problem letting the user override the scp binary's path
at least.
[The problem I was thinking of is one in the case if the sshD needs to pick up

scp binary and somehow it can't.  Wasn't this the problem after all?
In this case (if so), I would not want
a remote user (even if somehow the user
successfully log in to run "scp" from any directory of the user's choice since

"scp" seems to be handled rather specially in ssh/sshd.
[Oh well, come to think of it, by then, the intruder or impersonator
can plant any binaries by simple "scp", if available, or whatever and
so this problem is moot by then.]
Maybe my understanding of how scp is handled within ssh/sshd
is totally incorrect. Let me see

      scp my-local-data remote-host:/tmp/t.dat

would invoke ssh locally and the remote host
would accept the ssh connection and run a program, right?
For example,
  scp -v /tmp/t.dat host.example.com:/tmp/t.dat
  Executing: program /usr/local/bin/ssh host host.example.com, user
(unspecified), command scp -v -t /tmp/t.dat
      ...
The program "scp" is searched on the REMOTE side,  and seems to use
the default path of sshd
I had a problem since I didn't installed scp in  the default PATH of sshd.
(Or rather the default PATH of sshd is restrictive as it should be.)
Since I had a nagging suspicion that future changes might introduce "other"
binaries
searched from the PATH, I was reluctant to add the additional directory in the
sshd's
PATH, but eventually did so.

>
> > Shouldn't such entries in sshd_config solve the problems discussed?
> > (Or do we need a similar entry for ssh_config as well?)
> >

When I wrote above, I didn't think that the client side (caller) needed to
worry
about this problem..

> Solutions:
>
> a) Back-port 'subsystem' concept to v1  .. Never will happen
> b) Fix up the path and ignore the problem.
> c) add support for scp as a subsystem for v2 and dump v1 support.
> d) Add some complex hack that could cause things to not work as the user
> expects them to under certian cases.
>

I trust the judgement of developers.

> do.  Minus the 'scp site:file site2:file' concept. =)

Yes, this one is a tough one.
(In this case, sshd on both the site and site2 need to be
able to pick up scp from their respective PATH. )
ftp have similar features and I wonder if sftp tries to
support such proxy copying, too.