Optional mandatory locking

Posted Dec 21, 2015 12:02 UTC (Mon) by oldtomas (guest, #72579)
In reply to: Optional mandatory locking by cuboci
Parent article: Optional mandatory locking

One of my favourite options for when the transport is SSH is the "command" feature of authorized_keys.

This way you can hook yourself into the action (and even do different processing depending on your customer's credentials).

This is the way gitolite and friends work. For an example on how to do it with rsync, see [1].

Or set up a gitolite, add a few users, go into ~gitolite/.ssh/authorized_keys and follow the breadcrumbs from there.

Missing piece: convince ssh's sftp module to be called from your wrapper script. But I'd expect it to be sufficiently unixy and well-behaved as to just accept some command line parameters and then take the bulk of communication over stdio.

[1] <http://www.sakana.fr/blog/2008/05/07/securing-automated-r...>

Optional mandatory locking

Posted Dec 21, 2015 23:12 UTC (Mon) by nix (subscriber, #2304) [Link] (1 responses)

Your mention of sftp reminds me that insufficient attention is paid to ssh subsystems, probably because they're relatively undocumented. They're not tied into ssh at all -- they're *really* easy to write. A subsystem is just a process whose stdin/stdout/stderr get transparently connected to an SSH stream: all the client end has to do is run ssh -s subsystem_name user@host.

It can be more appealing than authorized_keys commands in some situations (particularly when you want to be able to this for more than one user on the server without frotzing with all their authorized_keys files).

Optional mandatory locking

Posted Dec 22, 2015 12:55 UTC (Tue) by oldtomas (guest, #72579) [Link]

> A subsystem is just a process whose stdin/stdout/stderr get transparently connected to an SSH stream

So my hunch was right, thanks for clarifying that (gotta love the Unix Way :-)

> It can be more appealing than authorized_keys commands in some situations ([...] without frotzing with all their authorized_keys files)

The authorized_keys part serves a different and highly complementary purpose: if you want different clients to do different things depending on their identity (authentification + authorization). The possibility of "hooking in" is just a side-effect.

If you just want to hook in, perhaps substituting the sftp module by an "enhanced" one (which appropriately triggers things on transfer success/failure) would be most adequate, yes.