I've written some enhancements to scp.c and pathnames.h to enable the scp to arbitrarily set the remote scp path. (eg $ scp -e /usr/bin/scp foo user@bar:foo) I did read the "scp: command not found" FAQ entry but I'm not quite sure why we can't do this, unless it's because enhancements to scp are no longer a priority. Any other reason why it "is the way it is" other than that? The patch is below, all I've really done is replaced char cmd[CMDNEEDS] with char *rspcmd throughout. Forgive any dodgy coding, I'm not a developer during the day :). I haven't been able to test the patch below because I don't have a handy openbsd box, I have tested a patch under the portable version that seems to work fine. Let me know if I'm better off providing that. My reason for wanting is that it means server side scripts that wrap around forced commands can tie scp down to the absolute path. Incidentally, if there is a reason why anyone thinks this is a bad idea, please let me know.
Created attachment 745 [details] patches scp.c and pathname.h i don't think these two files have changed much since I created this patch (31/8/2004), so it should be fine to patch directly against the current openbsd openssh tree.
I'm not sure that we should add more scp options, when a user can just fix the server's $PATH. scp has required a working $PATH for many years and has survived without this.
My reason for wanting is that it means server side scripts that wrapper forced commands can tie scp down to the absolute path. When scp is executed is PATH being determined by the user shell (by virtue of the fact that sshd is doing a sh -c force_cmd)? In a restricted environment this would allow me to pattern match against the SSH_ORIGINAL_COMMAND, and I would rather be matching against an absolute (^/usr/bin/scp...$) command than a relative one (^scp...$). Perhaps my fears wrt relative path are unfounded.. Maybe this is unnecessary? a) because it isn't possible for a user to abuse the PATH variable; or b) because the PATH variable can be forced in .ssh/environment I fine with this patch being rejected if there's a better way to achieve what I want to do.
Reading of ~/.ssh/environment is controlled by the PermitUserEnvironment option in sshd_config. It defaults to "no". The other ssh-related vector by which the environment may be modified by the user is through environment passing (AcceptEnv in sshd_config, SendEnv in ssh_config), it too is off by default (on both the client and the server). So, assuming that the user can't modify shell initialisation files (e.g. .bashrc), the user's $PATH is under your control and you should be able to match on the bare command safely.
Change all RESOLVED bug to CLOSED with the exception of the ones fixed post-4.4.