I create a service that do a git add , commit and push to github, the script that service triggers is working and the service if i manually start also works. The problem is when the timer start the service , and i get some permission problem with github.
My .service and .timer file are in /etc/systemd/user
my ssh keys (that may are giving me the permission error) are in a /home/.ssh
I think somehow if timer triggers the service, it dont read the ssh keys, just my guess, since if i manually start the service it works
the error:
dez 23 17:18:39 fedora systemd[2405]: Started git-auto.service - Rodar git-auto-timer.
dez 23 17:18:40 fedora git-auto.sh[2506]: git@github.com: Permission denied (publickey).
dez 23 17:18:40 fedora git-auto.sh[2505]: fatal: Could not read from remote repository.
dez 23 17:18:40 fedora git-auto.sh[2505]: Please make sure you have the correct access >
dez 23 17:18:40 fedora git-auto.sh[2505]: and the repository exists.
I though you had this working from the thread in email?
If not post the .timer and .service unit file contents here.
Use the </> button in the menu to format the text. It will instead back ticks like this for you, or just type them.
```
Your code here
```
From the error I assume that your key cannot be used in the service.
And is it really in /home/.ssh not /home/<user>/.ssh?
We will need acturate information to help you.
If the key is encrypted with a passphrase then the service will not be alble to use it.
Typically when you login to Fedora desktop your SSH keys are loaded into the ssh agent and you use then from there. The passphrase is remebered in the desktop keyring.
But the service will have no access to that keyring or ssh agent.
As @vgaetera says make a github unique key or setup a HTTPS API token to access github.
If you use the github SSH key then you need to configure git to call ssh with the -i option to have it use the right key. See man ssh for the details of -i.
If you use the HTTPS token then you will have to make the token available to the script.
Consider using systemd-creds to keep this secret secret. There is details on systemd and credentials support here: Credentials
wait, another SSH key ? is not possible to use the one i already have ? and if no where i would put them ? the strange thing is that i f i start service manually it works,why if the timer triggers it didnt get the key ?
you mean, in the git script ?
because i already configured a SSH keys on github , is in /home/<user>/.ssh. BUt somehow when i trigger manually the service it get the keys there but if timer triggers it dont
sorry bro, im noob, where would be the default directory ?
which one (.service, .timer or .sh) should access the new key ?
How do i make the connection between the file and the keys ?
about that , i know how generate them, i did that to configure git, and create the keys putting them on a .ssh folder in home. But appears that the service/timer dont acces them , hence my question after generating the new ones , where do i put to make the service/timer “see” them ?
That is becuase the setup of the service does not include all the features that have as a logged in user.
As a logged in user you have the ssh-agent automatically loading your ssh key so that you do not have to type a passphrase to use them. None of that works in the service environment.
You can see what is in the ssh-agent by using the ssh-add -L command.
That will not work in your service.
What this means is that is you test your script as a GUI logged in user it will work.
But that is not the way that the service is setup.
I think a close, but not perfect, setup to debug your script is to do ssh -a localhost as that will stop access to the keys in ssh-agent and the ssh-add -L will not work.
Now try running your script and it should fail the same way it does in the service.
Beware that the SSH agents does not exist until you have sucessfully logged in to your GUI session. So if the service runs are you are not logged in it will fail.
Atleast with KDE I see that the env var you need to use has a fixed path.
I see this is setup:
However given that you must be logged in for this to work there is little point running the service as root user as a system service. You are better off running this as a user systemd timer and service that is only going to run if you after you have logged in.