I tried to connect nethserver-backup to a Hetzner’s robot Storage through SFTP using Cockpit. That failed miserably, with that error message in the system log :
exec request failed on channel 0
That cryptic error message lead to that ServerFault page and to the suspicion that there was some kind of validation not supported by Hetzner’s storage system.
… and found that the validation process tries to execute some sh command, which is not allowed (no exec system call allowed if I understood correctly).
I tried to comment out the offending line and succeeded to complete the wizard. However, the backup script later tries to send copy ssh id’s… which is also not supported by the SFTP server.
I guess I’ll need to access the server by another using another protocol, but I wanted to share that user case with you.
To actually find out what the problem was, I had to log in manually (SSH to the dediserver, and running my scp command locally from the dedihost)…
Turns out the default encryption was the issue in my case. I had to deactivate some old ciphers in the ssh config, then it worked.
Using a GUI, you probably won’t get to see the error message in connecting…
Note, my issue wasn’t directly with NethServers backup, but with generic SSH / SCP connectivity…
Thanks Andre. But I think that the problem is clear : Nethserver’s backup module expects the target server to be smart and will not work with dumb, basic, passive, restricted, pure (S)FTP servers.
I tried other ways. SMB + Restic don’t work, because of some unexplained incompatibility.
I also tried Webdav + rync. Works more or less but performance is absolutely terrible, not usable.
Still finding my way but generally it looks like nethserver’s backup module is not really effective with dumb and restricted servers.