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

Git commit 204207f2e66e87e7696ff1c98d70ce41b3e2d396 by Albert Vaca Cintora.
Committed on 12/12/2022 at 20:21.
Pushed by albertvaka into branch 'master'.

Fix ssh authentication using pubkey on recent openssh versions

M  +1    -0    plugins/sftp/mounter.cpp

https://invent.kde.org/network/kdeconnect-kde/commit/204207f2e66e87e7696ff1c98d70ce41b3e2d396

Git commit ceea2af7da84169de32584329df0e4a89af21887 by Simon Redman, on behalf of Albert Vaca Cintora.
Committed on 22/01/2023 at 20:34.
Pushed by sredman into branch 'cherry-pick-204207f2'.

Fix ssh authentication using pubkey on recent openssh versions


(cherry picked from commit 204207f2e66e87e7696ff1c98d70ce41b3e2d396)

M  +1    -0    plugins/sftp/mounter.cpp

https://invent.kde.org/network/kdeconnect-kde/commit/ceea2af7da84169de32584329df0e4a89af21887

Git commit a7c17468f0bf16e4ed87c093dac0b77749c61d50 by Simon Redman, on behalf of Albert Vaca Cintora.
Committed on 22/01/2023 at 20:35.
Pushed by sredman into branch 'release/22.12'.

Fix ssh authentication using pubkey on recent openssh versions


(cherry picked from commit 204207f2e66e87e7696ff1c98d70ce41b3e2d396)

M  +1    -0    plugins/sftp/mounter.cpp

https://invent.kde.org/network/kdeconnect-kde/commit/a7c17468f0bf16e4ed87c093dac0b77749c61d50

From the comments above, the root cause of the issue is in the KDE Connect Android app which bundles an obsolete version of a library, sshd-core 0.14.0, which in turn offers only one insecure signature algorithm -- "ssh-rsa". Many desktop environments depend on OpenSSH, which has (2 years ago) since dropped default support for "ssh-rsa" -- thus, desktop apps (like KDEConnect-Desktop and GSConnect) will fail to establish SSH/SFTP sessions with KDE Connect Android.

The current workaround has been to quietly enable the use of "ssh-rsa" in the KDE Connect Desktop app: https://invent.kde.org/network/kdeconnect-kde/commit/204207f2e66e87e7696ff1c98d70ce41b3e2d396

But this is problematic:

* It obviously enables a known insecure algorithm, as mentioned earlier. Personally, I don't consider this a huge deal, given the tradeoff is to greatly increase user-coverage, for the meantime till ssh-rsa recedes into history. The real problem is ...

* There seem to be a few separate desktop apps which implement the KDEConnect protocol, whereas there is only one KDEConnect Android app of note. **Not all desktop apps will have the same easy control over SSH config as KDEConnect Desktop**, thus they cannot enable "ssh-rsa" at will -- GSConnect, for instance. 

So this issue should ideally be fixed in KDEConnect Android, not just because it is the source of the issue, but also because the alternative workaround is not feasibly implementable in all desktop apps.

Following that -- Why does KDEConnect Android still bundle an obsolete sshd-core (0.14.0)? 

The reason given so far has been backward-compatibility with older Android versions, specifically Android 7 and below. This is a relevant commit that gives a bit of detail -- https://invent.kde.org/network/kdeconnect-android/-/commit/ef3fd68f7378398273cb476581bc4f28c6b89515

However, I think this decision should be re-evaluated:

* Android 7 was first released 7 years ago, and its final update was in 2019. What is the source of the requirement to support Android <=7? Is this really still required, especially to the detriment of security? 

* If it is, then is there a way to achieve that backward compatibility, without sacrificing security or usability with newer phones/desktops?

For instance, a comment in the above commit says (in the removed lines) that newer versions of sshd-core require the NIO package, which is only available in Android 8+. It sounds like this is the main reason KDE-Connect Android isn't using newer sshd-core.

However, that commit also says (in the newly added lines), that adding mina-core somehow makes sshd-core work **without requiring NIO** any longer. So far, this combination seems to have been tested with only sshd-core 0.14.0 -- but perhaps this workaround should also work for newer sshd-core as well, latest being 2.9.2. https://mvnrepository.com/artifact/org.apache.sshd/sshd-core/2.9.2.

If that is the case, then it should now be possible to upgrade the sshd-core for all Android, once and for all.

Any news on that case?

works for me now. I assume android app and kde got updated several times already

No, as far as I can tell, the situation is still unchanged -- sshd-core is still stuck at the obsolete version 0.14.0, carrying only "ssh-rsa" support: https://invent.kde.org/network/kdeconnect-android/-/blob/master/build.gradle. 

Any desktop apps that don't/can't enable support for this algorithm, will fail to establish SFTP/mount sessions with the Android app.

As mentioned earlier, we need to get the sshd-core version bumped up to the most recent as possible (likely 2.9.2 or greater) and confirm that it resolves this standing issue of SSH negotiation, while retaining support for Android <= 7 if relevant and possible.

Is the KDE connect widget failing for you? I don't see in my ssh configuration `ssh-rsa` enabled, yet kde connect is working. Maybe it enables it under the hood and it is much better not to.

I'm just trying to understand whether the widget fails or you are concerned about security (which is legit) and compatibility with other apps.

SSH-RSA was enabled here in the KDE-Connect desktop app, as a work-around for this issue: https://invent.kde.org/network/kdeconnect-kde/-/commit/204207f2e66e87e7696ff1c98d70ce41b3e2d396

I'm using GSConnect on GNOME, which lacks the APIs to make similar changes, and so is presently unable to SFTP with the Android app. There are other such desktop apps that support the KDE Connect protocol, as mentioned here: https://userbase.kde.org/KDEConnect

The security aspect is also a concern, even if a lesser one.

The security concern should not be lesser IMO. The protocol was disabled for a reason. I just wanted clarification. Enabling the protocol was a good quick-fix measure. But it is unacceptable in the long term. I wonder if maintainer can comment on how hard would a proper update of ssh server be.

Any progress towards a proper fix for this?  This completely breaks file transfers when using GSConnect on any somewhat-modern distro.  IMHO it's time to drop Android <=7 support if no easy workaround to keep it supported is found.  I'm quite confident the number of GSConnect users vastly outweighs the number of Android <= 7 users.  For flagship phones, the Samsung Galaxy S7, first released in March 2016, runs Android 8.  For budget devices, the Moto G5 series (2017) runs Android 8.  You'd have to go back to 2015 flagship phones or 2016 budget phones to find stuff on Android <=7.

I briefly looked at upgrading kdeconnect-android to more recent releases of the Apache MINA sshd libraries, not too long ago. Purely to satisfy my own curiosity.

The issue I hit (aside from my relative lack of familiarity with Java) was, the library has evolved so much that vast chunks of the APIs kdeconnect-android uses just don't exist anymore. MINA sshd 0.14.0 was the last release before 1.0.0, and neither 1.0.0 nor anything later is fully compatible with the 0.x series. The farther forward you go, the more it diverges from 0.14.0.

Since the 0.14.0 APIs are mostly long-gone by now, upgrading to a recent-ish release would likely require a rewrite of kdeconnect-android's ssh functionality on top of all-new-all-different 2.x APIs. (Rewriting against 1.x seems like it would just be a foolish half-measure, since the 1.x releases are already obsoleted by 2.x.) The code currently in kde-connect, and the code that it would need in order to work with 2.x, are so far apart they may not even be recognizable as providing the same functionality.

[1]: https://github.com/apache/mina-sshd/blob/master/CHANGES.md

If I'm not mistaken this should be fixed in the Android app version 1.29.0. However, the fix only applies to new installs, so if you have an existing version of the Android app installed you will have to use "Clear Data" in the app settings (or uninstall & reinstall it). Note that you will have to redo the pairing and configuration.

Please confirm if this works / doesn't.

(In reply to Albert Vaca from comment #35)
> If I'm not mistaken this should be fixed in the Android app version 1.29.0.
> However, the fix only applies to new installs, so if you have an existing
> version of the Android app installed you will have to use "Clear Data" in
> the app settings (or uninstall & reinstall it). Note that you will have to
> redo the pairing and configuration.
> 
> Please confirm if this works / doesn't.

I gave it a quick try. I unpaired my PC and Phone, I de-installed KDEConnect on the Phone, I repaired and tried to mount the phone, but sadly it failed. However I fail to obtain any kind of debug log from gsconnect. Can anybody try/confirm with real KDEConnect?

I cleared KDE Connect settings on my phone, and it generated an ECDSA key instead of RSA, so option HostKeyAlgorithms=+ssh-dss,ssh-rsa is no longer needed, but that was bug #351725. This one is about option PubkeyAcceptedKeyTypes=+ssh-rsa, and that's still required, otherwise the server won't accept RSA key generated by the Plasma app:

debug1: Will attempt key: /home/8an/.config/kdeconnect/privateKey.pem  explicit
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: password,keyboard-interactive,publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/8an/.config/kdeconnect/privateKey.pem
sign_and_send_pubkey: no mutual signature supported

It happens because the server still doesn't support RSA authentication with SHA-256, only SHA-1:
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: ecdh-sha2-nistp384,diffie-hellman-group14-sha1

Thanks for the insight, Lukáš!

This change might do the trick: https://invent.kde.org/network/kdeconnect-android/-/commit/4f44aef5f8bee8603d08cab18decae70f618faa4

Can you please give it a test? You should be able to download a debug APK from this link once the build job succeeds: https://invent.kde.org/network/kdeconnect-android/-/jobs/1220040/artifacts/browse/build/outputs/apk/debug/

(Note that if you have a non-debug version of the app you will have to uninstall it before you can install this)

I tried that, but it made no difference. It seems that key exchange algorithms are something different, what's missing is signature algorithm "rsa-sha2-256" and some protocol extension. These additional lines are in SSH output when I connect to a Linux server using my RSA key:

debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,ssh-rsa>

The extension should be supported in MINA SSHD:
https://issues.apache.org/jira/browse/SSHD-895

I added rsa-sha2-256 but I think it still didn't fix the issue: https://invent.kde.org/network/kdeconnect-android/-/merge_requests/401

I'm out of ideas, the only alternative is to upgrade the version of mina-sshd that we use (which doesn't seem easy).

Unfortunately you're right, it didn't help, it really seems the RFC8308 extension is needed, which requires MINA SSHD version 2.3.0 or later.

Do we really need to use RSA for client authentication? Or could the KDE Connect client (Linux app) also switch to an ECDSA key?
The error "no mutual signature algorithm" does not appear when I try to send my ECDSA public key:

debug1: Next authentication method: publickey
debug1: Offering public key: id_rsa RSA SHA256:En18wk81oylB2/tXALRVR665pvuP3XHZOVUdTWnZ06w agent
debug1: send_pubkey_test: no mutual signature algorithm
debug1: Offering public key: id_ecdsa ECDSA SHA256:JL1U9qfHt51GmmiT41JB9WDRDP4cWWA8H/boCR08qCU explicit
debug2: we sent a publickey packet, wait for reply

I've modified GSConnect to use ECDSA and it doesn't seem to fix the issue. Here's my change:
https://github.com/albertvaka/gnome-shell-extension-gsconnect/compare/main...ecdsa-keys

After applying this change I deleted ~/.config/gsconnect to force it to recreate a key.

(In reply to Albert Vaca from comment #43)
> I've modified GSConnect to use ECDSA and it doesn't seem to fix the issue.
> Here's my change:
> https://github.com/albertvaka/gnome-shell-extension-gsconnect/compare/main...
> ecdsa-keys
> 
> After applying this change I deleted ~/.config/gsconnect to force it to
> recreate a key.

I was under the impression the problem was the key exchange algorithm, which is why `HostKeyAlgorithms +ssh-rsa`  fixed it in the past. This is all I have in my `~/.ssh/config` and SFTP works fine for me.

I reinstalled KDE connect 1.29.0 from F-Droid today on two of my devices (after un-pairing and clearing all application data). And mounting seems to work fine now with GSConnect 55 (55+108+gea56bcfe-1, which should be the head of the master branch at the time of writing). (OpenSSH 9.5p1) On both devices (Android 10 and 13) the SSH connection is established, and the appropriate directory under /run/user/$UID/gvfs/ appears. I have never had any workarounds in my local SSH configuration, and I also haven't touched ~/.config/gsconnect/

As a sidenote, with the Android 13 device I'm getting "Permission denied" errors when I want to even just list the contents (the "access all files" permission is given).

We can probably disregard tests done with the stable version in the Store. For now, we're focused on the latest builds, containing tentative fixes in both KDEConnect-Android and GSConnect.

@Albert, do you have any logs (both KDEConnect and GSConnect) and Wireshark traces of your recent failures (using *all* the changes you've made so far)? With these, we should be able to determine at what precise stage the key negotiation fails, and see where the applications still fall short.

(FYI, you can decrypt GSConnect's TLS traffic in Wireshark using steps explained here: https://github.com/GSConnect/gnome-shell-extension-gsconnect/discussions/1548#discussioncomment-4682656 and https://github.com/GSConnect/gnome-shell-extension-gsconnect/discussions/1548#discussioncomment-5273879)

(In reply to Brian from comment #46)
> We can probably disregard tests done with the stable version in the Store.
> For now, we're focused on the latest builds, containing tentative fixes in
> both KDEConnect-Android and GSConnect.
> 
> @Albert, do you have any logs (both KDEConnect and GSConnect) and Wireshark
> traces of your recent failures (using *all* the changes you've made so far)?
> With these, we should be able to determine at what precise stage the key
> negotiation fails, and see where the applications still fall short.
> 
> (FYI, you can decrypt GSConnect's TLS traffic in Wireshark using steps
> explained here:
> https://github.com/GSConnect/gnome-shell-extension-gsconnect/discussions/
> 1548#discussioncomment-4682656 and
> https://github.com/GSConnect/gnome-shell-extension-gsconnect/discussions/
> 1548#discussioncomment-5273879)

I installed kde connect master via android builder on my phone. I  installed the gsconnect from Alberts repo https://github.com/albertvaka/gnome-shell-extension-gsconnect/compare/main...ecdsa-keys and obtained a dump with: ´sudo tcpdump -v -i wlp3s0 -w kde_connect_dump.pcap dst 192.168.11.95´ with the local ip address of my phone. During capturing I repaired my phone and clicked the mount button of kde-connect. I then opened nautilus and tried to browse files on the phone.  This resulted in a permission denied error. I then stopped the capture. You can download the capture here: https://nextcloud.deiseroth.de/s/GHH4sg5JMiXRyar

"Permission denied" sounds a lot like a different issue I've had before -- https://bugs.kde.org/show_bug.cgi?id=432368

To fix it, you just need to set the Custom Destination in KDE-C Android to your Downloads folder, navigating there. (Repeat this even if the path looks already set).

Also to capture useful traces, you'll need to follow the steps at the first link I sent earlier to configure Wireshark to decrypt the TLS traffic between GSConnect and KDE-C Android. The steps are fairly straightforward -- one-liner modifying GSConnect's daemon.js to add an SSLKEYLOGFILE path, pointing Wireshark to that same path, reboot, and begin logging with Wireshark. (I'm not sure if/how the decryption can be done with a tcpdump cmdline.) Any saved traces should now contain the decrypted traffic -- a decrypted packet should look like the image at that first link.

Your phone's live "adb logcat" would also be very useful to see app-level errors. If you like, you can limit both traces and logcat to just the rough time period when you run the tests.

(In reply to Brian from comment #48)
> (I'm not sure if/how the decryption can be done with a tcpdump cmdline.) 
> Any saved traces should now contain the decrypted traffic -- a decrypted packet should look like the image at that first link.

The decryption happens when the packets are examined, not when they're captured. Loading a capture log containing encrypted traffic into WireShark, then decrypting it, should be no different from decrypting packets that were captured live _by_WireShark. (You do need the key dump created by having SSLKEYLOGFILE set in the environment at the time of capture, though.)
 
> Your phone's live "adb logcat" would also be very useful to see app-level
> errors. If you like, you can limit both traces and logcat to just the rough
> time period when you run the tests.

You'd think so, but... unlikely, in my experience. The SFTP stuff, in particular, has next to zero logging on the Android side, AFAICT.

(In reply to FeRD (Frank Dana) from comment #49)
> The SFTP stuff, in
> particular, has next to zero logging on the Android side, AFAICT.

(That wasn't meant as any sort of slight against kdeconnect-android, it's just a reality of the MINA SSH backend. The GSConnect side of things is even worse on that front, since it delegates SFTP operations to GVfs... which means we have basically zero control, and even less visibility into what's going on.)

I have same problem in KDE neon 5.27, Is there a solution?

```
Nov 21 18:08:18 User kdeconnectd[2382]: QDBusAbstractAdaptor: Cannot relay signal SftpPlugin::packetReceived(NetworkPacket): Unregistered input type in parameter list: NetworkPacket
Nov 21 18:08:18 User kdeconnectd[55031]: /usr/bin/fusermount: entry for /run/user/1000/254223ae_f376_48bc_bacd_c5535f54a9d8 not found in /etc/mtab
Nov 21 18:08:18 User dolphin[54983]: MEGASYNCOVERLAYPLUGIN: getOverlays </run/user/1000/254223ae_f376_48bc_bacd_c5535f54a9d8/storage/emulated/0>: 9
Nov 21 18:08:18 User plasmashell[54419]: Could not find the Plasmoid for Plasma::FrameSvgItem(0x55b7ef6d88e0) QQmlContext(0x55b7eabe9570) QUrl("file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/global/Globals.qml")
Nov 21 18:08:18 User plasmashell[54419]: Could not find the Plasmoid for Plasma::FrameSvgItem(0x55b7ef6d88e0) QQmlContext(0x55b7eabe9570) QUrl("file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/global/Globals.qml")
Nov 21 18:08:18 User kdeconnectd[2382]: QDBusAbstractAdaptor: Cannot relay signal SftpPlugin::packetReceived(NetworkPacket): Unregistered input type in parameter list: NetworkPacket
Nov 21 18:08:18 User kdeconnectd[55036]: /usr/bin/fusermount: entry for /run/user/1000/254223ae_f376_48bc_bacd_c5535f54a9d8 not found in /etc/mtab
Nov 21 18:08:20 User dolphin[54983]: MEGASYNCOVERLAYPLUGIN: getOverlays </run/user/1000/254223ae_f376_48bc_bacd_c5535f54a9d8/storage/emulated/0>: 9
```

(In reply to Albert Vaca from comment #43)
> I've modified GSConnect to use ECDSA and it doesn't seem to fix the issue.
> Here's my change:
> https://github.com/albertvaka/gnome-shell-extension-gsconnect/compare/main...
> ecdsa-keys
> 
> After applying this change I deleted ~/.config/gsconnect to force it to
> recreate a key.

I tried to replace RSA certficate in KDE Connect with ECDSA, but it didn't work either. I used this command to generate it:

openssl req -new -x509 -set_serial 10 -sha512 -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -nodes -keyout privateKey.pem -days 3650 -out certificate.pem -subj "/CN=_3e4db661_39a2_4d04_bd59_e6c962f356a2_/O=KDE/OU=Kde connect"

Unfortunately, kdeconnectd refuses the new private key:
kdeconnect.core: Private key from "/home/8an/.config/kdeconnect/privateKey.pem" is not valid

came across this issue while googling, this works for me: `sftp -i ~/.config/gsconnect/private.pem -P 1740 -o 'PubkeyAcceptedKeyTypes +ssh-rsa' gsconnect@pyriform:/storage/emulated/0`