[Dirvish] Setting up new backup

[Przemek Klosowski]

I didn't follow the entire thread, but seeing that it sees your keys but
refuses to use them, sometimes that is caused by sshd being picky about the
permissions on the key file.
THey have to be rw-------, which is weird because Linux uses UID=GID, so
group permissions aren't relevant. Please make sure that private keys and
authorized_keys files have the 600 permissions.
This is not mentioned in the ssh -v output, so if you want to confirm it
you have to look at sshd log files on the remote connection.

On Thu, Oct 24, 2019 at 8:56 AM Rich Shepard <rshepard at appl-ecosys.com>
wrote:

> On Wed, 23 Oct 2019, wes wrote:
>
> > Ok, try ssh -vi /root/.ssh/id_ed25519 localhost
>
> Wes,
>
> This is very interesting:
>
> # ssh -vi id_ed25519 localhost
> OpenSSH_7.4p1, OpenSSL 1.0.2t  10 Sep 2019
> debug1: Reading configuration data /root/.ssh/config
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: Connecting to localhost [127.0.0.1] port <redacted>.
> debug1: Connection established.
> debug1: permanently_set_uid: 0/0
> debug1: identity file id_ed25519 type 4
> debug1: key_load_public: No such file or directory
> debug1: identity file id_ed25519-cert type -1
> debug1: identity file /root/.ssh/id_ed25519 type 4
> debug1: key_load_public: No such file or directory
> debug1: identity file /root/.ssh/id_ed25519-cert type -1
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_7.4
> debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
> debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000
> debug1: Authenticating to localhost:14982 as 'root'
> debug1: SSH2_MSG_KEXINIT sent
> debug1: SSH2_MSG_KEXINIT received
> debug1: kex: algorithm: curve25519-sha256 at libssh.org
> debug1: kex: host key algorithm: ssh-ed25519
> debug1: kex: server->client cipher: chacha20-poly1305 at openssh.com MAC:
> <implicit> compression: none
> debug1: kex: client->server cipher: chacha20-poly1305 at openssh.com MAC:
> <implicit> compression: none
> debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
> debug1: Server host key: ssh-ed25519
> SHA256:/RInRdtcIMbpPu3LZmpg5wfAWi9ozQwgKLPnTQEDcxg
> debug1: Host '[localhost]:<redacted>' is known and matches the ED25519
> host key.
> debug1: Found key in /root/.ssh/known_hosts:3
> 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,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
> debug1: SSH2_MSG_SERVICE_ACCEPT received
> debug1: Authentications that can continue: publickey
> debug1: Next authentication method: publickey
> debug1: Offering ED25519 public key: id_ed25519
> debug1: Authentications that can continue: publickey
> debug1: Offering ED25519 public key: /root/.ssh/id_ed25519
> debug1: Authentications that can continue: publickey
> debug1: No more authentication methods to try.
> Permission denied (publickey).
>
> I wonder why it cannot find id_ed5519.pub when it tries to key_load_public,
> but then seems to find and accept it.
>
> Rich
> _______________________________________________
> Dirvish mailing list
> Dirvish at dirvish.org
> http://www.dirvish.org/mailman/listinfo/dirvish
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dirvish.org/pipermail/dirvish/attachments/20191024/b7d7329c/attachment.htm>