KDE Dolphin fails SFTP connection when any wildcard is used in the ~/.ssh/config or other related config file.

Dolphin is the KDE Plasma 5 file manager. It is pretty good at what it does. Rarely do you encounter some issue that gives you pause. The issue that I’m talk about came after encountering a problem and then researching it. Others have had the problem and have reported it only to have the KDE Plasma developers respond indicating that this is an ftp ioslave issue rather than taking responsibility and fixing it. I can understand that the problem exists. What is at issue here, for me, is that they begged off and wouldn’t discuss nor address it with the public. I’ve encountered the problem, and so has a buddy of mine. He reported it to me first and that’s how I knew that there’s a partial work-around, albeit an unsatisfactory long term one.

In Dolphin in the bar where you can put in the path that you want to go to (near the top of the window) you would type in sftp://<host>, i.e., sftp://server. In this example server is a host listed/configured is in your ssh config files.

The initial problem goes like this. If you use a wildcard in any of your config files Dolphin, when using the sftp protocol, as you try to connect indicates that it can’t connect to the hostname.

Here’s a bit of an explanation of how my config is set up.

The normal .ssh folder off my home folder exists. ~/.ssh

The normal config file in that folder exists. ~/.ssh/config

In the ~/.ssh I also have a folder called conf.d (which I created) ~/.ssh/conf.d/

In that folder are various <filename>.ssh files.

NOTE: The filename extension is something that I choose, and it has no bearing on the issue. Why do I name my files with the ssh extension? I do this because some programs when they save the (text) file will create a backup with ~ appended to the end (<filename>~) and if you used a wildcard to include the folder you’ll get duplicates read (the new edited good filename and the old unedited backup version). Doing a ssh -v <config host name> will show you that it’s reading the config files including the backup version. If you were editing the file to correct a show stopper error that backup will still have that show stopper error, and even though you think you fixed it because that backup file is also read by ssh it’ll appear like you still have the error. It’s best to just include the files you want hence that’s why I gave them the “.ssh” filename extension.

In each of the <filename>.ssh files are hosts with the typical layout.

host <host’s name>

user <account name of the host>

hostname <IP Address>

Port <number>

In the ~/.ssh/config file is an include statement that includes ~/.ssh/conf.d/*.ssh

This tells ssh to load all the files with that extension when trying to connect to a host.

This is also where the trouble begins. That “include” statement with the wildcard character causes Dolphin when it uses the sftp protocol to complain that it can’t connect to the hostname.

If you move a host out of a file in the ~/.ssh/conf.d/<filename>.ssh and add it to the ~/.ssh/config file as a host entry it will connect.

All other ssh related programs work with all of these config files with wildcard — e.g., ssh at the command line, rsync, sshfs, ansible, and sftp at the command line all work with this. It is only Dolphin (so far) that fails.

Again, I’ve read posts on where someone complained about the issue and all that happened was the developers came on and said to do a fuse mount instead. Of course, that’s a real shitty way of explaining it. You wouldn’t say “do a fuse mount”. You’d say mount it in your /etc/fstab file so you’ll have it on boot up.

No matter how it is said, it is wrong. In my case, I have so many hosts that I have to use this sort of organization just so I don’t have to sift through long long list of hosts to make adjustments, etc. I could never be convinced to go to the command line, execute the mount command then go back into dolphin just to make a connection where I can use the GUI file manager to manage the files.

As far as I know the KDE Plasma guys are not putting the work into making this work properly. If you’ve ever filed bug reports with anyone you have to suffer through the red tape. First they claim it is a duplicate, then they claim they can’t reproduce it, and then they try to close it. And then someone says that they can reproduce it. Then they flag it as reproducible and thus open. Then you hear nothing about it for months and months. There are times when for years you get emails mostly from other users indicating that they can reproduce it. Then maybe you might get something years later where the problem is allegedly solved only it isn’t, or it is solved only to be broken on the next release.

Well, that’s sort of a rant.