I am trying to set up a cronjob to rsync between a raspberry pi on raspbian and a vero 4k on the same network. I have set up ssh keys so passwords are not required, but it keeps asking for the ssh key password whenever I ssh/scp etc.
If I run:
eval $(ssh-agent)
ssh-add
Then it seems to work fine, but I need to run these two commands for every new terminal window (and the cronjob still doesn’t work). I get the exact same problem in both directions (i.e. from the pi to the vero and vice versa).
Everything works fine from my laptop - I can ssh to both machines without inputting a password using the same ssh keys, so I’m pretty sure the ssh keys + permissions are fine. Just in case, I have checked and set the permissions to be exactly the same as on my laptop.
I missed this bit: “ssh key password”. If you mean the “passphrase”, I’d suggest you rerun ssh-keygen, this time without specifying a passphrase, and copy the new key over to the other device(s). If not, please show us what happens when you run ssh -v <user@IP address>
Yes, I did mean passphrase. I can try setting up a passwordless ssh key, but with my laptop it only asked for the password the first time I used it, and never again (persisting through reboots), so I don’t understand what’s different here.
This is the output (up to the passphrase request) of ssh -v:
OpenSSH_7.4p1 Debian-10+deb9u7, OpenSSL 1.0.2u 20 Dec 2019
debug1: Reading configuration data /home/osmc/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.1.108 [192.168.1.108] port 22.
debug1: Connection established.
debug1: identity file /home/osmc/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/osmc/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/osmc/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/osmc/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/osmc/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/osmc/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/osmc/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/osmc/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u7
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.9p1 Raspbian-10+deb10u2
debug1: match: OpenSSH_7.9p1 Raspbian-10+deb10u2 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.1.108:22 as ‘pi’
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:WT64IR9yDENJgL7n3Z1z5GgQojKNUq5IC8wpstTpsj0
debug1: Host ‘192.168.1.108’ is known and matches the ECDSA host key.
debug1: Found key in /home/osmc/.ssh/known_hosts:1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/osmc/.ssh/id_rsa
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279
Enter passphrase for key ‘/home/osmc/.ssh/id_rsa’:
Ah, I didn’t realize that. But why does the ssh key agent persist on my laptop (through reboots), but not the vero even when just opening a new session?
Anyway, I have just created a new ssh key without a password and it seems to be working fine (at least with ssh, will have to check with the cronjob but I don’t see why not).