Problem using ssh public keys with crontab on raspbarry pi

ivanjunckes

New Member
Executing in the crontab a rsync + ssh using public key (without passphrase) doesn't work. I already tested the same procedure on ubuntu and works. Without crontab, executing the script by hand works fine.

I replaced the actual ip by <ip> so it is not exposed. Please help me, I already lost a lot of time on this.

Does anybody know how to make this work?

Logs below:
OpenSSH_7.4p1 Raspbian-10+deb9u6, OpenSSL 1.0.2r 26 Feb 2019
debug1: Reading configuration data /home/pi/.ssh/config
debug1: /home/pi/.ssh/config line 1: Applying options for <ip>
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "<ip>" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to <ip> [<ip>] port 22.
debug1: Connection established.
debug1: identity file /home/pi/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/pi/.ssh/id_rsa-cert type -1
debug1: identity file /home/pi/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/pi/.ssh/id_rsa-cert type -1
debug1: identity file /home/pi/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/pi/.ssh/id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Raspbian-10+deb9u6
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.8
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.8 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to <ip>:22 as 'timelapse'
debug3: hostkeys_foreach: reading file "/home/pi/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/pi/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from <ip>
debug3: order_hostkeyalgs: prefer hostkeyalgs: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc
debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected],zlib
debug2: compression stoc: none,[email protected],zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
debug2: host key algorithms: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected]
debug2: compression stoc: none,[email protected]
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: [email protected]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:wp4H3m9eKSJNGAYZ1uLpNTdAm9oEA8JyRZU7Zo6Ttu4
debug3: hostkeys_foreach: reading file "/home/pi/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/pi/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from <ip>
debug1: Host '<ip>' is known and matches the ECDSA host key.
debug1: Found key in /home/pi/.ssh/known_hosts:1
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug2: key: /home/pi/.ssh/id_rsa (0x6a88d8), explicit
debug2: key: /home/pi/.ssh/id_rsa (0x6a9ae0), explicit
debug2: key: /home/pi/.ssh/id_rsa (0x6a9cf0)
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,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 RSA public key: /home/pi/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: /home/pi/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: /home/pi/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
debug1: read_passphrase: can't open /dev/tty: No such device or address
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
debug1: read_passphrase: can't open /dev/tty: No such device or address
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
debug1: read_passphrase: can't open /dev/tty: No such device or address
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 1
Received disconnect from <ip> port 22:2: Too many authentication failures
Authentication failed.
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(235) [sender=3.1.2]
 
Last edited by a moderator:


wizardfromoz

Super Moderator
Staff member
Gold Supporter
G'day @ivanjunckes and welcome to linux.org :)

The subject matter is beyond my paygrade but I am thinking that our Networking or Pi forums would likely draw you more attention and answers.

Networking is here
https://www.linux.org/forums/linux-networking.144/
https://www.linux.org/forums/linux-networking.144/

and Pi is covered here

https://www.linux.org/forums/single-board-computers.12/

Let me know and I can move you.

Also a Google search under

linux crontab rsync ssh public key raspberry pi

... reveals a number of leads, have you tried any of those?

Cheers

Chris Turner
wizardfromoz
 

wizardfromoz

Super Moderator
Staff member
Gold Supporter
Consider it done.

I am putting the log output into a Spoiler, which is better for long outputs.

Spoiler function can be found in Reply Pane right of Smilies/Emoji. Just click the end result to open and click again to close.

Wizard
 

TechnoJunky

Well-Known Member
Because you're doing this using a script and it works, we can definately eliminate issues with the command itself and the SSH key(s). So the issue must be with the rights of the account executing it in Cron. I'm not real familiar with Cron, so you may still need to do some research, unless someone else can add anything here. I just went to https://www.adminschoice.com/crontab-quick-reference and found a short bit on it that may help. In not, then I suggest making sure that whatever account is executing the script in Cron has rights to the directory and the script itself.
3. Crontab Restrictions

You can execute crontab if your name appears in the file /usr/lib/cron/cron.allow. If that file does not exist, you can use
crontab if your name does not appear in the file /usr/lib/cron/cron.deny.
If only cron.deny exists and is empty, all users can use crontab. If neither file exists, only the root user can use crontab. The allow/deny files consist of one user name per line.
 

TechnoJunky

Well-Known Member
One other thing that could cause issues is that if the SSH key is in your home directory but Cron is running as Root (or whatever account other than your own), the transaction may not work because root isn't using your SSH Key because it's not in Root's home directory.
 

Members online


Top