duplicity scp (ssh) working with IP-address, NOT with domain?

Question

I'd like to use duplicity to create an encrypted remote backup. SSH-keys are in place and work:

sudo -u ssh-user -p 41111 domain.myfritz.net

opens a terminal on the remote host. Login is password-less since I created these logins in order to connect via scripts.

Also:

sudo -u ssh-user duplicity -v 5 --encrypt-key=*keyid* /path/to/local scp://123.456.789.012:41111//path/to/backup

works like a charme! But:

sudo -u ssh-user duplicity -v 5 --encrypt-key=*keyid* /path/to/local scp://domain.myfritz.net:41111//path/to/backup

fails. By the way, I have of course also used [email protected] and ssh-us[email protected], always combined with sudo -u, no difference.

With -v 5 this is shown (nothing like this when using the command with the IP!):

Using temporary directory /tmp/duplicity-H9igFH-tempdir
Backend error detail: Traceback (most recent call last):
  File "/usr/bin/duplicity", line 1553, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1547, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1382, in main
    action = commandline.ProcessCommandLine(sys.argv[1:])
  File "/usr/lib/python2.7/dist-packages/duplicity/commandline.py", line 1126, in ProcessCommandLine
    backup, local_pathname = set_backend(args[0], args[1])
  File "/usr/lib/python2.7/dist-packages/duplicity/commandline.py", line 1015, in set_backend
    globals.backend = backend.get_backend(bend)
  File "/usr/lib/python2.7/dist-packages/duplicity/backend.py", line 223, in get_backend
    obj = get_backend_object(url_string)
  File "/usr/lib/python2.7/dist-packages/duplicity/backend.py", line 209, in get_backend_object
    return factory(pu)
  File "/usr/lib/python2.7/dist-packages/duplicity/backends/ssh_paramiko_backend.py", line 235, in __init__
    self.config['port'], e))
BackendException: ssh connection to ssh-use[email protected]:41111 failed: [Errno 13] Permission denied

I have tried to understand (!) and use: --scp-command ssh; pexpect+scp; changed my ssh_config to accept all host keys; --ssh-option "-op 41111" and else in order to avoid the port issue and paramiko, since this seems to be a problem. But it didn't help... myfritz.net is a DDNS service by the manufacturer of my router (Fritz!Box) and works very well - putty logins and ssh-login from my local machine without any problems. Pinging the domain and the IP return virtually the same time. Could someone try to help? I could of course write a script that pings the remote server and uses that IP, but it seems weird.

local: OpenSSH_7.4p1 Debian-10+deb9u6, OpenSSL 1.0.2r 26 Feb 2019 duplicity 0.7.11

remote (domain.myfritz.net): OpenSSH_7.4p1 Raspbian-10+deb9u5, OpenSSL 1.0.2q 20 Nov 2018

Thanks for reading!

EDIT to answer by BarsMonster:

Thanks for your answer! Although pinging returns the correct Ip-address, I manually added the Ip-address to /etc/hosts (test.test.de is now linked to the correct IP). Now the ssh-connection is successful, but a new problem occurs:

ssh: Connected (version 2.0, client OpenSSH_7.4p1)
ssh: Authentication (publickey) successful!
Main action: inc
================================================================================
duplicity 0.7.11 (December 31, 2016)
Args: /usr/bin/duplicity -v 5 --encrypt-key=REDACTED /REDACTED scp://[email protected]:41111/REDACTED    Linux odroidhc2 4.14.94-odroidxu4 #14 SMP PREEMPT Fri Feb 8 11:14:13 CET 2019 armv7l
/usr/bin/python 2.7.13 (default, Sep 26 2018, 18:42:22)
[GCC 6.3.0 20170516]
================================================================================
Using temporary directory /tmp/duplicity-L7N_bX-tempdir
Temp has 1046974464 available, backup will use approx 272629760.
Synchronizing remote metadata to local cache...
PASSPHRASE variable not set, asking user.
GnuPG passphrase for decryption:

a prompt for the GnuPG for decryption appears, I enter the passphrase. And GPG throws an error:

GPG error detail: Traceback (most recent call last):
  File "/usr/bin/duplicity", line 1553, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1547, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1398, in main
    do_backup(action)
  File "/usr/bin/duplicity", line 1419, in do_backup
    sync_archive(decrypt)
  File "/usr/bin/duplicity", line 1206, in sync_archive
    copy_to_local(fn)
  File "/usr/bin/duplicity", line 1151, in copy_to_local
    gpg.GzipWriteFile(src_iter, tdp.name, size=sys.maxsize)
  File "/usr/lib/python2.7/dist-packages/duplicity/gpg.py", line 421, in GzipWriteFile
    new_block = block_iter.next()
  File "/usr/bin/duplicity", line 1131, in next
    self.fileobj.close()
  File "/usr/lib/python2.7/dist-packages/duplicity/dup_temp.py", line 226, in close
    assert not self.fileobj.close()
  File "/usr/lib/python2.7/dist-packages/duplicity/gpg.py", line 279, in close
    self.gpg_failed()
  File "/usr/lib/python2.7/dist-packages/duplicity/gpg.py", line 246, in gpg_failed
    raise GPGError(msg)
GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: encrypted with 3072-bit RSA key, ID REDACTED, created 2019-03-16
"My Name <[email protected]>"
gpg: decryption failed: No secret key
===== End GnuPG log =====

when I connect via IP (scp://123.456.789.012//...) it works. No prompt for passphrase and gpg/duplicity correctly "grasp" the situation. See below:

ssh: Connected (version 2.0, client OpenSSH_7.4p1)
ssh: Authentication (publickey) successful!
Main action: inc
================================================================================
duplicity 0.7.11 (December 31, 2016)
Args: /usr/bin/duplicity -v 5 --encrypt-key=REDACTED /REDACTED scp://[email protected]:41111/REDACTED
Linux odroidhc2 4.14.94-odroidxu4 #14 SMP PREEMPT Fri Feb 8 11:14:13 CET 2019 armv7l
/usr/bin/python 2.7.13 (default, Sep 26 2018, 18:42:22)
[GCC 6.3.0 20170516]
================================================================================
Using temporary directory /tmp/duplicity-rmi2v3-tempdir
Temp has 1046974464 available, backup will use approx 272629760.
Local and Remote metadata are synchronized, no sync needed.
Processing local manifest /REDACTED
Found 1 volumes in manifest
Processing local manifest /REDACTED
Found 1 volumes in manifest
Processing local manifest /REDACTED
Found 1 volumes in manifest
Processing local manifest /REDACTED
Found 1 volumes in manifest
Processing local manifest /REDACTED
Found 1 volumes in manifest
Processing local manifest /REDACTED    Found 1 volumes in manifest
Processing local manifest /REDACTED
Found 1 volumes in manifest
Processing local manifest /REDACTED
Found 1 volumes in manifest
Processing local manifest /REDACTED    Found 1 volumes in manifest
Processing local manifest /REDACTED
Found 1 volumes in manifest
Processing local manifest /REDACTED
Found 1 volumes in manifest
Added incremental Backupset (start_time: Sat Mar 16 13:05:52 2019 / end_time: Sat Mar 16 13:14:34 2019)
Added incremental Backupset (start_time: Sat Mar 16 13:14:34 2019 / end_time: Sat Mar 16 13:18:29 2019)
Added incremental Backupset (start_time: Sat Mar 16 13:18:29 2019 / end_time: Sat Mar 16 13:20:33 2019)
Added incremental Backupset (start_time: Sat Mar 16 13:20:33 2019 / end_time: Sat Mar 16 13:27:07 2019)
Added incremental Backupset (start_time: Sat Mar 16 13:27:07 2019 / end_time: Sat Mar 16 13:28:15 2019)
Added incremental Backupset (start_time: Sat Mar 16 13:28:15 2019 / end_time: Sat Mar 16 13:28:47 2019)
Added incremental Backupset (start_time: Sat Mar 16 13:28:47 2019 / end_time: Sat Mar 16 13:29:03 2019)
Added incremental Backupset (start_time: Sat Mar 16 13:29:03 2019 / end_time: Sat Mar 16 17:28:58 2019)
Added incremental Backupset (start_time: Sat Mar 16 17:28:58 2019 / end_time: Sat Mar 16 17:43:03 2019)
Added incremental Backupset (start_time: Sat Mar 16 17:43:03 2019 / end_time: Sat Mar 16 17:45:53 2019)
Last full backup date: Sat Mar 16 13:05:52 2019
Processing local manifest REDACTED
Found 1 volumes in manifest
Fatal Error: Backup source directory has changed.
Current directory: /REDACTED
Previous directory: REDACTED

Aborting because you may have accidentally tried to backup two different data sets to the same remote location, or using the same archive directory.  If this is not a mistake, use the --allow-source-mismatch switch to avoid seeing this message

The last warning is actually right. I used duplicity on the remote server to encrypt a small test folder. My goal is to encrypt the complete remote backup (which is already in place, done by rsync) and use duplicity to add new data encrypted.

Answer 1

The only explanation could be that resolved (cached) domain name and IP address you expect does not match. So when you are connecting by domain - you are getting to a different server.

Please double check that ping domain gives you the server you expect, and this IP address is matching the one you know working. If you have port forwarding in your router setup - you will also need to double check that (i.e. are you going outside of your home network vs it is all internal).

If this does not show the issue -

1) Try to add /etc/hosts entry for some test domain to be resolved to your target IP, and try to connect to this test domain. 2) Try to add /etc/hosts entry for your target domain domain.myfritz.net to be resolved to your target IP. If this helps - then it is definitely something with resolver. 3) Investigate the differences of behavior inside your network (using your local IP of the target server behind the NAT) and when connecting from the outside (using for example cellular network), to verify that NAT and port forwarding works as expected.