Re: scp -t . - possible idea for additional parameter‏

Larry Becke guyverdh at
Thu Oct 11 02:00:43 EST 2007

>> I understand that that is not how scp works today.>And it will likely never change.
Why not?  Just because "That's how we've always not done it" doesn't sound like a very good reason to me.
>> I'm suggesting that we make a minor change to how it works.>scp is maintained for compatibility reasons only, as I've understood>things.
That's still not a valid reason to not implement a very simple change.
>> I am suggesting this will make it trivial to secure one subset of>> the system.  That subset being scp.>Moot point unless scp is the only way users can use the system, which>I don't think is the case all too often.
In my specific case, it is the point.   I'm using a public key authentication, where the parameter defined in the authorized_keys file is
command="/usr/local/bin/scp -t /some/path/to/dir" ....remainder of key....
>Either you're prepared to make an effort in order to make the system>secure, or it doesn't matter. Hacking up scp is good for neither. :\
Why should *everyone else in the world* have to go through all the hassle of trying to make a "secure" product secure, when a very simple fix, would effectively lock scp so that it couldn't go anywhere above the directory specified in the startup with the -T (like -t) parameter.
The simple change outlined would truly make scp *secure* from all perspectives, as opposed to only being secure via the transport.  It could be a significant feather in the cap of the project.
If the -T were configurable to be a selectable (either through the build process, or the sshd_config file) all scp transfers could be locked into the user's home directory, which wouldn't be a bad thing at all for those who would want it to be that way.
Help yourself to FREE treats served up daily at the Messenger Café. Stop by today.

More information about the openssh-unix-dev mailing list