Hey,
i try to run Duplicati 2 on a RaspberryPi (Raspian). Everytime i try to connect to my webserver (Ubuntu 16.04, OpenSSH 7.2) it shows an error “Failed to connect: Session operation has timed out”.
If i try to connect to the server from the RPi manually via SSH, there is no problem. If i try to connect Duplicate SFTP to my server from another machine (x86/x64), there is no problem too.
What can i do?
Neo
That sounds like something is blocking Duplicati?
One thing you can try is running the SSH daemon in “debug mode” on the server, and see if it tells you that it connects and why it fails:
/usr/sbin/sshd -dD -p 3333
This will start the daemon in “debug mode” meaning that it listens to another port (-p 3333), only accepts one connection before shutting down (-d), and outputs debug info (-D).
Then try to connect to port 3333 from the RPI and watch the server output.
Thx for your reply.
I tried the debug mode. That was the result (server side):
$ sudo /usr/sbin/sshd -dD -p 2222 debug1: sshd version OpenSSH_7.2, OpenSSL 1.0.2g 1 Mar 2016 debug1: private host key #0: ssh-rsa SHA256:*****(censored) debug1: private host key #1: ssh-dss SHA256:*****(censored) debug1: private host key #2: ecdsa-sha2-nistp256 SHA256:*****(censored) debug1: private host key #3: ssh-ed25519 SHA256:*****(censored) debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-dD' debug1: rexec_argv[2]='-p' debug1: rexec_argv[3]='2222' debug1: Set /proc/self/oom_score_adj from 0 to -1000 debug1: Bind to port 2222 on 0.0.0.0. Server listening on 0.0.0.0 port 2222. debug1: Bind to port 2222 on ::. Server listening on :: port 2222. debug1: Server will not fork when running in debugging mode. debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8 debug1: inetd sockets after dupping: 3, 3 Connection from *****(censored) port 46192 on *****(censored) port 2222 debug1: Client protocol version 2.0; client software version Renci.SshNet.SshClient.0.0.1 debug1: no match: Renci.SshNet.SshClient.0.0.1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.2 debug1: permanently_set_uid: 107/65534 [preauth] debug1: list_hostkey_types: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] debug1: SSH2_MSG_KEXINIT sent [preauth] debug1: SSH2_MSG_KEXINIT received [preauth] debug1: kex: algorithm: diffie-hellman-group-exchange-sha256 [preauth] debug1: kex: host key algorithm: ssh-rsa [preauth] debug1: kex: client->server cipher: aes256-ctr MAC: hmac-sha1 compression: none [preauth] debug1: kex: server->client cipher: aes256-ctr MAC: hmac-sha1 compression: none [preauth] debug1: expecting SSH2_MSG_KEX_DH_GEX_REQUEST [preauth] debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received [preauth] debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth] debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT [preauth] debug1: rekey after 4294967296 blocks [preauth] debug1: SSH2_MSG_NEWKEYS sent [preauth] debug1: expecting SSH2_MSG_NEWKEYS [preauth]
Is that the end of the log?
There is a thread discussing a similar problem here:
https://lists.mindrot.org/pipermail/openssh-unix-dev/2013-December/031879.html
Not entirely the same, but could it be something like this:
http://www.thegeekstuff.com/2010/07/openssh-slow-at-ssh2_msg_service_accept-received/
Yes, that’s the end of the log. At this point, Duplicati shows the error message.
I read your discussions, but couldn’t find a solution.
The strange part is: On every other machine, Duplicati can connect to my server and my RPi, which can’t, can connect to other servers. Just the combination of my RPi and my server results in this error.
@kenkendk are you german?
Ok, i overclocked the RPi and now it seems to work.
The key exchange via mono is too much for the RPi. But with SSH in the Terminal it connects instantly.
So non-mono SSH key exchange is “lighter” on resources? Interesting.
Close… Danish 
Really strange … It must negotiate another encryption methods or something.
Is it possible to speed that up in future releases? I don’t want to have to overclock my RPi just for a SSH key exchange^^
But it works so i think i could accept it if not.
I am not really sure why it works with overclocking enabled, so I would not know where to start debugging it.
Maybe you can try to connect with the debugging enabled, from a normal ssh client, and compare the two to see if it chooses another algorithm. You can then selectively disable the other algorithms, until you find the one that Renci.SSH is using.
It should be possible to simply disable that algorithm and then the connection will just work with another one.
There is discussion on how to configure available algorithms here:
I will try and report that.
I know this thread is 6 months old now, but I just wanted to add a shared experience here. I am running Duplicati Canary on a Raspberry Pi Model B. With the board running at stock speeds, I get a timeout on SFTP connection tests just as described here. However once I overclock the board, the timeout goes away.
I had been considering overclocking for other reasons anyway so I’m ok with this as long as it remains stable. I love that Duplicati runs on the Pi - however no idea why the overclock should be needed for SFTP connectivity tests…
Thanks for sharing your experience with this as well! Hopefully some day we’ll have enough other things resolved that we can look into why the overclocking seems necessary. 
I know - the number of people using Duplicati on the old Model B is I doubt a high priority for the project! I am just trying to make good use of old hardware…
On a related note although I thought I’d got everything to work once I had performed the overclock, it the backup failed partway through with the same timeout error. So perhaps once I put load onto the SFTP connection the RPi Model B couldn’t cope even when overclocked.
I tried WebDAV but FreeNAS 11’s implementation of WebDAV didn’t work with Duplicati (though I didn’t spend long debugging and that’s off topic anyway). Currently testing plain old FTP to see if that will work.
Thanks for taking note of this - if you ever want someone to test Duplicati on esoteric old ARM hardware, I am happy to help!
That’s odd - I think I read that others are using WebDAV on FreeNAS, though it could be a different version (or I’m just making things up).
Hi there ! Just tried canary and beta version as well on a Raspberry PI 3B+, same behaviour ! While it’s working for FTP service, impossible to make it work for SSH.
The exact same setup is working fine on a classic intel server, but on ARM it seems mono-SSH is not working well…
I tried to debug and I’m also stuck with these logs on my debug ssh server:
ebug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: sshd version OpenSSH_7.4, OpenSSL 1.0.2u-fips 20 Dec 2019
debug1: get user realname admin => admin
debug1: private host key #0: ssh-rsa SHA256:FDpflOXXXXXthuf1p18
debug1: private host key #1: ssh-dss SHA256:S1xwDdbXXXXX1eMcihO0
debug1: private host key #2: ecdsa-sha2-nistp256 SHA256:s2XjKTKXXXh4MHYrEfEwio
debug1: private host key #3: ssh-ed25519 SHA256:uWwDoXXXCXAfT++llZP1vzSrQ
debug1: inetd sockets after dupping: 3, 3
Connection from 192.168.0.x port 4xx54 on 192.168.0.x port 4455
debug1: Client protocol version 2.0; client software version Renci.SshNet.SshClient.0.0.1
debug1: no match: Renci.SshNet.SshClient.0.0.1
debug1: Local version string SSH-2.0-OpenSSH_7.4
debug1: Enabling compatibility mode for protocol 2.0
debug1: permanently_set_uid: 1024/100 [preauth]
debug1: ssh_sandbox_child: prctl(PR_SET_SECCOMP): Invalid argument [preauth]
debug1: list_hostkey_types: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug1: kex: algorithm: diffie-hellman-group-exchange-sha256 [preauth]
debug1: kex: host key algorithm: ssh-rsa [preauth]
debug1: kex: client->server cipher: aes256-ctr MAC: hmac-sha1 compression: none [preauth]
debug1: kex: server->client cipher: aes256-ctr MAC: hmac-sha1 compression: none [preauth]
debug1: expecting SSH2_MSG_KEX_DH_GEX_REQUEST [preauth]
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received [preauth]
WARNING: could not open /etc/ssh/moduli (No such file or directory), using fixed modulus
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth]
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT [preauth]
debug1: rekey after 4294967296 blocks [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: rekey after 4294967296 blocks [preauth]
debug1: KEX done [preauth]
I am available if someone wants to understand what happens. Like it’s said before, connecting from SSH CLI is working fine and is very fast…
Welcome to the forum @quentindavid
Looking at Duplicati’s third-party SSH.NET data with Wireshark (with help from OpenSSH moduli) saw
DH GEX Number of Bits: 1024
Increase the Secure Shell Minimum Recommended Diffie-Hellman Modulus Size to 2048 Bits says 1024 bits can be broken using sufficient computing resources. Your RPi might be at the other end of the scale, possibly unable to process that fixed modulus in a timely fashion, whereas your Intel server can handle it.
I think the moduli file is commonly pregenerated, so if you have another system you could try copying one.
There was also an SSH.NET bug, but if by Beta and Canary you mean current, the change should be in it. Whether or not the change was meant to solve this missing-moduli issue is unknown, but maybe it didn’t.
Understand debug messages from sshd [closed] might also help. Did RPi ever close? Did Intel continue?
Cannot connect via SSH (Failed to connect: Session operation has timed out) has more speculation on it.
Hi @ts678 ! Thanks for your help. Maybe it would be a good thing to pre-generate the moduli file within Duplicati, as it’s done using the regular ssh command ? It would solve the problem if I’ve correctly understood ?
Nobody knows if problem is understood. Please do a test.
There’s no requirement for SSH commands on the Duplicati side, and moduli file on SSH server side.
Ok I’m sorry I did not understand.
Actually, I generated the moduli file on the SFTP server and now it’s working correctly from my Raspberry Pi 3B+, so thanks for your help !!