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
desktop kdeconnect now beeps repeatedly with a warning that sshfs cannot expose the filesystem, and in the journal log lines now contain:
kdeconnectd: QDBusAbstractAdaptor: Cannot relay signal SftpPlugin::packetReceived(NetworkPacket): Unregistered input type in parameter list: NetworkPacket
The phone filesystem should be exposed so that files can be transferred.
(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
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
Small clarification, regression is introduced after upgrading openssh (not openssl) to 8.8p1.
Thank you for comment 1 - I have changed the title to the correct package involved.
I can confirm too
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
(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
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.
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?
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?
This bug from 2020 is not dissimilar to the current bug https://bugs.kde.org/show_bug.cgi?id=417787
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.
(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
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?
(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.
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.
(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
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.
I see a commit allowing `ssh-rsa` algorithm . 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.