Why does OpenSSH not conform with XDG_CONFIG? Can there be alternatives?

https://lemmy.world/post/5482259

So the Arch Linux Wiki page you shared actually had a source, but the OpenSSH maintainers hid it because it got brigaded (if I had to guess, by this Hacker News post). Anyways, here’s the latest archive (I also edited the wiki to include it), it’s a BS reason: web.archive.org/web/…/show_bug.cgi?id=2050

Please support FreeDesktop.org XDG basedir specification for openssh

No.

OpenSSH (and it’s ancestor ssh-1.x) have a 17 year history of using ~/.ssh. This location is baked into innumerable users’ brains, millions of happily working configurations and countless tools.

Changing the location of our configuration would require a very strong justification and following a trend of desktop applications (of which OpenSSH is not) is not sufficient.

Please notice that backward compatibility can be preserved by continue to use ~/.ssh if it exits but using/creating XDG dirs if it is not exist.

So tools and users need to hunt in two places for configuration that has security ramifications? That makes it even less palatable…

As I see a new release, I wish OpenSSH would conform to the XDG base directory s... | Hacker News

They are not BS reasons, they are just reasons you don’t like. The OpenBSD team - those behind OpenSSH - are very conservative to the point of being almost reactionary, and that’s great for the kind of software they make. OpenBSD defines itself as “boring”, in a good way.

Coming from a Linux world it may seem weird, as around Linux innovation is praised more than improvement so we end up with a bunch of shiny new software with a lot of growing pains, while BSDs tend to be avantgarde on some technical aspects but at the same time very wary of novelty. OpenBSD in particular takes this to the next level with most of development still happening on CVS and many other quirks that would baffle most Linux users.

To each their own. Personally when it’s security stuff I like it boring. I’ve been using openssh since version 2.x and the muscle memory built 20 years ago is still serving me.

It's not BS. It's correct.

You're proposing an obscene security hole for no benefit.

if they switch it will cause a lot of trouble at first. it’s used everywhere. some management software has .ssh/ hardcoded.

they can’t be automatically backwards compatible, because it would mean an alternate location for a authorized_key file etc, which is dangerous. so, hosts updating need to be checked and migrated. some people will be locked out.

however, after the initial chaos it should be fine.

Well yes, after breaking countless tools with repercussions possibly in the decade range, punching security holes in systems that were hardened with certain expectations (my head aches at the amount of “lol the admin didn’t restrict .config/ssh”) - after all this havoc we will have a native bsd server software that finally complies with a Linux desktop standard. I don’t see downsides to this.
it will secure a lot of jobs 😆
Other than declutter and conformity (which are good goals in general) what else are you getting here? What would you be able to do tomorrow if they suddenly supported XDG_CONFIG that the general population would benefit from?
Honestly, I do not have any strong points, because XDG makes the home directory look clean, but I imagine alternative SSH libraries offer this freedom of choice? Maybe the Guille-SSH? But then again, it’s just one extra folder on my personal device, so I don’t really have a lot of complaints, and I don’t really want to use a project that is not tried and tested, at least for now.
ssh predates the specification, exists somewhat independently of even the idea of a desktop (not common to see xdg env variables like XDG_CONFIG in a headless environment, for example), and uses the homedir/.ssh directory on both the client and server side of a connection. I think it’s less to do with security and more to do with uniformity for something as important as ssh - ssh doesn’t need to change to use the xdg spec, and xdg doesn’t need to allot anything special for ssh when it’s already uniform across the unix spectrum

Because it comes from OpenBSD and OpenBSD doesn’t do xdg stuff.

It also predates the standard.

But you could ask the same of many other Unix utilities too.

XDG = X Desktop Group.

OpenSSH is neither an X client nor a desktop program.

More specifically, XDG is more related to Linux. It was the name of the freedesktop group. OpenSSH is more related to OpenBSD. However, none of that is strictly true - freedesktop/XDG isn’t just about desktop, XDG directories are not completely neglected by OpenBSD and OpenSSH isn’t used by just OpenBSD. dotfiles sprawling is a common problem - so OpenSSH should probably follow it as well.

XDG config was always a smooth brain idea, and any other outcome of this experiment was always ~impossible (of course some apps didn’t switch …)

Great job to X “fixing” what didn’t need fixing, and causing us to go from one unified system that made sense, to two. And now people don’t even want to use X anymore

Having a consistent base directory specification is a “smooth brain idea”? Alright, buddy, enjoy your config and cache files scattered around your user directories.
is $HOME not a consistent base path?

My “user directories”? You mean you have more than one $HOME with dotfiles in it?

It was never a problem to find user specific app data on unix. And XDG obviously didn’t solve it because solutions that require everyone to change their code are dumb. Case in point, this thread

My “user directories”? You mean you have more than one $HOME with dotfiles in it?

I meant directories under your $HOME.

The problem isn’t that finding files is difficult, but that a lack of specifications leads to inconsistencies and programs doing whatever they want under your home directory.

That worked fine for Unix because programs were designed to be simple. It doesn’t work today where you have programs that constantly save temporary files, caches, and data derived from user input.

You used to have to do all that stuff before too. Vim has had history, settings, caching, and plugins for ever. And it all used to sit in ~/.vim. Now it’s in ~/.config/vim. What’s the difference?

Consistency and separation.

If I need to clear out any caches or temporary files, I don’t need to dig around in a bunch of dot-directories to figure out what’s safe to delete and what’s a configuration file. I can wholesale rm -rf ~/.cache.

It’s also convenient for distro hopping or backing up files. If every program kept temporary and transient files in the same base directory, you would need filters for each of them. For anything conforming to XDG base directory specifications, different types of files are all under well-known directories.

More subjectively, I hold the opinion that my home directory is mine. Programs shouldn’t be littering the root of my user folder with their crap (looking at you, ~/go).

All in all, XDG base directories solve a problem that isn’t covered in any other specification. If POSIX defined a similar specification, such as having config files relegated to ~/.local/etc/some-program, I wouldn’t be here.

Shit y’know what, fair enough. I never had your particular needs, and I’d probably still have to double check a cache location in case the app didn’t comply, but I feel you
OpenSSH's server login component (the authorized_keys checking) can't properly respect XDG_CONFIG_HOME because it won't be set at the time it's reading the authorized_keys file. The user's home directory is stored in /etc/passwd but the XDG variables have a million different ways to set them, none of which are truly standardized. Best you could really do is hardcoding .config or the like, which you can do by changing the AuthorizedKeysFile in sshd_config.