Pushed python-paramiko-2.0.8-1.1.mga6 with a patch backported from upstream to core/updates_testing. Please test.

CC: (none) => jani.valimaa

works for me, no more messages on console. Backup works.

Assigning to QA team.

Assignee: python => qa-bugs

Testing this on Mageia 6, x86_64.
This was tested recently, bug #22837, using the backup utility duplicity.  Ran a quick test to recover an existing backup from another machine and a particular folder from that backup.  That worked as expected.

I need to figure out what this ECDSA signature stuff means.  It was not previously tested.

CC: (none) => tarazed25

This is caused if the backup is (re-)stored via ssh backend. For my scripts this is run


duplicity ${DUPOPTIONS} ${CMD} sftp://${SERVER}/${NAME} --name ${NAME} --ssh-options='-i /etc/ssh/ssh_host_rsa_key' --archive-dir /mnt/backuplog/

Using release version of python-paramiko.

Tried various commands modelled on Marc's comment 5 example but could not get them to work, let alone reproduce the ECDSA problems, a matter of pure ignorance on my part probably.  e.g.
$ cat duplicity.sh
export PASSPHRASE=Rapunzel22
export TARGET=$1
export FOLDER=$2
duplicity ${FOLDER} scp://lcl@vega/${TARGET} --ssh-options='-i /home/lcl/.ssh/known_hosts'
$ ./duplicity.sh /home/lcl/docs /data/backup4
BackendException: ssh connection to lcl@vega:22 failed: Private key file is encrypted

Tried removing the vega ecdsa entries from known_hosts then:
$ ./duplicity.sh /home/lcl/docs /data/backup4
The authenticity of host 'vega' can't be established.
ECDSA-SHA2-NISTP256 key fingerprint is 2a:4f:06:bf:c6:c1:3e:f8:4b:8c:15:30:e5:e8:e6:bb.
Are you sure you want to continue connecting (yes/no)? yes
BackendException: ssh connection to lcl@vega:22 failed: Private key file is encrypted
$ ssh lcl@vega
Warning: Permanently added the ECDSA host key for IP address '192.168.1.3' to the list of known hosts.
Password: 
[lcl@vega ~]$ exit


The following simple commands do work:

$ duplicity /home/lcl/ruby sftp://lcl:<password>@vega//data/backup2
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: none
GnuPG passphrase: <whatever>
Retype passphrase to confirm: <whatever>
No signatures found, switching to full backup.
--------------[ Backup Statistics ]--------------
StartTime 1524593035.00 (Tue Apr 24 19:03:54 2018)
EndTime 1524593037.46 (Tue Apr 24 19:03:57 2018)
ElapsedTime 2.47 (2.47 seconds)
SourceFiles 2200
SourceFileSize 61506433 (58.7 MB)
NewFiles 2200
NewFileSize 61506433 (58.7 MB)
DeletedFiles 0
ChangedFiles 0
ChangedFileSize 0 (0 bytes)
ChangedDeltaSize 0 (0 bytes)
DeltaEntries 2200
RawDeltaSize 60642119 (57.8 MB)
TotalDestinationSizeChange 27167984 (25.9 MB)
Errors 0
-------------------------------------------------

$ duplicity scp://lcl:<password>@vega//data/backup2 tmp/backup2 
Synchronising remote metadata to local cache...
GnuPG passphrase: <whatever> 
Copying duplicity-full-signatures.20180424T180314Z.sigtar.gpg to local cache.
Copying duplicity-full.20180424T180314Z.manifest.gpg to local cache.
Last full backup date: Tue Apr 24 19:03:14 2018

Local tmp/backup2 contained a full copy of the original folder.

Not worth continuing this investigation - don't know enough about this signature and encryption business.

@Lens: no that's ok. I just have a few more variables.

Thanks Marc.  Since the whole point of the bug is to address the issue you are having it needs to be sorted.  I am dropping it because I don't have the background to understand how to reproduce it but there must be somebody else who could (?).  My apologies anyway.  None of us in QA likes to throw in the towel on any bug.

MGA6-32 on Dell Latitude D600 MATE
No installation issues
Following the duplicity ftp example from Comment 6, I made a similar attempt, and straced the duplicity command.
The command fails ultimately because the backup requires some 260+Mb on temp space ans my very limited setup has only 248Mb.
But the strace shows some apparently successfull calls (at least no errors) on paramiko. Same for a backup to a local folder.
At least in my opinion there is proof that the update does not impact the normal working of duplicity. If Len agrees to OK, I won't object.

CC: (none) => herman.viaene

Thanks for the 32-bit test Herman.  I agree that our tests show that duplicity works OK but I am not willing to give it the OK here unless Marc can say that he no longer has a problem.  This would be the second time recently that we have had to ask somebody outside the team to add a confirmation - not ideal at all.  It is just that some bugs occur within such a narrow set of circumstances that we can find them difficult or impossible to reproduce.  Mind you we do pass updates when PoCs do not provide a definitive test.  Need a third opinion on this.

@Len: I don't think you can cover all things that change in an update process by upstream.
I don't know exactly what this python library does and how it interacts with ssh connections, I assume it has sth. to do with the specific encryption method used (ecdsa asymetric keys). 

I've had a look at the patch which Jani applied, and this looks like the subsystem of paramiko was not updated correctly to their changes. This patch just changes the old method names to the new ones which do not show this warning.

For me, I have checked the patch on 3 machines, with no more messages.

OK Marc, thanks for the additional information.  And 64-bit OK it is.

Whiteboard: (none) => MGA6-64-OK

OK also for Herman's 32-bit test.

Whiteboard: MGA6-64-OK => MGA6-64-OK MGA6-32-OK

This is an update, not a backport, advisory added to svn

Keywords: validated_backport => advisory, validated_update
CC: (none) => tmb, sysadmin-bugs

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGAA-2018-0077.html

Resolution: (none) => FIXED
Status: NEW => RESOLVED