scp -t - revisited.....

[Larry Becke]

Okay - We went around and around on the idea that adding an option to restrict scp to only allow files to be copied to a certain directory (or below) based on a different startup param.
 
I was told to use all sorts of different options, parameters, methods, etc...   All because no one wanted to modify the scp code, for whatever reasoning.
 
I'm sitting here laughing right now, seriously laughing, because the request was un-necessary.  scp already has that functionality built into it, whether it was intentional or not.
 
Here's the deal.
 
we set up a key on the client side, and the systems admin places the public component of the key into the users authorized_keys file with the command attribute set.
 
command="/usr/local/bin/scp -t /data/work/test" ssh-dss AAAAB3keycodefollows......
 
Then when the client issues the command
 
scp -i test_key /path/to/filename user at remotehost:
 
It copies the to the remote host into the directory specified in the command= option.
 
Now, at first glance, you're probably thinking  - wth is he talking about?  so what?
 
We had been using this for a while, and within the last few days had the first user attempt to rename a file in transit.
 
scp -i test_key /path/to/filename user at remotehost:filename.0001
 
The only problem was, that the file was always copied with the original filename.
 
I dug into it, not even thinking about the unorthadox approach I had taken to placing the users files into a specific directory, until all attempts at reproducing the problem had failed.  Once I used the same key structure and command= approach, the *rename problem* showed up.
 
I then decided to test a few other vectors - lke placing a directory name, or directory shift into the remote filename.
 
scp -i test_key/path/to/filename user at remotehost:../
or
scp -i test_key/path/to/filename user at remotehost:subdir/
 
Again, the file was copied over into the directory specified in the command= section, and nowhere else.
 
This leads me to believe that using the scp -t /some/path/to/a/directory  command= in the authorized_keys file causes scp to forget/ignore everything after the remote hostname.
 
This gives us almost exactly what we were looking for (actually, it's overkill, but I'm okay with that), and no changes were required.
 
Like I said, I'm sitting here laughing right now, mostly because it was a lot of wasted effort on all sides to argue (or discuss with pointed statements) over something that already existed, even if it wasn't known or documented.
 
 
 
(Wonders if this will be considered a bug to be fixed or quashed as it wasn't an intended *feature* of scp)....   I hope not...
 
Thanks again,
 
LB
 
 
_________________________________________________________________
Share life as it happens with the new Windows Live.Download today it's FREE!
http://www.windowslive.com/share.html?ocid=TXT_TAGLM_Wave2_sharelife_112007