[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#756172: ITP: ssh-cron -- cron-like job scheduler than handles ssh key passphrases

/me mutters something about being incompatible with reportbug...

The upstream author and URL should have been in the original report
(corrected below).

On 07/27/2014 01:54 AM, Marc Haber wrote:
> On Sat, 26 Jul 2014 21:05:37 -0700, tony mancill <tmancill@debian.org>
> wrote:
>> * Package name   : ssh-cron
>>  Version         : 0.91.01
>>  Upstream Author : Frank B. Brokken <f.b.brokken@rug.nl>
>> * URL            : http://sshcron.sourceforge.net/
>> * License        : GPL-2+
>>  Programming Lang: C++
>>  Description     : cron-like job scheduler than handles ssh key passphrases
>> ssh-cron acts like cron, but is provided with ssh passphrases allowing
>> its commands to access remote systems without requiring a passphrase
>> to be stored in a clear-text file or resorting to ssh keys without
>> passphrases.
> Why would one use such a tool? passphraseless keys exist, and can be
> configured to be secure.

Hello Marc,

Thank you, Ansgar and Paul for responses regarding other ways to perform
these tasks. Specifically:

> It is possible to restrict keys in .ssh/authorized_keys so that they are
> only allowed to run specific commands, see the 'command="command"' bit in
> man:sshd(8). One probably wants to combine this with no-port-forwarding
> and similar options.

and in more detail:

> http://blog.ganneff.de/blog/2007/12/29/ssh-triggers.html

The idea for ssh-cron is to be able to use the keys (one might currently
already have) without having to generate separate keys for triggers, and
while maintaining a passphrase.  Whether or not that's advisable given
alternatives such as ssh triggers depends on your risk tolerance and the
specifics of your environment.

It seems like with Ganneff's trigger mechanism, one attack vector is to
steal a backup of the passphraseless key and spoof the source IP - now
you can run the trigger at will.  Having a passphrase on the key could
at least slow the attacker down.  I could imagine using ssh-cron
together with "command=" for a higher level of security.

In any event, thank you for the discussion.  I'll confer with the
upstream author before proceeding with the package.


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: