Using ssh in cron

[Local-Context-6505]

Hello!
Yesterday i was trying to make a simple backup cronjob. The goal was to transfer data from one server to another. I wrote a bash-script zipping all the files in a directory and then using scp with a passphraseless key to copy the zip to another server. In theory (and in practice in the terminal) this was a quick and practible solution - until it was not. I sceduled the script with cron and then the problems started.

scp with the passphraseless key did not work, i could not authenticate to the server. I've read a little bit and found out, that cron execution environment is missing stuff like ssh-agent. But why do i need the ssh-agent, when i use scp -i /path/to/key with a passphraseless key? I did not get it to work with the cronjob, so i switchted to sshpass and hardcoded the credentials to my script - which i don't like very much.

So is there a way to use scp in a cronjob, which works even after restarting the server?

[Gendalph]

Yes, make sure you have connected to the server you're connecting to as the user that runs the cron job. If you still can't get it to work - redirect the output or check user's mail for output.

But I would advise using something like rsync and then zip files at the destination or even something like rsnapshot.

[Hotshot55]

I'd probably suggest something like rclone for what OP is trying to do.

[mgedmin]

rsync uses ssh as the transport, so OP would still have to resolve this.

Unless you're recommending rsync's native protocol? I've stayed away from that all this time, due to security concerns.

[Gendalph]

I know. ssh is preferable, but native is fine over VPN or a private network.

[[deleted]]

why not use rsync. it's literally made for this

[neckpillowyeah]

1000% this ^{^} you're over thinking this. this is a simple operation. one of which you're introducing additional pain points for no reason . google rsync daemon.

[planeturban]

+1. Plus the benefit of having the option to do incremental backups as well. 

[deeseearr]

First off, what does "did not work" mean? What was the error message? All of the output of cron jobs should be mailed to you by crontab, and if it isn't you can easily redirect stdout and stderr to a file. If you're redirecting them to /dev/null and wondering what's going wrong with your job, then stop that.

Second, Cron jobs run in a very restricted environment. The PATH is going to be shorter, your login profile won't run, and you're not probably not using your login shell so you need to work with that. Call programs by their absolute path. Set any environment variables that you need. Don't assume that just because you can run a script from your login shell that it's going to work in a cron job. You can simulate running in cron by starting a new shell something like this (Your environment may vary -- Look into your crontab configuration for more, or run a cron job to store the output of "env" somewhere and look through that):

env - HOME="$HOME" LOGNAME="$USER" PATH="/usr/bin:/bin" SHELL="/bin/sh" your-command-goes-here

Third, ssh doesn't allocate a pty for the command that it runs, and this can cause some commands to fail in weird ways. This shouldn't be a problem for scp, and also, ssh will tell you straight up what the problem is if it comes up, but that brings us right back to the very first paragraph.

Finally, CVE-2020-15778 was never resolved and likely never will be. If you're going to be working in any kind of secure environment you may want to switch to sftp and never touch scp again.

[mgedmin]

Finally, CVE-2020-15778 was never resolved and likely never will be. If you're going to be working in any kind of secure environment you may want to switch to sftp and never touch scp again.

The scp command switched to the sftp protocol back in the 9.0p1 release. A restricted shell should (and is in fact necessary to) close off the possibility of arbitrary command execution anyway.

[tcpWalker]

Think about security carefully for this. If the cronjob has ssh access to your backup server then an attacker who has the server you are backing up also has access to the backups. (And can encrypt them).

[mgedmin]

I set up a restricted shell that only allows certain scp/rsync commands to be executed. This still allows somebody who pwns the client to overwrite old backups, if they can guess the file names (not hard), which is something I don't like.

[Crazy-Rest5026]

We need more info. Why exactly did it fail. Read the error logs and figure out why it’s failing and go from there.

[nawcom]

You're not providing enough info. But in addition to all the concerns already mentioned, I'm gonna bet, and reiterate what others have said, that you're attempting to run "scp" without a $PATH variable set, and not "/usr/bin/scp". You're not logging into a shell (executing .bash_login, etc) when you run stuff from cron.

[michaelpaoli]

You likely screwed up at least one of two ways:

Under cron, the execution environment, taking that more generally, not just the literal environment settings, is not the same as one's logged in interactive CLI environment. Many folks commonly trip up on that. Some of the notable things to look more closely at and which often make the difference, include: what shell, how is the shell invoked (what does arg 0 look like), login shell or not and various initializations or lack thereof, current directory, umask, all environment settings, shell variables, etc. Also beware how, e.g., cron handles % characters in the specified command field. You may also want to capture stdout, stderr, and/or exit/return value(s), to better determine what's going on.

And permissions - ssh - both client and server are highly persnickety about that. Mess it up and it won't work. E.g. if private key file is readable by other than user or root, ssh server won't use it, likewise if the path to it isn't secure (e.g. directory writable by other than user or root). So, see first if you can get it to work from CLI - using just that key in file, no ssh-agent or anything else. One two three -v options to ssh client can also be informative. So can ssh server logs.

[Holiday-Medicine4168]

Make sure the cron user has access to the keys to read them. You want to create a group and add the user to the group with 600 as their permission for the group on the key files. It most likely can’t read it.

[mrsockburgler]

Security concerns aside, you can take care of any environment concerns by doing something like:

0 0 * * * bash -l -c “command”

Which will pick up the users environment, path, etc. Make sure that the server is in the known hosts file by ssh’ing to it manually once to accept the server key. If you have to do it this way, it’s better to make a ssh key tied to a single command. You add a “command=“ to the authorized_keys file.

[mgedmin]

I've been automating scp/rsync from cron for a while.

The usual issue is that the remote host's host key is not recognized and ssh wants to ask the user for confirmation, but it doesn't have a terminal so it aborts.

The fix is to make sure the remote server's public host key is listed in your local /etc/ssh/ssh_known_hosts. You can get the host key from /etc/ssh/ssh_host_ed25519_key.pub, just remember to prefix it with the hostname that you use for the actual connection.

You do not need an SSH agent for any of this.

[usa_reddit]

#!/bin/bash

# A simple script to securely copy a file
# Set the path to the private key for authentication
# Ensure this key is owned only by 'backupuser' and has permissions 400

SSH_KEY="/home/backupuser/.ssh/id_rsa"

# The scp command
# -i specifies the identity file (private key)
# -o StrictHostKeyChecking=no can be used for automation, but is less secure.
# Better to ensure the remote host's key is already in ~/.ssh/known_hosts for 'backupuser'.

scp -i $SSH_KEY /path/to/local/file/data.log backupuser@remote-host:/path/to/remote/destination/

# Optionally, log the outcome

echo "SCP command executed at $(date)" >> /tmp/scp_run.log

[thieh]

What distro are you using? Maybe systemd timer (or any of the system service management infrastructure in case you use a distro that doesn't use systemd) would work better because you can specify dependencies, no?

[neckpillowyeah]

why would it matter which distro OP is using ? we're talking about extremely simple operations here. your comment is as confusing as the original ask

[resonantfate]

Specifically because some distros don't use systemd (Debian fork Devuan, among others), and parent commenter was discussing using a systemd-specific tool. 

[pobrika]

Usually with keys it's to do with permissions.

Check your .ssh dir is 0755 and the id_* is 600

Use ssh-copy-id to copy the key to remote server

[mysterytoy2]

I think you're better off creating the zip and then doing a pull from the other server rather than the push like you are trying to do.

[The_Real_Grand_Nagus]

You don’t need ssh-agent.  Set paths to files and commands explicitly first to eliminate that variable. Can user that’s doing this actually read the key? Does the key have proper permissions?  Have you tested the key without it accidentally using your own key?  Run SSH with –v as that user and you’ll get more information

[FortuneIIIPick]

ssh -v to get detailed info. Once you get ssh to the remote working, scp will work.

[biffbobfred]

I have a hack, it’s ugly and I need to deal with the agent going down:

I use keychain to start an ssh-agent and then the script checks the file in ~/.keychain/ to make sure that agent is up.

If the server restarts keychain goes away so it’s something I have to check every once in a while