1

Since this has already come up, just want to get the related posts out of the way:

Permission denied (publickey); not my issue:

The closest and what got me where I am, but not working for me:

There's no indication on the last one of what, exactly, led the top answer to be marked solved but I'm having no issues with the suggested troubleshooting script or manual password-less/ssh-agent-based pushes to github.

I have a python file that writes to a log, which I'd like pushed to github every minute automatically from my raspberry pi. Here's the script:

~/dir/script
export HOME=/home/uname
cd /home/uname/dir/
echo $HOME
pwd
whoami
python2 ./python-script.py
git commit -am "update"
git push

When I run it manually, I get the following output:

$ ./script 
/home/uname
/home/uname/dir
uname
done ### print from script
[master 0db9599] update
 1 file changed, 1 insertion(+), 1 deletion(-)
Counting objects: 3, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 306 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
To uname@github.com:uname/repo.git
   def0bed..0db9599  master -> master

So, all looks great!

Here's the crontab line (edited via crontab -e as my regular user):

*/1 * * * * /home/uname/dir/script

Here's my journalctl log after cron runs:

CROND[13791]: pam_unix(crond:session): session closed for user uname
crond[13862]: pam_unix(crond:session): session opened for user uname by (uid=0)
CROND[13863]: (uname) CMD (/home/uname/dir/script)
CROND[13862]: (uname) CMDOUT (/home/uname)
CROND[13862]: (uname) CMDOUT (/home/uname/dir
CROND[13862]: (uname) CMDOUT (uname)
CROND[13862]: (uname) CMDOUT (done)
CROND[13862]: (uname) CMDOUT ([master 4fd590d] update)
CROND[13862]: (uname) CMDOUT ( 1 file changed, 1 insertion(+), 1 deletion(-))
CROND[13862]: [50B blob data]
CROND[13862]: (uname) CMDOUT (fatal: Could not read from remote repository.)
CROND[13862]: (uname) CMDOUT ()
CROND[13862]: (uname) CMDOUT (Please make sure you have the correct access rights)
CROND[13862]: (uname) CMDOUT (and the repository exists.)
CROND[13862]: pam_unix(crond:session): session closed for user uname

From googling around a bit to make sure the user was properly set for github, I tried the explicit command shown in the accepted answer here:

git push ssh://uname@github.com/uname/repo.git

I'm no git expert, so I thought this was just an example on github but it appears to work fine, too:

git push ssh://git@github.com/uname/repo.git

I also tried the ~/.ssh/config suggestion from the same answer above. Namely:

$ cat ~/.ssh/config
Host github-project1
User git
HostName github.com
IdentityFile ~/.ssh/id_rsa.pub

Then:

git remote add github-project1 github-project1:uname/repo.git

I get the same results with all variants I've tried; manual pushes and the script execute fine but cron fails.

What further can I check?

Community
  • 1
  • 1
Hendy
  • 10,182
  • 15
  • 65
  • 71
  • 1
    `ssh -vvv git@github.com verify` should tell you more. – Jakuje Mar 15 '16 at 11:31
  • @Jakuje I can post a full log if you'd like, but 2/3 down I get `debug1: Authentication succeeded (publickey)` and it exits with `debug1: Exit status 1`. Should I re-do that from the script/cron and save the log to compare? – Hendy Mar 15 '16 at 18:30
  • Also when you run it from cron? – Jakuje Mar 15 '16 at 19:25
  • @Jakuje they're definitely different, and in the process of googling what I think was the problem, I've solved the issue. The cron-executed script log features `read_passphrase: can't open /dev/tty: No such device or address` and then fails. [This question](http://stackoverflow.com/questions/5499680/why-does-this-bash-script-work-at-console-but-fails-when-run-as-a-cron-job) says it's because `ssh-agent` isn't accessible to `cron` since it runs outside of a sesson. Thanks for the tip; should have thought of doing that... – Hendy Mar 15 '16 at 23:13

1 Answers1

1

git push via cron + ssh-agent (no password)

Cron usually does not have access to your ssh-agent, because there is environment variable $SSH_AUTH_SOCK in your shell, but it is probably not in the one that is used by cron.

Jakuje
  • 24,773
  • 12
  • 69
  • 75
  • And I don't suppose I could set it in my script with `SSH_AUTH_SOCK=/tmp/blahblah`, right? – Hendy Mar 15 '16 at 23:35
  • You can, but then you will depend on. Some other running session providing this socket and the pass phrase earlier. – Jakuje Mar 16 '16 at 07:02