Hello I've searched quite a bit, but have so far been unsuccessful in finding an answer to a question I have concerning the upload of files via rsync over SSH. When downloading, I have been able to make use of SSH's benefits, yet still keep the rsync server safe from a shell accessible with a private SSH key lacking a passphrase by restricting the public key used by the rsync client to the one rsync operation it shall perform, something of the sort "rsync --sender --server <blabla>". That command showed up the in the sshd debug (or verbose) info on the rsync server. So far so good. Now I'm in a situation where I have to push data from the rsync client to the server. I'd also like to use SSH. Since this is an automated process I again need to use an empty SSH private key passphrase on the client. To make things worse, we're talking about access to the root account on the rsync server. I'd really like to restrict the capabilities of that SSH key. However, from the output of "rsync -vvv ..." on the client and "sshd -d ..." on the server it appears to me that no command is passed to the sshd on the server when uploading data. Is this correct? And is there a way to do what I want or do I need to drop SSH and resort to pure rsync, over IPSec perhaps (which doesn't provide for user auth, but rsync can do that, can't it)? Thanks for any help. Cheers, Tobias -- Tobias Reckhard secunet Security Networks AG Tel : +49(6196)95888-42 Mergenthalerallee 77 Fax : +49(6196)95888-88 D-65760 Eschborn E-Mail: tobias.reckhard@secunet.com
On Thu, Mar 13, 2003 at 01:33:52PM +0100, Reckhard, Tobias wrote:> Hello > > I've searched quite a bit, but have so far been unsuccessful in finding an > answer to a question I have concerning the upload of files via rsync over > SSH. > > When downloading, I have been able to make use of SSH's benefits, yet still > keep the rsync server safe from a shell accessible with a private SSH key > lacking a passphrase by restricting the public key used by the rsync client > to the one rsync operation it shall perform, something of the sort "rsync > --sender --server <blabla>". That command showed up the in the sshd debug > (or verbose) info on the rsync server. So far so good. > > Now I'm in a situation where I have to push data from the rsync client to > the server. I'd also like to use SSH. Since this is an automated process I > again need to use an empty SSH private key passphrase on the client. To makeOr use ssh-agent.> things worse, we're talking about access to the root account on the rsync > server.That is your choice or circumstance, not an rsync issue.> I'd really like to restrict the capabilities of that SSH key.You can do so. Using the command option in authorized keys. There have been several discussions of this in the mailing list. Check the archives.> However, from the output of "rsync -vvv ..." on the client and "sshd -d ..." > on the server it appears to me that no command is passed to the sshd on the > server when uploading data. Is this correct? And is there a way to do what IThe command is passed just like the download. You must have missed it.> want or do I need to drop SSH and resort to pure rsync, over IPSec perhaps > (which doesn't provide for user auth, but rsync can do that, can't it)?This has all been discussed within the last six months. Look for authorized_keys in the archives. -- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: jw@pegasys.ws Remember Cernan and Schmitt
2003-03-13T07:33:52 Reckhard, Tobias:> However, from the output of "rsync -vvv ..." on the client and "sshd -d ..." > on the server it appears to me that no command is passed to the sshd on the > server when uploading data.I'm not sure about those techniques for finding it, I haven't tried 'em, but whether the techniques have a hole or there was an observational error, J.W. Schultz was right, you missed it. Here's the trick to find it. sshd deals with a .authorized_keys file where a key line is preceeded by command="foo bar baz" (key here) by running foo, with args bar and baz, ignoring whatever command was requested by the client ssh. Instead, the client ssh's requested command is shoved into the environment variable SSH_ORIGINAL_COMMAND. So set up your key like this: command=/path/to/wrapper (key here) and have wrapper contain #!/bin/sh echo "$SSH_ORIGINAL_COMMAND" >>/tmp/sshcmdlog exec $SSH_ORIGINAL_COMMAND and try your rsync. It'll work as usual, and as a side-effect the command it requested will be logged. Then update your .authorized_keys line to reflect the exact command you want to allow and voila. -Bennett -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.samba.org/archive/rsync/attachments/20030313/3a57e395/attachment.bin
Hi [empty SSH key passphrase]> Or use ssh-agent.Yes, that's an alternative. I can't see a difference in functionality nor risk between the two, though.> > things worse, we're talking about access to the root > account on the rsync > > server. > > That is your choice or circumstance, not an rsync issue.I agree entirely. I made that statement to further justify my cause. I will be trying to move away from the root account, but, as you say, this is entirely independent of any rsync matters.> The command is passed just like the download. You must have > missed it.[snip]> This has all been discussed within the last six months. > Look for authorized_keys in the archives.OK, will do. Thanks for the pointer. I had checked the archives, but not found anything. Alas, I hadn't looked for "authorized_keys" but rather "SSH", "restrict", "command" and the like. That hadn't turned up anything (not within the first couple of dozen hits anyway). Thanks again and be seeing y'all. Tobias