I am trying to write a script to rsync a folder on my laptop to my NAS. The script runs fine when called from the commandline. I've tried setting up the script to run automatically with systemd. However, there is a problem with the ssh login. While it works fine when the script is run from the commandline, I get a permission denied error.

Here is what I've tried so far to narrow down the problem:

The script /home/tikey/scripts/nas_sync_photos_to_nas.sh:

#!/bin/bash
set -x
ssh tikey@192.168.17.200 -v -i /home/tikey/.ssh/id_rsa ls -la rsync_laptop

To run the script with systemd, I've put the file sync-photos-to-nas.service in ~/.config/systemd/user/:

[Unit]
Description=sync Bilder to nas
[Service]
ExecStart=/home/tikey/scripts/nas_sync_photos_to_nas.sh

Running the script from the commandline works fine. Unfortunately, running the script with systemd does not work. I've run the systemd service with systemctl --user start sync-photos-to-nas.service. Then, using journalctl --user-unit sync-photos-to-nas, I get:

...
debug1: Host '192.168.17.200' is known and matches the RSA host key.
debug1: Found key in /home/tikey/.ssh/known_hosts:2
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/tikey/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 535
debug1: read_passphrase: can't open /dev/tty: No such device or address
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
debug1: read_passphrase: can't open /dev/tty: No such device or address
debug1: Authentications that can continue: publickey,password,keyboard-interactive
Permission denied, please try again.
debug1: read_passphrase: can't open /dev/tty: No such device or address
debug1: Authentications that can continue: publickey,password,keyboard-interactive
Permission denied, please try again.
debug1: read_passphrase: can't open /dev/tty: No such device or address
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: No more authentication methods to try.
sync-photos-to-nas.service: Main process exited, code=exited, status=255/n/a
sync-photos-to-nas.service: Unit entered failed state.
sync-photos-to-nas.service: Failed with result 'exit-code'.

Does anybody know what the problem might be?

migrated from serverfault.com Oct 25 '16 at 21:02

This question came from our site for system and network administrators.

up vote 4 down vote accepted

debug1: read_passphrase: can't open /dev/tty: No such device or address

The log says that your private key is encrypted and the client can't use it before you will enter a passphrase. Either use unencrypted key or use again some dirty workaround using sshpass.

  • Forgot about this. The key is automatically unlocked when I log in but apparently not for systemd. – Thomas Oct 25 '16 at 18:18
  • Because it's a different user who has the key/keyring, so it's not unlocked as systemd has no interactive session running – Alfabravo Oct 25 '16 at 21:03

According to man ssh, the order of your arguments is wrong in your SSH call. You have this:

ssh tikey@192.168.17.200 -v -i /home/tikey/.ssh/id_rsa ls -la rsync_laptop

But in the "Synopsis" of man ssh, it shows that that all the options must come before "user@host", so try this:

 ssh -v -i /home/tikey/.ssh/id_rsa tikey@192.168.17.200 ls -la rsync_laptop

The other details of your systemd configuration look reasonable.

  • In practice this doesn't actually matter, as long as the command to be run comes at the end. Try this: ssh myhost -v, which will turn on the -v argument even after the host declaration. – Jamieson Becker Nov 14 '16 at 1:25
  • @JamiesonBecker it might not matter now, but if you aren't following the documented way to use SSH, then expect no guarantee of future support of undocumented behaviors. – Mark Stosberg Nov 14 '16 at 18:15
  • .. but it's not an answer. Or, at least not an answer to the question OP was asking. :) – Jamieson Becker Nov 25 '16 at 4:06

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.