I'm using paramiko as the SSH backend for duply. Recently, after
looking more closely at the current SSH man page, I found that
newer types of SSH keys, ECDSA and ED25519, existed. So I created
new keypairs of that nature, and all seemed to work fine. Until
my next backup.

I began getting errors like this:
---

I spent some time trying to find out the cause of this error, and
finally narroed it down to the new keypairs.

Note the filenames (~/.ssh/id_dsa, ~/.ssh/id_ecdsa,
~/.ssh/id_ed25519 and ~/.ssh/id_rsa). In my case, these were
symbolic links to the real private key files, but replacing the
links with copies of the real file makes no difference.

File id_dsa doesn't affect paramiko's operation (as I imagine it
shouldn't: that filename has been generated at install time by
SSH2 for as long as I can remember), and neither does id_rsa for
much the same reason. The presence of either of the two new
private key files, id_ecdsa and id_ed25519, or symbolic links by
either name, seems to cause paramiko to barf. Since all my
private keys have passwords (naturally), that may be part of the
problem. Either way, without looking at the code (I'm not a
Python programmer), I'd guess that paramiko knows to ignore the
two older id_* files (id_rsa and id_dsa). It should probably be
told about the new ones, too.

Backtrace from duply is available, but probably not a lot of use
here. The last few lines are:
get_backend_object
packages/duplicity/backends/ssh_paramiko_backend.py", line 218, in __init__
sequence (0x30), got 0x6a
sequence (0x30), got 0x6a
---

I can always upload it if you need it.

I neglected to mention that authentication for my backups is normally
in  the form of passwords (contained in duply's config file). I don't
use public-key authentication for my backups, although I do use it for
all other SSH purposes.

 .....Ron