Bug 443155 - kdeconnect breaks when openssh is upgraded to version 8.8p1-1
Summary: kdeconnect breaks when openssh is upgraded to version 8.8p1-1
Status: REOPENED
Alias: None
Product: kdeconnect
Classification: Unclassified
Component: common (show other bugs)
Version: unspecified
Platform: Archlinux Packages Linux
: NOR major with 107 votes (vote)
Target Milestone: ---
Assignee: Albert Vaca
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-09-30 09:18 UTC by MikeC
Modified: 2021-12-28 14:27 UTC (History)
13 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description MikeC 2021-09-30 09:18:09 UTC
SUMMARY

kdeconnect on the plasma desktop, when paired to an android phone running kdeconnect, and that previously opened/exposed the phone filesystem on the linux plasma desktop, now fails to do so after the openssl package is updated to version 8.8p1-1

STEPS TO REPRODUCE
1. transfer files from phone to computer using kdeconnect when paired correctly
2. update openssl to version 8.8p1-1
3. kdeconnect now fails to open the directory tree on the phone using sshfs once the openssl package has been updated, since sshfs depends on openssl

OBSERVED RESULT
desktop kdeconnect now beeps repeatedly with a warning that sshfs cannot expose the filesystem, and in the journal log lines now contain:

kdeconnectd[1007]: QDBusAbstractAdaptor: Cannot relay signal SftpPlugin::packetReceived(NetworkPacket): Unregistered input type in parameter list: NetworkPacket


EXPECTED RESULT
The phone filesystem should be exposed so that files can be transferred.

SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: plasma-desktop 5.22.5-1
KDE Frameworks Version: plasma-framework 5.86.0-1
Qt Version: qt5-base 5.15.2+kde+r227-1

kdeconnect 21.08.1-1

ADDITIONAL INFORMATION

It is possible that the changelog at https://www.openssh.com/releasenotes.html may have an impact on sshfs and kdeconnect - such as the "potentially incompatible changes" that would affect other code which uses the new incompatibilities including sshfs and kdeconnect
Comment 1 Maciej Stanczew 2021-09-30 17:17:11 UTC
Small clarification, regression is introduced after upgrading openssh (not openssl) to 8.8p1.
Comment 2 I don't need a name 2021-09-30 17:57:09 UTC
Can confirm
Comment 3 MikeC 2021-09-30 18:59:12 UTC
Thank you for comment 1 - I have changed the title to the correct package involved.
Comment 4 juanmah 2021-10-01 00:39:26 UTC
I can confirm too
Comment 5 MikeC 2021-10-01 12:10:29 UTC
Also I have tested sshfs with the newest openssh package and it works without issue, such as making a directory mnt as a mount point and doing:

$ sshfs remotemachine:/home/mike/Documents/ mnt

then enter ssh password if the ssh agent is not already set up.

then you can list the files on the remote machine using:

$ ls mnt

and then unmount it using:

$ fusermount3 -u mnt

So that all works fine, and suggests the bug is in kdeconnect
Comment 6 Martin Droessler 2021-10-01 12:58:15 UTC
(In reply to MikeC from comment #5)
> 
> So that all works fine, and suggests the bug is in kdeconnect

Well, I guess, rather in the kdeconnect-app on the remote device/phone.

I suspect the offending change is:
"This release disables RSA signatures using the SHA-1 hash algorithm by default."

If thats the only algorithm, the remote device offers, than the connection will fail.
Unless you have something like
"Host old-host
   HostkeyAlgorithms +ssh-rsa
   PubkeyAcceptedAlgorithms +ssh-rsa"
in your ~/.ssh/config

But AFAIK this config is not used/ignored by kdeconnect.

So, I guess, that either the kdeconnect-app must be updated to offer a more modern algorithm, or the kdeconnect desktop-service needs workaround to allow the deprecated algorithm.
Comment 7 MikeC 2021-10-01 19:09:53 UTC
The matter of using the RSA signatures with sha-1 looks like a possible cause of the issue. Is there a way to get kdeconnect to use an alternative sig to test that idea?
Comment 8 MikeC 2021-10-01 19:26:12 UTC
I had a look at the private key for the connection using the command:

$ openssl pkey -in .config/kdeconnect/privateKey.pem -text

and in the output there is a line:

RSA Private-Key: (2048 bit, 2 primes)

SO it is certainly using RSA. I wonder if the algorithm can be changed for kdeconnect?
Comment 9 MikeC 2021-10-01 19:30:33 UTC
This bug from 2020 is not dissimilar to the current bug https://bugs.kde.org/show_bug.cgi?id=417787
Comment 10 MikeC 2021-10-06 19:23:33 UTC
This is now fully resolved with arch Linux updated packages sshfs 3.7.2-2 and kdeconnect 21.08.1-2 and kdeconnect now connects to my Android phone, after re-pairing, and the exposed filesystem on the phone is now visible in the kdedesktop in dolphin. As used to be the case. So I will close this bug.
Comment 11 Antonio Rojas 2021-10-06 19:43:35 UTC
(In reply to MikeC from comment #10)
> This is now fully resolved with arch Linux updated packages sshfs 3.7.2-2
> and kdeconnect 21.08.1-2 and kdeconnect now connects to my Android phone,
> after re-pairing, and the exposed filesystem on the phone is now visible in
> the kdedesktop in dolphin. As used to be the case. So I will close this bug.

That's not a fix, it's a workaround in the downstream packaging
Comment 12 MikeC 2021-10-06 19:58:27 UTC
OK - I had assumed this came from upstream - presumably the work-around in the arch packages provides the basis for the upstream source to be fixed if the kde developers make the same changes to the source files?
Comment 13 Antonio Rojas 2021-10-06 20:16:47 UTC
(In reply to MikeC from comment #12)
> OK - I had assumed this came from upstream - presumably the work-around in
> the arch packages provides the basis for the upstream source to be fixed if
> the kde developers make the same changes to the source files?

The Arch fix depends on an unreleased sshfs commit. Pushing the kdeconnect fix with an unpatched sshfs will result in broken file browsing with any openssh version. So I don't see any easy way to port this upstream. I guess this needs to be properly fixed on the Android side by switching to a more secure pubkey algorithm.
Comment 14 MikeC 2021-10-08 10:38:49 UTC
Fixing the android app for kdeconnect seems the most straightforward way to get this resolved. Hopefully the developers will get that implemented soon. Moving to more modern and secure key algorithm would make sense, even if the old algorithms had not been deprecated in openssh.
Comment 15 Fabian Vogt 2021-10-31 13:07:30 UTC
(In reply to MikeC from comment #8)
> I had a look at the private key for the connection using the command:
> 
> $ openssl pkey -in .config/kdeconnect/privateKey.pem -text
> 
> and in the output there is a line:
> 
> RSA Private-Key: (2048 bit, 2 primes)
> 
> SO it is certainly using RSA. I wonder if the algorithm can be changed for
> kdeconnect?

It's not about the algorithm of the private key (though that should ideally be changed to a more secure one as well), but about the hash algorithm of the public key signature. The 2048 bit RSA key could be used with SHA-256/512 as well.
Comment 16 Aleksandar Kostadinov 2021-11-24 15:31:59 UTC
I see a commit allowing `ssh-rsa` algorithm [1]. I think this is insecure. Where is the problem actually? In kdeconnect android app that it uses old SSH server/client or in client machine using old SSH server/client?

I think that if insecure algorithms are to be enabled, that should be an in-app question. Not just allowing old insecure stuff.

And user should be informed whether the problem comes from not updated android app or from not updated ssh client on user's machine.

[1] https://invent.kde.org/network/kdeconnect-kde/-/commit/460eb70a81f13955f2ff32f38178c79695cb7413