Hi,
Server is setup with ssh passphrase free key and user password.
No problem using cli but Dolphin won’t auth (sftp).
I guess Dolphin assumes access after the first step (key) then discovers no access.
Any way to work around this?
It works to different server with user password only (popup).
I don’t want this server to have only password or only key.
Thanks.
You just need to setup an ssh config file in your home directory.
Create, or append this, to the file:
~/.ssh/config
Host myhost HostName example.com User myuser IdentityFile ~/.ssh/my_key(With your proper values.)
Or wait, am I reading you right?
That would be server or client side (guess client)?
And that would make the popup appear in Dolphin?
Edit: forgot to mention, via sftp.
Yes, but I’m still trying to figure out exactly what you mean. I’m guessing it still may be.
This thew me off.
It works once? Or not at all?
I thought there were client side keys involved, my bad. So this is just a standard default ssh server?
And this is what is happening?
scp works on the terminal, but not in Dolphin.It does not work at all.
The server requires key and the user’s password, a two step login.
It looks like Dolphin does not support those two steps, it’s either key or user’s password so i was wondering if there is some work around.
Oh, okay good.
Stick with plan A, an ~/ssh/config file.
I thought Plasma (and Dolphin) supported connecting this way? Can anyone comfirm?
I cleaned up to do it fresh.
Popup for trusting the key comes up but no popup for the user password so it fails to auth.
Any idea where would this be logged?
None the wiser,
journal:
dolphin kf.kio.core: "Authentication failed."
and
kioslave5 kf.kio.core: Deprecated: messageBox() called with null secondaryActionText arg. type: 3 text: "<html><p>The authenticity of host <i>ipaddress</i> cannot be established.</p>\n\n<p>The ssh-ed25519 key fingerprint is:\n\n<pre>bladibla</pre>Are you sure you want to continue connecting?</p></html>"
Will search some more.
Thanks.
Okay, that sounds like something is wrong.
We need logs. 
It’s all in your journalctl logs, just use journalctl -f to watch them live. (As you attempt this, for example.)
Or filter by warnings or worse since you have booted:
journalctl -b -p4
# or journalctl --boot --priority 4
The ssh key initialising is done on the client side.
Then the public key is added to the server user’s authorized_keys file using the ssh-copy-id command.
How did you do that ?
My current knowledge on how ssh work is that it is either key (the key can be with or without passphrase) or password.
If one want both key and passphrase - then one uses a password passphrase protected key.
The latter will cause a passphrase entry
For this to be working - you need to add your host to .ssh/config file as mentioned by @Molski in comment #2 and you will need to use the Host part of the entry - also known as nickname.
I maintain a server where I have no password - only a passphrase protected ssh key.
By configuring the server to accept only key + user password on login:
https://security.stackexchange.com/questions/17931/can-i-require-both-private-key-and-password-authentication-for-ssh-login
As you also mentioned but not consistently, to prevent confusion, it’s passphrase for the key and password for the user.
Here is one i found that describes it more clearly:
https://askubuntu.com/questions/1019999/key-based-ssh-login-that-requires-both-key-and-password
Nice - I didn’t know that - describing it as a two-factor authentication makes more sense.
But that is what one accomplish using a passphrase protected ssh key - so using the above with a passphrase protected ssh-key, would make it - a three-factor authentication?
It was around 2015/2016 that this server was setup (Ubuntu server), have not tried 3 step auth at that time.
Is easy enough to test i think.
But anyway, Dolphin seems not to support it.
It’s a little easier now, knowing that you meant “passphrase”, which is different than the ssh password.
A passphrase is used to encrypt and unlock your private key. Unlike an ssh password, it is not stored on the remote system. Instead, it protects the private key locally, and you must provide the passphrase to use that key.
There is an app that allows kwallet integration, so you can safely store things like ssh passphrases in memory.
It is an official package called:
pacman -Si ksshaskpass
Repository : extra
Name : ksshaskpass
Version : 6.6.3-1
Description : ssh-add helper that uses kwallet and kpassworddialog
Architecture : x86_64
URL : https://kde.org/plasma-desktop/
Licenses : GPL-2.0-or-later
Groups : plasma
Provides : x11-ssh-askpass
Depends On : gcc-libs glibc kcoreaddons ki18n kwidgetsaddons qt6-base qtkeychain-qt6
Optional Deps : None
Conflicts With : None
Replaces : None
Download Size : 36.28 KiB
Installed Size : 127.81 KiB
Packager : Antonio Rojas <arojas@archlinux.org>
Build Date : Wed 18 Mar 2026 07:23:43 AM
Validated By : MD5 Sum SHA-256 Sum Signature
I have not tested this, but it seems straight forward enough:
For future readers:
One can configure ssh server to require:
only a user password to login.
only a user key to login.
only a passphrase protected user key to login.
One can configure ssh server to require 1. and 2.
One can possibly configure ssh server to require 1. and 3., this one i never tested.
Dolphin suppurts only 1. or 2.
I may have skimmed a bit at first (to be fair, it was a confusing start), but I don’t think we’re on the same page yet.
The server has no way to know whether your private key is protected by a passphrase. This is only local.
You can make the server can require keys globally, or per user. But not by passphrase.
I cannot do this today. But I bet you I can get this working.
So we can all see that we can configure this to use a key and password.
So the only missing piece is prompting for (or unlocking) this key with the passphrase. Core Plasma is missing that component.
That’s where something like ksshaskpass comes in. It provides the UI/bridge to enter the passphrase.
This is still considered 2FA. 
Yes, you´re right. Passphrase is local so outside this case.
Correct in the head but the hands did not follow.
To test this I have altered my remote server setup
The server’s /etc/ssh/sshd_config configuration had this added
...
# Authentication:
AuthenticationMethods "publickey,password" "publickey,keyboard-interactive"
...
Then restart the service systemctl restart sshd
When you connect using dolphin
Create an entry in your ~/.ssh/config to use the correct ssh key (you cannot provide the key as part of the connection string in dolphin)
Host server2
hostname some.domain.tld
port 33333
identityfile ~/.ssh/server2.key
user nix
Connecting with dolphin - make sure you supply the username as part of the connection string sftp://nix@server2 - this will open a password dialog with the username preset - all you have to do is provide the password.
Thanks for the effort.
As written before, from the command line it all works, ssh and sftp (as it does for the past 10 years or so) but not for Dolpin.
Will come back to this at a later date.
Thanks so far.