0
1
I have to get files from another server, using sftp.
I created a script that will cd to my directory and execute the sftp command. Since i'm not allowed to add rsa keys into the external server, i'm using sshpass to handle this situation. If i run the script in my session, it works fine (but print what every sftp command on screen). If i try to execute va crontab , the sftp command is not executed, but everything else in the script are executed.
set -o nounset # Treat unset variables as an error
umask 000
cd /path/to/dir
export SSHPASS='securepass'
sshpass -e sftp -oBatchMode=no -b - -P9999 user@external.ip.address: << !
cd REMOTEDIR
get *
rm *
bye
!
# processing the files part
Fernando Crozetta
Posted 2017-08-17T18:08:05.933
Reputation: 3
Add full path to
REMOTEDIRor use path relative to user's$HOME. – Cyrus – 2017-08-17T20:49:20.080Why do you believe that that would cause different behavior between interactive and cron use? – Scott – 2017-08-17T21:00:47.800
1What's the output? + Does the cron run under the same account as you are using in the shell? – Martin Prikryl – 2017-08-18T05:29:16.543
@Cyrus the full path of REMOTEDIR is ./REMOTEDIR , i don't think this is the problem, since it works when i execute manually. – Fernando Crozetta – 2017-08-18T16:44:24.147
@Scott the difference is that the files are not downloaded, nor removed from remote server – Fernando Crozetta – 2017-08-18T16:44:57.000
@MartinPrikryl nope, the root's cron is used to run the script .. i'll try to execute manually with root to see what happens – Fernando Crozetta – 2017-08-18T16:46:05.010
@FernandoCrozetta: I was asking Cyrus why he thought some values of
REMOTEDIRwould work interactively and not under cron. But you said, “If I run the script in my session, it works fine …. If I try to execute via crontab” it fails. If you were running it interactively under one account (e.g., your personal account) and running it via cron under a different account (e.g., root), you should have said so in the question. (Better yet, if it works under your personal account, that proves that it doesn't need root, and you should have tried running it in cron under your personal account already.) – Scott – 2017-08-18T17:04:13.510@Scott i didn't realize that the user could be the problem... that's why i didn't wrote that on my question. i'm new asking questions here, my apologies. – Fernando Crozetta – 2017-08-18T18:34:19.493
@MartinPrikryl The user was the problem. since i HAVE to run the script as root (not my choice...) i realized that you are correct. as root it fails to validate the host key. if you can post that as an answer, i can upvote, i can choose your answer, i guess – Fernando Crozetta – 2017-08-18T18:37:37.443
@FernandoCrozetta: Well, it's not so much the user id per se, but the fact that different user accounts have different environments defined. (Except, of course, lots of things that work for root don’t work for any other user — but, apparently, your situation is the opposite of that.) – Scott – 2017-08-18T18:41:45.833