Created attachment 178559 [details] Screenshot showing that the ssh key's password is saved in KWallet, but Dolphin still prompts for it with no option to remember it. SUMMARY Using Dolphin to connect to a remote server using the "sftp://" protocol when an ed25519 ssh key is required results in a password entry dialogue with no way to "remember" the password for subsequent connections after logout or reboot. Subsequent connections in the current session are unimpeded once password is entered though. The "fish://" protocol works as expected, the password dialogue has a checkbox to remember the password and add it to KWallet, however this is not a substitute as, I hear, "fish://" is not as secure as "sftp://" and opening remote directories that have a large number of files results in Dolphin taking a long time to index the directory before any files are displayed. I believe this may be due to a difference in how each protocol accessed the remote server but I'm not completely sure. Something to note. This issue was not present in Plasma 5. Remote connections using "sftp://" correctly used the ssh key's password that was saved in KWallet. The issue only began with the update to Plasma 6. I've been using XFCE because of this, but figured since I really want to move to Wayland I'd really like to see this issue resolved. It's the one critical issue I have that's keeping me from using Plasma. STEPS TO REPRODUCE 1. Create a new ssh keypair with the type "ed25519", secure it with a password and then copy it to the remote server (if necessary) 2. Add the ssh key pair using ssh-askpass, then when entering the password check the box to "remember" the password so it is saved in KWallet 3. Connect to the remote server with Dolphin using "sftp://", observe a password entry dialogue box with no way to remember the password 4. Confirm "fish://" connects to the same remote server without prompting for any password once it's added to KWallet OBSERVED RESULT "sftp://" connection in Dolphin results in a password prompt the first time a connection is made in a new session. There is no option to remember the password or save it in KWallet EXPECTED RESULT KWallet should be used as intended to allow automatic password entry. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.3.1 KDE Frameworks Version: 6.11.0 Qt Version: 6.8.2 Kernel Version: 6.13.2-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 4 × 12th Gen Intel® Core™ i7-12700KF Memory: 7.7 GiB of RAM Graphics Processor: SVGA3D; build: RELEASE; LLVM; ADDITIONAL INFORMATION
Sounds like a libssh bug. Can you grab a dolphin log please https://community.kde.org/Guidelines_and_HOWTOs/Debugging/Debugging_IOSlaves/Debugging_kio_sftp#Logging
(In reply to Harald Sitter from comment #1) > Sounds like a libssh bug. Can you grab a dolphin log please > https://community.kde.org/Guidelines_and_HOWTOs/Debugging/Debugging_IOSlaves/ > Debugging_kio_sftp#Logging Sure thing. Since the outputs tend to be quite lengthy I've uploaded text files as attachments. Not exactly sure how to add collapsible code blocks here.
Created attachment 178595 [details] Output using fish://
Created attachment 178596 [details] Output using sftp://
Created attachment 178597 [details] Output using sftp:// with verbosity 10 for libssh
Changing this back to "REPORTED" as the desired info has been provided.
I don't have any personal insight on this, but I wonder if this is possibly related to https://bugs.kde.org/show_bug.cgi?id=451755 ?
(In reply to John Kizer from comment #7) > I don't have any personal insight on this, but I wonder if this is possibly > related to https://bugs.kde.org/show_bug.cgi?id=451755 ? I don't think so. The user in that report states they are being asked for standard user credentials as if kio, or the sftp protocol, is not using the identity file while the fish protocol is. In my case the identity file is being used, it's just not using the saved passphrase in kwallet for sftp, but it is for fish. Almost like the sftp protocol isn't integrating with ksshaskpass at all.
(In reply to Chris Winters from comment #8) > (In reply to John Kizer from comment #7) > > I don't have any personal insight on this, but I wonder if this is possibly > > related to https://bugs.kde.org/show_bug.cgi?id=451755 ? > > I don't think so. The user in that report states they are being asked for > standard user credentials as if kio, or the sftp protocol, is not using the > identity file while the fish protocol is. In my case the identity file is > being used, it's just not using the saved passphrase in kwallet for sftp, > but it is for fish. Almost like the sftp protocol isn't integrating with > ksshaskpass at all. Just a small correction: Well, maybe it's integrating with ksshaskpass since it does use the right ssh key, but it's certainly not integrating with kwallet to automatically use the saved passphrase.
Have some updated info to share. Not sure how helpful it will be, but here it goes. I decided to spin up a couple VMs to test two different configurations to see if I can at least isolate where the issue might be occurring. Both VMs are Arch Linux so all packages should be up to date. 1) Arch Linux + Plasma + Dolphin + Dolphin Plugins + Kio (and all additional packages related to kio) + Gnome-Keyring (replacing KDE Wallet/ksshaskpass completely) This configuration prevents fish protocol from connecting, and the sftp protocol exhibits the same behaviour as described in the original report. SSH Key passphrases are not saved, and the user is asked to enter the passphrase when connecting to sftp via Dolphin. 2) Arch Linux + Plasma + Thunar (probably doesn't matter, any file gvfs enabled filed manager would do) + GVFS (and all additional packages related to GVFS) + KDE Wallet + ksshaskpass This configuration works as expected. On first connection to an sftp share the user is presented with a passphrase dialogue with the option to save the passphrase. Thunar (or gvfs) will then correctly fetch the saved passphrase on subsequent connection attempts, even in a new session (after a logout or a reboot). The issue therefore seems to be with KIO. I've read somewhere that KIO does not natively support org.freedesktop.secrets (libsecret) and perhaps this is where the issue is stemming from. There is a patch available that adds support so I'm going to set up a vanilla Plasma instance and add that patch to see the results. If it works, I'll use that as an acceptable workaround.