View Full Version : Launchd, rsync ssh problem
I have a script that archives a HD onto a RAID over the network with rsync via SSH. It works perfectly well when I start it manually, but it fails when launchd attempts to run it. Here is the launchd XML:
[...]
<key>ProgramArguments</key>
<array>
<string>/Users/me/bin/synchronizeComputers.sh</string>
<string>user</string>
<string>machine</string>
</array>
<key>UserName</key>
<string>me</string>
<key>WorkingDirectory</key>
<string>$HOME</string>
[...]
and synchronizeComputers.sh is this:
USER=$1
MACHINE=$2
sh /Users/me/.keychain/fileserver.local-sh
rsync -aEz -e ssh --progress $USER@$MACHINE.edu:/Users/Shared/Images /Volumes/Tera/Machines-Archives/$MACHINE/
exit 0
I keep the .plist in /Library/LaunchDaemons/com.mylaunchd.plist
If I do:
% sudo launchctl load /Library/LaunchDaemons/com.mylaunchd.plist
% sudo launchctl start syncmic
The stderr gets this:
Permission denied, please try again.
Permission denied, please try again.
Permission denied (gssapi-with-mic,publickey,gssapi,password,keyboard-interactive).
I have set UserName to "me", so what is going on?
If I do (without sudo)
% launchctl load /Library/LaunchDaemons/com.mylaunchd.plist
% launchctl start syncmic
It works fine BUT since my launchctl quits when I leave, it won't run unattended.
It's only the system's launchd that fails.
What is going on?
Did you manage to find a solution to this problem in the end? I'm also trying to get launchd to perform my rsync. My plist is under my user directory and I get the same error of permission denied.
However, if I running the script directly (same user), it works fine.
I tried using "ssh -vvv" and compared the difference between the 2. There are some differences in the bits set. I'm not sure how to proceed from here. Appreciate any advice.
(Via launchd)
...
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 127/256
debug2: bits set: 502/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /Users/xxx/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug3: check_host_in_hostfile: filename /Users/xxx/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 4
debug1: Host 'domain.com' is known and matches the RSA host key.
debug1: Found key in /Users/xxx/.ssh/known_hosts:1
debug2: bits set: 517/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /Users/xxx/.ssh/id_rsa (0x103400)
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /Users/xxx/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug2: input_userauth_pk_ok: fp xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
debug3: sign_and_send_pubkey
debug1: PEM_read_PrivateKey failed
...
(Via shell)
...
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 119/256
debug2: bits set: 539/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /Users/xxx/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug3: check_host_in_hostfile: filename /Users/xxx/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 4
debug1: Host 'domain.com' is known and matches the RSA host key.
debug1: Found key in /Users/xxx/.ssh/known_hosts:1
debug2: bits set: 493/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /Users/xxx/.ssh/id_rsa (0x101a80)
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /Users/xxx/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug2: input_userauth_pk_ok: fp xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
debug3: sign_and_send_pubkey
debug1: Authentication succeeded (publickey).
...
Never managed to get to the bottom of it!
Looking at the script in the post above, ssh is wrapped in rsync as I have. I wonder if rsync was piped or tunnelled through ssh, moving it into the forefront, rather than being launched/wrapped by rsync (or how ever it does it) would that make a difference? I'll try this as soon as I get a chance. If anyone else gets this cracked before then, please let us know.
Thanks.
eval `/usr/bin/ssh-agent -s`
/usr/bin/ssh-add
This will start an ssh-agent and add your private key to the agent so that it can handle the authentication challenge correctly (avoid the "debug1: PEM_read_PrivateKey failed"). If your private/public keys are not stored in ~/.ssh/ you need to point them out in the ssh-add call. See the respective man pages for more info.
Hopes this helps you, it works for me now!
setenv SSH_AUTH_SOCK `find /tmp/launch-*/Listeners -user [username] -type s | head -1`
replace [username] with your username
No comments:
Post a Comment