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
Small clarification, regression is introduced after upgrading openssh (not openssl) to 8.8p1.
Can confirm
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 "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.
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 > 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.
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
I think I have a similar issue, which I have discussed at length with the author of GSConnect (the GNOME implementation of KDEConnect) here: https://github.com/GSConnect/gnome-shell-extension-gsconnect/issues/1203#issuecomment-1218423970 Briefly, the symptoms are that I cannot mount my phone to my laptop unless I add some extra lines to `~/.ssh/config`: ``` Host 192.168.*.* HostKeyAlgorithms +ssh-rsa ``` As far as I understand, the problem is in the SFTP server that is [bundled](https://invent.kde.org/network/kdeconnect-android/blob/master/build.gradle#L159-L160) with the KDEConnect Android app and which somehow only supports deprecated ciphers. Is that true? And if so, can this problem be somehow patched from the KDEConnect side?
Looking at the lines you send, can it just be the version? implementation 'org.apache.sshd:sshd-core:0.14.0'. This version of sshd-core is from 2015 hence outdated unsecured ciphers are expected. I assume this version is used for some sort of compatibility with older android version. Atleast the comment in the following line indicates something about Android 8. The current sshd-core version is 2.9.1 from 07. September 2022. Maybe the way to solve this, is to update sshd-core to a somewhat resent version. Potentially leaving behind some people using old android versions.
(In reply to Malte Deiseroth from comment #18) > Looking at the lines you send, can it just be the version? > implementation 'org.apache.sshd:sshd-core:0.14.0'. > > This version of sshd-core is from 2015 hence outdated unsecured ciphers are > expected. I assume this version is used for some sort of compatibility with > older android version. Atleast the comment in the following line indicates > something about Android 8. Seems so. The commit (https://invent.kde.org/network/kdeconnect-android/-/commit/ef3fd68f7378398273cb476581bc4f28c6b89515) that added a dependency on Apache Mina clarifies that before it, Android 7 and earlier versions weren't supported. > The current sshd-core version is 2.9.1 from 07. > September 2022. Maybe the way to solve this, is to update sshd-core to a > somewhat resent version. Potentially leaving behind some people using old > android versions. Seems so. I guess @Albert Vaca should make a call on whether it's time to drop support for old Android versions so that SFTP can work without workarounds.
Got this issue with a new Android 12 phone now. What is the current workaround? HostKeyAlgorthms and PubkeyAcceptedAlgorithms +ssh-rsa in .ssh/config did not help.
(In reply to pixelplanetdev from comment #20) > Got this issue with a new Android 12 phone now. > > What is the current workaround? > HostKeyAlgorthms and PubkeyAcceptedAlgorithms +ssh-rsa > in .ssh/config did not help. That's because kdeconnect explicitly disables the use of .ssh/config, I had to remove this line in plugins/sftp/mounter.cpp to make it work: << QStringLiteral("-F") << QStringLiteral("/dev/null") //Do not use ~/.ssh/config