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
Oh- it also makes the scp send only. ie - you cannot copy a file from the remote host, to the local host. _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_102007
On Thu, 6 Dec 2007, Larry Becke wrote:>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.internally, local scp runs "ssh <HOST> scp -t/-f <PATH>". With command= in authorized keys file, the command set on ssh command line is ignored and "command=..." is used instead.> (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...it has nothing to do with scp. The local scp process doesn't know about it at all, neither the scp process on remote side. -- Jan Pechanec
On Thu, 6 Dec 2007, Larry Becke wrote:>Oh- it also makes the scp send only. > >ie - you cannot copy a file from the remote host, to the local host.correct. For copying from remote side, you run that internall ssh with (slightly simplified) "scp -f <FILE>". Well, you could set another key and you could always copy the same file :-) -- Jan Pechanec
On Thu, Dec 06, 2007 at 05:26:14PM -0600, Larry Becke wrote:> 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.There is one more step between the remote scp (run with -t) and the "remote filename" as specified in the local shell: The local scp.> This gives us almost exactly what we were looking forI think that depends on the local scp program. What happens if you (within the scp protocol, not in the shell) specify e.g. a new directory ../../../../../../../tmp/breakout ? I would assume that /tmp/breakout is created. If your local scp program is trusted then you're all set. But if that was the case why bother with locking down the server?> 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.I still believe there was a good reason for that argument.> (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...It's just a side effect of the rcp/scp design. //Peter
*My apologies for mangling this, as I'm not a subscriber, and peter doesn't deign to reply to me as well as the list* On Thu, Dec 06, 2007 at 05:26:14PM -0600, Larry Becke wrote:>> 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.>There is one more step between the remote scp (run with -t) and the>"remote filename" as specified in the local shell: The local scp. You're right as long as the scp client has the power to do anything, beyond send the file names/content. However, with this method, the local scp is powerless.>> This gives us almost exactly what we were looking for>I think that depends on the local scp program.Sorry, not with this method.>What happens if you (within the scp protocol, not in the shell)>specify e.g. a new directory ../../../../../../../tmp/breakout ?>I would assume that /tmp/breakout is created. Again, not with this method.>If your local scp program is trusted then you're all set. But if that>was the case why bother with locking down the server?Unfortunately (or in my case, fortunately), that's not how scp works. Using scp as you showed, would not do anything to this method. The reason being is as follows... scp -i key_file localfile remotehost:../../../../../../../../../../../tmp/breakout what really happens, as near as I've been able to figure out with the information that J.P. sent me, is that the client (or local) system executes the following. ssh -i key_file {remotehost} scp -d -t ../../../../../../../../../../../tmp/breakout now - normally this would cause the effect that you mentioned - except for one minor little thing. The ssh key in question, is configured on the server to only run "scp -t /server/selected/path" This overrides the command that was sent by the scp client, and replaces it with what we want to happen. No directory selection, it gets rid of all your carefully crafted pathing exploit attempts - they're all gone, as though they never existed. Now, the scp -t starts the scp server service in receive mode (this is an assumption on my part), waiting for the client to send the commands needed to create the file and it's contents (or multiple files and their contents). This is the cool part - no matter what you *try* to do with the scp client, it will never do anything other than go into receive mode and wait for the transfer commands. Now, if the scp protocol can be exploited some how beyond the open file / send contents, then we may have a problem - but that would be the case with scp in general. I would also assume that using another key to put the scp server side into send mode - ie scp -f /server/selected/path - would restrict downloads from the specified directory, again, regardless of what the client asked for.>> 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.>I still believe there was a good reason for that argument.You're free to believe what you want, I found what I wanted - and it works - very well.>> (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...>It's just a side effect of the rcp/scp design. Which apparently neither of us were 100% up on, and I was glad for the opportunity to learn something new. I hope you did as well.>//Peter LB _________________________________________________________________ You keep typing, we keep giving. Download Messenger and join the i?m Initiative now. http://im.live.com/messenger/im/home/?source=TAGLM