Reworking KSSHAskPass

KDE has a little utility called ksshaskpass that is invoked by SSH to prompt the user for credentials. It can then store them in KDE Wallet so you don’t have to type them again next time. The other day I had to set up an elaborate SSH configuration with jump hosts and what not and found that it actually couldn’t handle some of the prompts I encountered along the way.

The way an “SSH ask pass” program works is relatively simple: You point the SSH_ASKPASS environment variable to it and whenever SSH needs credentials, it runs that program, passing the prompt (e.g. “user@host’s password:”) as command-line argument. The program brings up a dialog and/or reads the corresponding password from a database and prints it to stdout. SSH then uses it to authenticate.

Unfortunately, the prompt is just a string, we don’t get any metadata for it. The only additional information we might get is the SSH_ASKPASS_PROMPT variable set to “confirm” (bring up a confirmation dialog with no input field) or “none” (just show a dialog while it’s waiting for you to press a button on your FIDO dongle). Anything else is just an opaque string.

In order to provide a good user experience we want to know what kind of input it is expecting and what the context of it is: is it asking for a user name (show input) or a password (show bullets)? What is the user and host name so we can store it in KDE Wallet properly? Should we allow storing those credentials in the first place? Maybe it is asking us to confirm the authenticity of the host we’re trying to connect to, and so on.

Before touching any of the existing regular expressions, I split the relevant code into a separate library so I could write unit tests for it. This ensures that I don’t break one use case by fixing or adding another. It’s quite easy to accidentally write a regular expression that’s too greedy.

The first issue was the lack of support for the password prompt coming from PAM. Normally, SSH will ask for the password like “user@host’s password:” but a connection might instead require server-side authentication where the prompt is coming from the server directly, most likely from PAM, which then looks like “(user@host) Password:”. When I failed to reproduce the issue on my laptop running the latest git master build, I noticed that someone had recently added this specific use case. My tests actually uncovered a regression in this change (didn’t I just say it’s easy to mess up a regular expression?) which I fixed. That reinforced my decision to write some unit tests first. :-)

Next, I noticed a few minor differences between the SSH versions used in Kubuntu 24.04 and 26.04, things like a period here, a colon there, so I added them as well. It now also supports the prompts issued by ssh-keygen, such as “Enter passphrase (empty for no passphrase):”.

The biggest usability problem, however, was that when you chose to remember the password but you had a typo or it just changed in the meantime, you were effectively locked out. SSH would ask for the password and ksshaskpass dutifully replied with the wrong answer. The only way to get around this was to open KeepSecret (the successor to KWalletManager) and delete the corresponding entry. Yikes!

As I said before, there’s no metadata, we don’t know whether it’s a first time prompt or asking again after a failure. I therefore made ksshaskpass remember the last prompt string and PID of the parent (likely SSH) process. When the same process asked for the same thing again, we now consider it failed, and bring up the dialog. If you have a better idea or I might have missed something, please tell me! It now also lets you remove stored credentials by unchecking the “Remember” check box. It also no longer shows that checkbox when we failed to identify the prompt string – the checkbox never worked in this case, so it was pointless to show it.

I then went through Bugzilla and was able to resolve a good chunk of the reports in there. The most high profile one was the fact that it used a password dialog when asking for a user name, i.e. the user name was not shown. The reason it used that dialog is to offer the “Remember” checkbox. However, hiding a user name is not very nice, is it? The common password dialog we use isn’t really designed to ask just for a user name without a password, so I instead implemented a custom dialog mimicking the look of the regular dialog.

As often, it’s the little things, so I hope you will enjoy a better SSH experience in Plasma very soon. A few of the bug fixes I mentioned above have already been released as part of Plasma 6.7 with the larger changes expected to land in Plasma 6.8.