Dear Maintainer,

Backups with duplicity are failing in a random manner. I use public key
authentication with duplicity and it often dies with the following
message:

BackendException: ssh connection to sftp.host.xxx:22 failed: Authentication failed.

(sftp.host.xxx is just an example name)

It also works from time to time while nothing changed. This bug is something that popped up several weeks ago. I have 20+ hosts running duplicity every night some fail some don't.
Now i'm 100% sure there is nothing wrong with the ssh hosts and public key authentication works with "normal" ssh/scp/sftp.

I have tested this on:
- oldstable with 0.6.18-3~bpo60+1 (backport)
- stable with 0.6.18-3
- oldstable with 0.6.23-1 (build from deb-src)


A verbose trace of duplicity failing in action:
--------------------------------------------------------------------------
command:

/usr/bin/duplicity collection-status --sign-key #### --log-file /var/log/duplicity/duplicity.log --verbosity 9 scp://###@sftp.host.xxx/path

Using archive dir: /root/.cache/duplicity/c5af6ab267a8aff1a2af8efc9f6d5467
Using backup name: c5af6ab267a8aff1a2af8efc9f6d5467
Import of duplicity.backends.hsibackend Succeeded
Import of duplicity.backends.imapbackend Succeeded
Import of duplicity.backends.cloudfilesbackend Succeeded
Import of duplicity.backends.webdavbackend Succeeded
Import of duplicity.backends.gdocsbackend Succeeded
Import of duplicity.backends.u1backend Succeeded
Import of duplicity.backends.sshbackend Succeeded
Import of duplicity.backends.rsyncbackend Succeeded
Import of duplicity.backends.botobackend Succeeded
Import of duplicity.backends.ftpsbackend Succeeded
Import of duplicity.backends.giobackend Failed: No module named gio
Import of duplicity.backends.localbackend Succeeded
Import of duplicity.backends.ftpbackend Succeeded
Import of duplicity.backends.tahoebackend Succeeded
ssh: starting thread (client mode): 0x1e24590L
ssh: Connected (version 2.0, client OpenSSH_3.7.1p2)
ssh: kex algos:['diffie-hellman-group-exchange-sha1', 'diffie-hellman-group1-sha1'] server key:['ssh-rsa', 'ssh-dss'] client encrypt:['aes128-cbc', '3des-cbc', 'blowfish-cbc'] server encrypt:['aes128-cbc', '3des-cbc', 'blowfish-cbc'] client mac:['hmac-md5', 'hmac-sha1', 'hmac-sha1-96'] server mac:['hmac-md5', 'hmac-sha1', 'hmac-sha1-96'] client compress:['none'] server compress:['none'] client lang:[''] server lang:[''] kex follows?False
ssh: Ciphers agreed: local=aes128-cbc, remote=aes128-cbc
ssh: using kex diffie-hellman-group1-sha1; server key type ssh-rsa; cipher: local aes128-cbc, remote aes128-cbc; mac: local hmac-sha1, remote hmac-sha1; compression: local none, remote none
ssh: Switch to new keys ...
ssh: Trying discovered key ###################### in /root/.ssh/id_rsa
ssh: userauth is OK
ssh: Authentication (publickey) failed.
Using temporary directory /tmp/duplicity-nhEUIu-tempdir
Backend error detail: Traceback (most recent call last):
  File "/usr/bin/duplicity", line 1404, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1397, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1248, in main
    action = commandline.ProcessCommandLine(sys.argv[1:])
  File "/usr/lib/python2.7/dist-packages/duplicity/commandline.py", line 999, in ProcessCommandLine
    globals.backend = backend.get_backend(args[0])
  File "/usr/lib/python2.7/dist-packages/duplicity/backend.py", line 158, in get_backend
    return _backends[pu.scheme](pu)
  File "/usr/lib/python2.7/dist-packages/duplicity/backends/sshbackend.py", line 140, in __init__
    raise BackendException("ssh connection to %s:%d failed: %s" % (parsed_url.hostname,portnumber,e))
BackendException: ssh connection to sftp.host.xxx:22 failed: Authentication failed.

BackendException: ssh connection to sftp.host.xxx:22 failed: Authentication failed.
ssh: EOF in transport thread
--------------------------------------------------------------------------

This all happens when using the default ssh backend (paramiko). I've build 0.6.23-1 on oldstable:

1. add a deb-src line for sid to your sources.list
2. apt-get update
3. apt-get build-dep duplicity
4. apt-get -b source duplicity
5. dpkg -i duplicity_0.6.23-1_amd64.deb

With 0.6.23-1 i have the oppertunity to choose the pexpect backend which uses the sftp commands. This works flawlessly, everytime duplicity works, no authentication failed messages.

So to conclude:

This sometimes works:

/usr/bin/duplicity collection-status --sign-key #### --log-file /var/log/duplicity/duplicity.log --verbosity 9 scp://###@sftp.host.xxx/path

but often fails with:

BackendException: ssh connection to sftp.host.xxx:22 failed: Authentication failed.


This always works:

/usr/bin/duplicity collection-status --ssh-backend -expect --sign-key #### --log-file /var/log/duplicity/duplicity.log --verbosity 9 scp://###@sftp.host.xxx/path





Regards,

Frodo

On Tue, 18 Mar 2014 11:34:07 +0100, Frodo Larik writes:
...

could you provide some info from the server side of one of those failing connections, ie. does your ssh server log anything useful on those instances?

this looks like a bug in paramiko, the python ssh implementation that's used
when you don't use the pexpect backend.

regards
az

Hi!

Using `duply' as a frontend, we're experiencing this bug in recent
weeks, too.  Duplicity used to work, automatically using user's
~/.ssh/id_rsa key without further config.

  Out of curiosity, we added
--ssh-options=-oIdentityFile=/.../.ssh/id_rsa, but it seems (using
`duply') this strangely breaks GPG encryption when it's really used,
though it works initially when it tests to sign and encrypt with that
very key.

  What's even more interesting is that, as said, is just used to work
and then gradually failed more often in a timespan of, say, three or
four weeks. It's now at about 100% failure. I see that it seems there
was an auto-update of Python 2.7 in that timespan, though
python-paramiko wasn't updated.

MfG, JBG

Hi!

Actually, explicitely supplying the key file (instead of letting
Paramiko find it automatically) seems to be a proper workaround for
this issue. The GPG error seems to be unrelated and is also gone by
now.

  As a workaround, this does the job. However, I'm not sure how to
actually fix it, because there's so little debugging aid in Paramiko.
Would have been nice to have lots of logging all over the place... If
somebody who's deeper "into" the code wants to do in-depth debugging,
I'll help!

  As another note, it *seems* that with Debian's current "unstable"
version (1.10.1-1), I cannot trigger this bug on my desktop system,
while it does trigger in Ubuntu's lucid version, 1.7.7.1-2ubuntu1.
However, since this authentication error used to come and go for some
extended period of time, this may or may not be a red herring.

MfG, JBG

reassign 742015 python-paramiko
retitle 742015 paramiko: random but frequent public key authentication failures
thanks

On Tue, 18 Mar 2014 11:34:07 +0100, Frodo Larik writes:
...


reassigning this to paramiko.

the failing code essentially boils down to:

import paramiko;
self.client = paramiko.SSHClient()
self.client.set_missing_host_key_policy(AgreedAddPolicy())
# ...parameter are collected...
self.client.connect(hostname=self.config['hostname'],
     port=self.config['port'],
     username=self.config['user'],
     password=password,
     allow_agent=True,
     look_for_keys=True,
     key_filename=self.config['identityfile'])

regards
az

Dear Customer,

This is to confirm that your item has been shipped at February 18.

Please check delivery label attached!

Kind thanks,
Nathan Mueller,
UPS Parcels Operation Manager.

Hi,



I'm sorry to trouble you. I would love to hear your thoughts with the
follow-up request.



Awaiting for your swift response



Regards,

Claire



From: claire.ross [mailto:claire.ross@eventdelegates.com]
Sent: Wednesday, February 23, 2022 11:26 AM
To: '742015@bugs.debian.org' <742015@bugs.debian.org>
Subject: Seatrade Cruise Global
Importance: High



Greetings,



I'm connecting to see if you would be interested in purchasing the attendees
profile database of Seatrade Cruise Global 2022?



Attendees: Ship Owners/Operators | Tour Operators | Suppliers | Architects |
Brokers | Itinerary Planners | Port & Terminal Developers | Travel Agents |
Influential Industry Professionals | and many more.



If you're interested, Let me know I will assist you with the counts and
pricing details for your further references.



Just let me know if you have any questions.



Regards,

Claire Ross | Marketing Executive.



To remove, kindly respond with "Abolish".