Timeline for Permission denied (publickey,password) on SSH connection when run as a service
Current License: CC BY-SA 4.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| S Aug 12, 2022 at 19:00 | history | bounty ended | CommunityBot | ||
| S Aug 12, 2022 at 19:00 | history | notice removed | CommunityBot | ||
| Aug 8, 2022 at 20:47 | answer | added | t0w0i7ne | timeline score: 0 | |
| S Aug 4, 2022 at 17:15 | history | bounty started | jpsalm | ||
| S Aug 4, 2022 at 17:15 | history | notice added | jpsalm | Draw attention | |
| Jul 27, 2022 at 7:32 | comment | added | Andrea | yes, the key is password protected and managed by the ssh-agent. Indeed using an unprotected key it works fine. | |
| Jul 27, 2022 at 6:21 | comment | added | Stewart | I have two more ideas. First: is your ssh-key password-protected? It may be that it is password-protected and therefore needs authentication from an agent to be unlocked. In your desktop environment a keyring is unlocked when you log-in so it's not a problem until you get into the sterile environment of systemd. Second, consider moving this service from the system bus to the --user bus. This ssh session may depend on gpg-agent-ssh.socket and gpg-agent.service which is only available on the --user bus. It will also cause your service to inherit much of your user's environment. | |
| Jul 26, 2022 at 18:10 | history | edited | Andrea | CC BY-SA 4.0 | added 91 characters in body |
| Jul 26, 2022 at 17:42 | comment | added | Andrea | @Stewart Thanks to your suggestions I did new attempts and edited my question | |
| Jul 26, 2022 at 17:41 | history | edited | Andrea | CC BY-SA 4.0 | added 979 characters in body |
| Jul 26, 2022 at 9:11 | comment | added | Stewart | If you have something in /etc/profile, ~/.bash_profile, ~/.bash_login, or ~/.profile, then add /bin/bash --login ... to read those. If you have something in /etc/bash.bashrc or ~/.bashrc, then consider moving that to one of the previous files. | |
| Jul 26, 2022 at 9:10 | comment | added | Stewart | Just a thought, could there be something ssh related in one of your bash configurations? To test that hypothesis, try running this from your shell /bin/bash --noprofile --norc /home/localuser/backup-script.sh. If you reproduce the problem from your interactive terminal, then we know where to start looking. | |
| Jul 24, 2022 at 20:44 | comment | added | Andrea | I would say it is verified, since in the localuser's home a file is created by the same script, and the owner is correctly set to localuser | |
| Jul 24, 2022 at 20:25 | comment | added | Sotto Voce | Have you verified that systemd is running your script as localuser and not as another user who can't read the private key file? Perhaps add a command to check, such as touch /tmp/backup.service.test.$$ in the script before the rsync command... | |
| Jul 24, 2022 at 20:24 | comment | added | Sotto Voce | Do you always use the username remoteuser and the private key ~/.ssh/id_ed25519 with that host? If so, you can simplify your rsync command by creating a ~/.ssh/config file with a clause associating the username and private key file with that host. | |
| S Jul 24, 2022 at 19:47 | review | First questions | |||
| Aug 7, 2022 at 19:50 | |||||
| S Jul 24, 2022 at 19:47 | history | asked | Andrea | CC BY-SA 4.0 |