scp remote path specification

[Jan IVEN]

>>>>> "PS" == Pekka Savola <pekkas at netcore.fi> writes:

 PS> On 18 Dec 2000, Jan IVEN wrote:
 >> Hello,
 >> 
 >> in order to use "scp", the scp binary has to be in the compile-time
 >> default path on the remote host. For some users (like root), we try to
 >> avoid this since scp may be on a network file system (AFS/NFS), and we
 >> don't want to hang root's session on network outages.
 >> 
 >> Would a patch to scp be acceptable in the main tree that allows to set
 >> the path to remote scp explicity, either as a new command line or as
 >> an ENV variable (it looks like a ssh config file parameter won't work,
 >> since the file is not read by scp itself).
 >> 
 >> I know that a workaround is to put "PATH=/path/to/bla" into these user's
 >> .ssh/environment or as a parameter to their key, but I don't want this
 >> PATH to be taken for interactive use.
 >> 
 >> Please advise.
 >> 
 >> Best regards
 >> Jan Iven
 >> 
 >> PS: a small patch so that /full/path/to/scp will find the
 >> corresponding local /full/path/to/ssh is appended below.

 PS> If I'm not mistaken, with this you can force the remote server to execute
 PS> a trojaned ssh, if you run e.g. '/tmp/scp user at remote:xxx .' and have
 PS> managed to create /tmp/ssh on the remote system.

 PS> Doesn't look good as this this breaks sshd expectations with regard to
 PS> PATH and what users can control.

Not sure whether the remark applies to the proposed stuff or the
attached patch. My understanding of the execution sequence is as
follows:

local: scp user at remote:xxx
local scp runs local ssh,
   specifies remote command "scp": ssh user at remote scp -{r|-t} xxx
local ssh contacts remote server, authenticates
remote server runs "scp" in user context

proposed change: pass "/path/to/scp" as command to server instead of
"scp". Still runs in user context, and can be done directly from ssh
as well right now (without using local scp). No additional security
risk as far as I can see.

attached patch: help local scp find the local ssh. Server is not
involved. Security risk if you can get somebody to run a version of
scp (with full path) that lives in a directory with a trojan ssh, so
the trojan will get executed in local user context. But if permissions
on the directory allow for an trojan ssh, they probably allow for
installation of a trojaned scp as well.

Please correct me if I'm wrong.

Regards
Jan