What exactly do you want to happen here?

(In reply to Harald Sitter from comment #1)
> What exactly do you want to happen here?

Assuming that there's an implicit understanding of what the problem with inquiry about expected resolution, I see the first step being someone with authority deciding how this long standing problem is supposed to be handled instead of just letting user experience suffer, and keeping around bug reports where the issue is clearly understood, there's just no plan to do anything about the problem.

Not necessarily an exhaustive list of possible decisions, but I can see one of the following paths being chosen:
- The whole problem is decided not to be on KDE, considering libssh issues not to be relevant here despite them impacting KDE user experience. In that case the relevant issues should be closed as not planned to be resolved here.
- Depending on libssh might be still desired, but it either gets forked so issues can be patched bypassing upstream issues, or part of the functionality like known_hosts handling gets replaced with code not using libssh.
- Deciding that libssh is not sufficient, so replacing it with another library or a new implementation (not really seeing this happening, but still a possibility).

Take this as more of a pushing for decision with possibly cleanup effort.
Ideally a task would be made outlining the chosen plan of resolving the problem, and all related bug reports could be closed as a duplicate of that. Even if there would be no fix any soon, it could at least centralize all the different bug reports into a larger "libssh limitations" topic, so users could be pointed there instead of letting each bug reporter individually discover looking at yet another manifestation of SSH config options just simply being ignored instead of KDE having some really weird bug.

In a project with a deep technology stack, it's common that issues manifesting to users are caused by problems at a lower level in the stack. Other common examples that I can think of include:
- Graphical glitches or multi-screen problems caused by graphics drivers
- Audio issues caused by PulseAudio/PipeWire
- Power management and battery life issues caused by the Linux kernel and its hardware platform drivers
- Network connection isues caused by NetworkManager
- Bluetooth connection issues caused Bluez


etc.

It would not feasible for KDE to take ownership of those parts of the stack by either forking them or assigning people to contribute to them; frankly we have trouble even maintaining our own code, due to its vast breadth and our limited resources. I wish this were different, but it's not.

Ultimately, resolving issues like these is the job of the system integrators. Their role is to take diverse pieces of software, jam them together, see what breaks, assign people to work permanently on problem-child upstream projects, fix bugs in a targeted manner, QA the result and polish it up, and then distribute it as a cohesive supported product--likely for money, because doing all of this is un-fun work that people generally only do when paid.

In the Linux world, historically our system integrators have been the software distributions--especially the ones that have commercial backing and deep pockets. Today the model seems like it's sort of dying, with the big players taking less interest in our world and neglecting critical issues for years, and a massive proliferation of micro-distros developed by 1-2 person teams that aren't sustainable and pass the buck for every issue below them. All of this makes sense when resources are highly constrained, as they are.

It's my opinion that those selling Linux-powered hardware need to step up to take the role of system integrator more seriously, by putting dedicated engineering effort into fixing problems at all levels of the stack. When you get all the software you ship for free, that's a business cost savings, which should free up funds for developing it. This work takes money, and they have it. Certainly more than KDE and most distros do.

Speaking personally, it's been my dream to see KDE itself become a hardware company and reinvest the revenue from selling devices into development not only on KDE software, but on the software we rely on. But at this point, it's just a dream.

---

If you'd like to take the initiative to better-categorize the upstream bug reports that affect users so that there's at least a record of what's damaging the UX, that seems like something actionable that could be done--by anyone! Since you expressed interest in it, I think it makes sense for you to give it a shot. The way this would work is as follows:
- Create a new metabug titled something like "Upstream libssh issues"
- Find all the bug reports we have that are ultimately caused by upstream libssh issues
- For each one, identify the upstream libssh bug report and put it in the URL field of the bug report, then close it as RESOLVED UPSTREAM and then mark it as a blocker for the metabug

That way, even though they're closed in our bu tracker, the bug reports will still be findable.

What do you think?