Consider the situation where a computer every now and then must access a remote computer to do some useful things at that remote computer (like running a stealth(1) file integrity scan). In order to do so the computer must be allowed to make ssh(1) connections to the remote computer. But since the commands are not executed by the user but by cron(1), the ssh-keys which are required to access the remote computer cannot use passphrases.
This is an undesirable situation: if the computer running the ssh commands gets compromised, then the remote computers are compromised as well, since the attacker may access these remote systems using ssh keys not requiring pass phrases.
Ssh-Cron offers a way out of this undesirable situation, while still allowing commands to be executed on remote computers. Here's how this is realized:
When shell control characters (like redirection symbols) must be used in command specifications, they should be escaped. E.g., as in echo hello world \> /dev/null.
Users sharing a computer each define their own ssh-cron specification file. When a user logs out and leaves the system the daemon process continues to run, executing its scheduled commands at their scheduled times, using ssh-keys whenever required.
If the accounts for which ssh-cron jobs are running are ever compromised, the remote computers remain safe, as the passphrases of the available ssh-keys remain unavailable.
To prevent unauthorized modifications of the commands scheduled by the ssh-cron daemon themselves a passphrase is required when starting ssh-cron's daemon process. The passphrase itself is not stored by the daemon (instead, it stores a sha256(1) hash value), which avoids access to the ssh-cron daemon's passphrase by browsing the computer's memory. The passphrase may be empty, but even then that empty passphrase must be provided when reloading ssh-cron daemon's scheduled commands. The scheduled commands may be listed, however. This is allowed without providing a passphrase since the file containing the scheduled commands will usually also be available on the computer. Likewise, since a user may always terminate his/her own programs an ssh-cron daemon process can be terminated from another ssh-cron program using the --terminate command line option.
The above-mentioned facilities are not supported by crontab(1) itself. Cron(1), which is responsible for executing scheduled crontab commands, has no access to the passphrases of ssh-keys (which are otherwise provided ssh-agent).
Ssh-Cron returns 0 if the daemon was successfully started. Otherwise 1 is returned.
Where available, single letter options are listed between parentheses following their associated long-option variants. Single letter options require arguments if their associated long options also require arguments.
Several options have default values. Run ssh-cron --help for an overview of the implemented default option values. Also, several options can be specified in a configuration file (where this doesn't hold true, it is explicitly mentioned at the relevant options).
The configuration file (not to be confused with the file containing the scheduled commands, which is provided as ssh-cron command-line file argument) ignores empty lines and all information on lines starting at a hash-mark (#, optionally preceded by blanks and/or tabs). The configuration file is used to specify ssh-cron's options using their long variants. However, in the configuration file the initial hyphens of command-line options must be omitted, and optionally a colon may be appended to these long options names. Note that multi-word option arguments should not be surrounded by quotes. Examples:
stdout
syslog-facility: LOCAL0
mailer: /usr/bin/mail -s "some subject" me@myhost.warpnet.nl
Command-line options always override configuration file options.
By default /usr/bin/ssh-agent /bin/bash is used.
By default ~/.ssh-cron is used.
This option cannot be specified in the configuration file.
This option cannot be specified in the configuration file.
By default ~/.ssh-cron.ipc is used.
This option cannot be specified in the configuration file.
By default /usr/bin/mail -s \"Ssh-cron $*\" $USER@localhost is used, with $* replaced by the exected command as specified in the crontab file argument.
This option cannot be specified in the configuration file.
This option cannot be specified in the configuration file.
This option cannot be specified in the configuration file.
By default facility DAEMON is used.
By default priority NOTICE is used.
By default the tag SSH-CRON is used.
This option cannot be specified in the configuration file.
When using rsyslogd(1) property based filters may be used to filter syslog messages and write them to a file of your choice. E.g., to filter messages starting with the syslog message tag (e.g., SSH-CRON) use
:syslogtag, isequal, "SSH-CRON:" /var/log/ssh-cron.log
:syslogtag, isequal, "SSH-CRON:" ~
Note that the colon is part of the tag, but is not specified with the
syslog-tag option.
This causes all messages having the SSH-CRON: tag to be written on /var/log/ssh-cron.log after which they are discarded. More extensive filtering is also supported, see, e.g., http://www.rsyslog.com/doc/rsyslog_conf_filter.html and http://www.rsyslog.com/doc/property_replacer.html
cron(1), crontab(1), crontab(5), , rsyslogd(1), ssh(1), ssh-add(1), ssh-agent(1), ssh-askpass(1), stealth(1), syslog(3)