search

gilbertchen / duplicacy

A new generation cloud backup tool
https://duplicacy.com
Other
5.17k stars 336 forks source link

SFTP encrypted private key #158

Open cristihcd opened 7 years ago

cristihcd commented 7 years ago

On Windows, trying to use a private key encrypted with a password, Duplicacy does not ask for the password:

Storage set to sftp://user@ip/duplicacy
Attempting public key authentication
Reading the environment variable DUPLICACY_SSH_KEY_FILE
Reading ssh_key_file from preferences
Failed to parse the private key file /Users/.../user: ssh: cannot decode encrypted private keys
Failed to load the SFTP storage at sftp://user@ip/duplicacy: ssh: handshake failed: ssh: cannot decode encrypted private keys

Is there a way to set the private key password?

Thanks.

gilbertchen commented 7 years ago

Unfortunately this is not supported by go yet: https://github.com/golang/go/issues/18692

thenickdude commented 7 years ago

The current workaround seems to be to use an SSH agent instead (which should define SSH_AUTH_SOCK in the environment)

rawtaz commented 7 years ago

Chiming in on this issue as it's exactly what I'm having problems with. Duplicacy doesn't make use of the ssh-agent I have loaded with the key for the server. Instead it keeps asking me for the path to the private key, which it does when I don't use the ssh-agent as well.

$ ~/go/bin/duplicacy init -e home sftp://HOST:1234/backup/duplicacy
Enter the path of the private key file:/Users/USER/.ssh/id_rsa-foo
Failed to parse the private key file /Users/USER/.ssh/id_rsa-foo: ssh: cannot decode encrypted private keys
Failed to load the SFTP storage at sftp://HOST:1234/backup/duplicacy: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain

ssh-add -l shows the key being loaded just fine, and when I run restic to try it it uses the ssh-agent loaded key like it should. So for all I can tell, the agent and key works as expected.

Any idea why it's still asking me for the path to the key, instead of using the ssh-agent, which is what the documentation says it does?

thenickdude commented 7 years ago

Add -background to the command line to suppress the prompt.

rawtaz commented 7 years ago

No dice:

$ ~/go/bin/duplicacy -background init -e home sftp://HOST:1234/backup/duplicacy
2017-10-06 22:26:34.896 duplicacy[33598:23665936] Keychain Get: Error Code: -25300
ssh_key_file is not found in Keychain/Keyring
No private key file is provided
Failed to load the SFTP storage at sftp://HOST:1234/backup/duplicacy: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain

I have disabled SSH's use of the keychain in my macOS 10.12 by adding UseKeychain no in the ssh config. However, the agent is still loaded, so I would expect Duplicacy to use that. Seems to me that the problem is that it doesn't use the agent as it should.

rawtaz commented 7 years ago

@gilbertchen FWIW, restic handles this fine - if there's an SSH agent loaded it uses that, and if there isn't it asks for the password of the SSH key. I'm not trying to promote restic here, but I know this particular thing works there, so perhaps it might be worth taking a look at how it's done there. The PR for it is here: https://github.com/restic/restic/pull/1270

gilbertchen commented 7 years ago

Do you have the environment variable SSH_AUTH_SOCK set up and pointed to your ssh agent?

rawtaz commented 7 years ago

@gilbertchen Yes, I do. And I tested it with restic, which doesn't ask for the private key password but instead goes directly to ask me for the repository password. Had it not used the ssh-agent for the key, it would either have asked me for the SSH key passphrase or not worked at all. So the ssh-agent does work, AFAICT.

EDIT: I have the agent running in two separate terminal sessions. In the first one I have SSH_AUTH_SOCK=/var/folders/rx/s_h0zqcd2sj7r70299njxk180000gp/T//ssh-5XsDrBnKfdVl/agent.16609 and in the second one I have SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.fvMJMhHJaA/Listeners. They do look a bit different, but restic utilizes the agent in both of these terminals successfully, so it seems to me that they're working in both places. ssh-add -l lists the key as added in both of them as well. So I can't really find anything wrong there, but correct me if you spot anything I'm missing.

gilbertchen commented 7 years ago

Can you run duplicacy -d -log init ...? It will print a message Attempting public key authentication via agent when it is connecting to the ssh agent.

rawtaz commented 7 years ago

Sure, here's the output of that:

$ ~/go/bin/duplicacy -d -log init -e home sftp://HOST:1234/backup/duplicacy
2017-10-07 11:25:58.171 DEBUG PASSWORD_ENV_VAR Reading the environment variable DUPLICACY_SSH_KEY_FILE
2017-10-07 11:25:58.407 DEBUG SSH_PUBLICKEY Attempting public key authentication
2017-10-07 11:25:58.407 DEBUG SSH_AGENT Attempting public key authentication via agent
2017-10-07 11:25:58.407 DEBUG PASSWORD_ENV_VAR Reading the environment variable DUPLICACY_SSH_KEY_FILE
Enter the path of the private key file:/Users/USER/.ssh/id_rsa-foo
2017-10-07 11:26:20.265 INFO SSH_PUBLICKEY Failed to parse the private key file /Users/USER/.ssh/id_rsa-foo: ssh: cannot decode encrypted private keys
2017-10-07 11:26:20.270 ERROR STORAGE_CREATE Failed to load the SFTP storage at sftp://HOST:1234/backup/duplicacy: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain

$ echo $DUPLICACY_SSH_KEY_FILE

$
gilbertchen commented 7 years ago 
2017-10-07 11:25:58.407 DEBUG SSH_AGENT Attempting public key authentication via agent

This log message means the following lines were called: https://github.com/gilbertchen/duplicacy/blob/b2ad6da36477328344caac09afb77edb5688bae7/src/duplicacy_storage.go#L237-L242

Since it didn't report an error, I guess for some reason signers was nil or empty. Does ssh-add -l show any identity for you? If not, you may need to add some with ssh-add -K key_file.

It looks like restic runs an external ssh process to obtain the sftp channel so it works differently.

rawtaz commented 7 years ago

Yes, ssh-add -l lists the loaded key as expected (and other software running in the very same shell instance uses the agent successfully):

$ ssh-add -l
2048 SHA256:<randomChars>/<randomChars> /Users/USER/.ssh/id_rsa-foo (RSA)

The key was added using ssh-add ~/.ssh/id_rsa-foo and as I mentioned previously I have UseKeychain = no in the SSH config, in case that's relevant.

gilbertchen commented 7 years ago

Can you create a new ssh agent by running ssh-agent -d and then set SSH_AUTH_SOCK accordingly to use this new ssh agent?

Also running the remote sshd with the -D -d -e options may also reveal what goes wrong.

rawtaz commented 7 years ago

What I did was:

I then ran ~/go/bin/duplicacy -d -log init -e home sftp://HOST:1234/backup/duplicacy again, and the result was the same as before - the same output up to the point where it asks me for the path of the private key file. If I supply the path, it tells me it cannot decrypt the file.

Let's take a step back and look at the code in duplicacy_storage.go. Considering that I'm not seeing the message in line 241 ("Can't log in using public key authentication via agent"), it seems like the agent support has been loaded fine. But then I see the message in line 246 ("Enter the path of the private key file"), and that seems odd. If the agent loaded fine, it should be managing the key, so why would Duplicacy then ask me for the path to the private key file? It seems wrong that it does (that and perhaps the code following that as well).

gilbertchen commented 7 years ago

What is the output from ssh-agent -d? Did you see debug1: type 13?

https://github.com/gilbertchen/duplicacy/blob/b0a67cefb7b24ccc813ed22dc76896c94ac1c819/src/duplicacy_storage.go#L232-L246

Here on line 239 it tries to retrieve the signers from the agent and authentication doesn't happen yet. It may not get any signer or the signers may not work at all therefore it may need to create a new signer from the private key file. The logic seems a bit awkward, but this is mainly due to the poor api design of the go's ssh library in my opinion.

rawtaz commented 7 years ago

Here's the output from the ssh-agent, should have included this in my previous post of course:

$ ssh-agent -d
SSH_AUTH_SOCK=/var/folders/rx/s_h0zqcd2sj7r70299njxk180000gp/T//ssh-mgXn80CTuYI8/agent.35978; export SSH_AUTH_SOCK;
echo Agent pid 35978;
debug2: fd 3 setting O_NONBLOCK
debug3: fd 4 is O_NONBLOCK
debug1: type 11
debug1: XXX shrink: 3 < 4
debug3: fd 4 is O_NONBLOCK
debug1: type 11
debug1: XXX shrink: 3 < 4
debug3: fd 4 is O_NONBLOCK
debug1: type 11
debug1: XXX shrink: 3 < 4
debug3: fd 4 is O_NONBLOCK
debug1: type 17
debug1: XXX shrink: 3 < 4
debug3: fd 4 is O_NONBLOCK
debug1: type 11
debug1: XXX shrink: 3 < 4
debug3: fd 4 is O_NONBLOCK
debug1: type 11
debug1: XXX shrink: 3 < 4

Okay, but can't you ask for the private key path only if the signers from the agent doesn't work? I dunno, just seemed wrong that it ALWAYS asks for the private key path, since if the agent works this shouldn't be needed I guess.

gilbertchen commented 7 years ago

This is the output of ssh-agent -d from a successful log in:

echo Agent pid 73692;
debug2: fd 3 setting O_NONBLOCK
debug3: fd 4 is O_NONBLOCK
debug1: type 17
debug1: XXX shrink: 3 < 4
debug3: fd 4 is O_NONBLOCK
debug1: type 11
debug1: type 13
debug1: XXX shrink: 3 < 4

Compared with your output, you were missing type 13 which is SSH_AGENTC_SIGN_REQUEST. But it did have type 17 so I guess for some reason the private key wasn't accepted for the login. Could you please run sshd -p port -D -d -e on a different port and connect to this port to see if why the private key wasn't accepted?

rawtaz commented 7 years ago

Here is hopefully the mother of all debug outputs, including the ssh-agent, the client, and the server, both for when I do supply the path to the private key when asked, and when I don't.

It looks like there's a missing username in there when the client connects, but perhaps that's just normal when pubkey is supposed to be used.

To be clear, between each of these, I restarted the ssh-agent, the sshd and completely restarted the client shell as well. So it should all be pristine for each run.

PROVIDING PATH TO SSH KEY WHEN ASKED
====================================

SSH agent in shell 1 on client
------------------------------

$ ssh-agent -d
SSH_AUTH_SOCK=/var/folders/rx/s_h0zqcd2sj7r70299njxk180000gp/T//ssh-xTDhJNCV0W56/agent.37450; export SSH_AUTH_SOCK;
echo Agent pid 37450;
debug2: fd 3 setting O_NONBLOCK
debug3: fd 4 is O_NONBLOCK
debug1: type 17
debug1: XXX shrink: 3 < 4
debug3: fd 4 is O_NONBLOCK
debug1: type 11
debug1: XXX shrink: 3 < 4
debug3: fd 4 is O_NONBLOCK
debug1: type 11
debug1: XXX shrink: 3 < 4
$

Duplicacy in shell 2 on client
------------------------------

$ SSH_AUTH_SOCK=/var/folders/rx/s_h0zqcd2sj7r70299njxk180000gp/T//ssh-xTDhJNCV0W56/agent.37450; export SSH_AUTH_SOCK
$ echo $SSH_AUTH_SOCK
/var/folders/rx/s_h0zqcd2sj7r70299njxk180000gp/T//ssh-xTDhJNCV0W56/agent.37450
$ ssh-add ~/.ssh/id_rsa-FOO
Enter passphrase for /Users/USER/.ssh/id_rsa-FOO: 
Identity added: /Users/USER/.ssh/id_rsa-FOO (/Users/USER/.ssh/id_rsa-FOO)
$ ssh-add -L
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDlGGInfnT3eNjmWQK0GpgtTF/A0phIo9U7924ebutQIstnuOjd5aeZrETnwnFNzb5obl6gA3XUgv34cNeohB5kWL+5Qnkt1J0sOV6h6cFwVgDeJm+pn7NZwbXi9TkbnulfMs55Fym9PGE5Mr05YGc11q2mEFhCe2AU/Q2I6x6iXGLkeIGMhOih/fj4giM2wOgJ9+fieUOOeYZEstW13/aEqm+d5a7wc7tP5Am89wMjFWzQOPecR/BghNsSEApZBdfQRN5odyDqwOLgcAPsZsQ2QVrz/z9rvEggeRPj6RBquDkxHtk/+FHNwjRDgu3yASW9vnSdQ7q/khJHPltqOwBR /Users/USER/.ssh/id_rsa-FOO
$ 
$ ~/go/bin/duplicacy -d -log init -e home sftp://SERVER:2222/backup/duplicacy
2017-10-12 21:53:16.801 DEBUG PASSWORD_ENV_VAR Reading the environment variable DUPLICACY_SSH_KEY_FILE
2017-10-12 21:53:17.127 DEBUG SSH_PUBLICKEY Attempting public key authentication
2017-10-12 21:53:17.128 DEBUG SSH_AGENT Attempting public key authentication via agent
2017-10-12 21:53:17.128 DEBUG PASSWORD_ENV_VAR Reading the environment variable DUPLICACY_SSH_KEY_FILE
Enter the path of the private key file:/Users/USER/.ssh/id_rsa-FOO
2017-10-12 21:53:28.281 INFO SSH_PUBLICKEY Failed to parse the private key file /Users/USER/.ssh/id_rsa-FOO: ssh: cannot decode encrypted private keys
2017-10-12 21:53:28.287 ERROR STORAGE_CREATE Failed to load the SFTP storage at sftp://SERVER:2222/backup/duplicacy: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain
$

SSH daemon on server
--------------------

# /usr/sbin/sshd -p 2222 -D -d -e
debug1: HPN Buffer Size: 65536
debug1: sshd version OpenSSH_6.6.1p1_hpn13v11 FreeBSD-20140420, OpenSSL 1.0.1p-freebsd 9 Jul 2015
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type ECDSA
debug1: private host key: #2 type 3 ECDSA
debug1: private host key: #3 type 4 ED25519
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-p'
debug1: rexec_argv[2]='2222'
debug1: rexec_argv[3]='-D'
debug1: rexec_argv[4]='-d'
debug1: rexec_argv[5]='-e'
debug1: Bind to port 2222 on ::.
debug1: Server TCP RWIN socket size: 65536
debug1: HPN Buffer Size: 65536
Server listening on :: port 2222.
debug1: Bind to port 2222 on 0.0.0.0.
debug1: Server TCP RWIN socket size: 65536
debug1: HPN Buffer Size: 65536
Server listening on 0.0.0.0 port 2222.
debug1: fd 5 clearing O_NONBLOCK
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: HPN Buffer Size: 65536
debug1: sshd version OpenSSH_6.6.1p1_hpn13v11 FreeBSD-20140420, OpenSSL 1.0.1p-freebsd 9 Jul 2015
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type ECDSA
debug1: private host key: #2 type 3 ECDSA
debug1: private host key: #3 type 4 ED25519
debug1: inetd sockets after dupping: 3, 3
debug1: res_init()
Connection from CLIENT port 54950 on SERVER port 2222
debug1: HPN Disabled: 0, HPN Buffer Size: 65536
debug1: Client protocol version 2.0; client software version Go
debug1: no match: Go
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1_hpn13v11 FreeBSD-20140420
debug1: permanently_set_uid: 22/22 [preauth]
debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug1: kex: client->server aes128-ctr hmac-sha2-256-etm@openssh.com none [preauth]
debug1: kex: server->client aes128-ctr hmac-sha2-256-etm@openssh.com none [preauth]
debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: KEX done [preauth]
debug1: userauth-request for user  service ssh-connection method none [preauth]
debug1: attempt 0 failures 0 [preauth]
Invalid user  from CLIENT
input_userauth_request: invalid user  [preauth]
debug1: userauth-request for user  service ssh-connection method publickey [preauth]
debug1: attempt 1 failures 0 [preauth]
Connection closed by CLIENT [preauth]
debug1: do_cleanup [preauth]
debug1: monitor_read_log: child log fd closed
debug1: do_cleanup
debug1: Killing privsep child 17540
#

*NOT* PROVIDING PATH TO SSH KEY WHEN ASKED
==========================================

SSH agent in shell 1 on client
------------------------------

$ ssh-agent -d
SSH_AUTH_SOCK=/var/folders/rx/s_h0zqcd2sj7r70299njxk180000gp/T//ssh-Osl3eRUA62np/agent.37483; export SSH_AUTH_SOCK;
echo Agent pid 37483;
debug2: fd 3 setting O_NONBLOCK
debug3: fd 4 is O_NONBLOCK
debug1: type 17
debug1: XXX shrink: 3 < 4
debug3: fd 4 is O_NONBLOCK
debug1: type 11
debug1: XXX shrink: 3 < 4
debug3: fd 4 is O_NONBLOCK
debug1: type 11
debug1: XXX shrink: 3 < 4
^Cdebug1: cleanup_socket: cleanup
$

Duplicacy in shell 2 on client
------------------------------

$ SSH_AUTH_SOCK=/var/folders/rx/s_h0zqcd2sj7r70299njxk180000gp/T//ssh-Osl3eRUA62np/agent.37483; export SSH_AUTH_SOCK
$ echo $SSH_AUTH_SOCK
/var/folders/rx/s_h0zqcd2sj7r70299njxk180000gp/T//ssh-Osl3eRUA62np/agent.37483
$ ssh-add ~/.ssh/id_rsa-FOO
Enter passphrase for /Users/USER/.ssh/id_rsa-FOO: 
Identity added: /Users/USER/.ssh/id_rsa-FOO (/Users/USER/.ssh/id_rsa-FOO)
$ ssh-add -L
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDlGGInfnT3eNjmWQK0GpgtTF/A0phIo9U7924ebutQIstnuOjd5aeZrETnwnFNzb5obl6gA3XUgv34cNeohB5kWL+5Qnkt1J0sOV6h6cFwVgDeJm+pn7NZwbXi9TkbnulfMs55Fym9PGE5Mr05YGc11q2mEFhCe2AU/Q2I6x6iXGLkeIGMhOih/fj4giM2wOgJ9+fieUOOeYZEstW13/aEqm+d5a7wc7tP5Am89wMjFWzQOPecR/BghNsSEApZBdfQRN5odyDqwOLgcAPsZsQ2QVrz/z9rvEggeRPj6RBquDkxHtk/+FHNwjRDgu3yASW9vnSdQ7q/khJHPltqOwBR /Users/USER/.ssh/id_rsa-FOO
$ 
$ ~/go/bin/duplicacy -d -log init -e home sftp://SERVER:2222/backup/duplicacy
2017-10-12 21:59:35.036 DEBUG PASSWORD_ENV_VAR Reading the environment variable DUPLICACY_SSH_KEY_FILE
2017-10-12 21:59:35.358 DEBUG SSH_PUBLICKEY Attempting public key authentication
2017-10-12 21:59:35.358 DEBUG SSH_AGENT Attempting public key authentication via agent
2017-10-12 21:59:35.358 DEBUG PASSWORD_ENV_VAR Reading the environment variable DUPLICACY_SSH_KEY_FILE
Enter the path of the private key file:
2017-10-12 21:59:37.752 INFO SSH_PUBLICKEY No private key file is provided
2017-10-12 21:59:37.756 ERROR STORAGE_CREATE Failed to load the SFTP storage at sftp://SERVER:2222/backup/duplicacy: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain
$

SSH daemon on server
--------------------

root@FOO:/usr/home/USER # /usr/sbin/sshd -p 2222 -D -d -e
debug1: HPN Buffer Size: 65536
debug1: sshd version OpenSSH_6.6.1p1_hpn13v11 FreeBSD-20140420, OpenSSL 1.0.1p-freebsd 9 Jul 2015
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type ECDSA
debug1: private host key: #2 type 3 ECDSA
debug1: private host key: #3 type 4 ED25519
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-p'
debug1: rexec_argv[2]='2222'
debug1: rexec_argv[3]='-D'
debug1: rexec_argv[4]='-d'
debug1: rexec_argv[5]='-e'
debug1: Bind to port 2222 on ::.
debug1: Server TCP RWIN socket size: 65536
debug1: HPN Buffer Size: 65536
Server listening on :: port 2222.
debug1: Bind to port 2222 on 0.0.0.0.
debug1: Server TCP RWIN socket size: 65536
debug1: HPN Buffer Size: 65536
Server listening on 0.0.0.0 port 2222.
debug1: fd 5 clearing O_NONBLOCK
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: HPN Buffer Size: 65536
debug1: sshd version OpenSSH_6.6.1p1_hpn13v11 FreeBSD-20140420, OpenSSL 1.0.1p-freebsd 9 Jul 2015
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type ECDSA
debug1: private host key: #2 type 3 ECDSA
debug1: private host key: #3 type 4 ED25519
debug1: inetd sockets after dupping: 3, 3
debug1: res_init()
Connection from CLIENT port 54953 on SERVER port 2222
debug1: HPN Disabled: 0, HPN Buffer Size: 65536
debug1: Client protocol version 2.0; client software version Go
debug1: no match: Go
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1_hpn13v11 FreeBSD-20140420
debug1: permanently_set_uid: 22/22 [preauth]
debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug1: kex: client->server aes128-ctr hmac-sha2-256-etm@openssh.com none [preauth]
debug1: kex: server->client aes128-ctr hmac-sha2-256-etm@openssh.com none [preauth]
debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: KEX done [preauth]
debug1: userauth-request for user  service ssh-connection method none [preauth]
debug1: attempt 0 failures 0 [preauth]
Invalid user  from CLIENT
input_userauth_request: invalid user  [preauth]
debug1: userauth-request for user  service ssh-connection method publickey [preauth]
debug1: attempt 1 failures 0 [preauth]
Connection closed by CLIENT [preauth]
debug1: do_cleanup [preauth]
debug1: monitor_read_log: child log fd closed
debug1: do_cleanup
debug1: Killing privsep child 17559
#
gilbertchen commented 7 years ago

I think it is the missing username that caused the problem. The storage url should be sftp://USER@SERVER:2222/backup/duplicacy.

rawtaz commented 7 years ago

Doesn't seem to help. Are you interested in debug output from when i SUPPLY the key path, or when I don't?

gilbertchen commented 7 years ago

I'm pretty sure it is the username. At least not providing one is wrong. A debug output with a fake key path should be enough.

rawtaz commented 7 years ago

Yes, you are right. Adding the username to the URL made it work.

However, IMO one should not have to supply the username in the URL. If there's no username in the URL, the current username of the shell should be used, just as is usual in most other common cases (e.g. if I sftp to a server using sftp IP it will happily log me in as the same user as in my shell, unless I overrode that in the SSH config).

rawtaz commented 7 years ago

Would of course also be nice to not have to supply the darn key path. Shouldn't be needed.