On 07.01.2023 12:41, Michael Ströder wrote:
On 1/7/23 07:23, Andrei Borzenkov wrote:
On 07.01.2023 02:13, Michael Ströder wrote:
On 1/6/23 23:46, Martin Wilck wrote:
On Fri, 2023-01-06 at 21:24 +0100, Michael Ströder wrote:
how can I disable this /etc/ssh/ssh_config.d/ madness without rebuilding the package without openssh-8.4p1-ssh_config_d.patch? Th elatest openssh-package update has this change which breaks all my SSH client configs:
This is hard to answer without knowing how your client configs are implemented.
The idea of the patch below is that you put your local config in /etc/ssh_config.d, where they will override the defaults stored in /usr/etc/ssh_config.d.
Iundertand the basic idea bu it won't solve any problem for me and just silently breaks working setups.
* Wed Jul 06 2022 Adam Majer <adam.majer@suse.de> - openssh-8.4p1-ssh_config_d.patch: admin overrides should take priority (listed first) over package defaults
That makes sense to me. Please explain why you call it "madness".
Because I had a hard time today to find out why the most *basic* SSH config items like known_hostschecking and key-based-authc did not work anymore at all-!ssh -vvvhave me the hint thta it look for files which will never exist on my laptop.
This breaking change should not have been publishshed without being announced more clearly here. I remember the discussion about similar issues with sshd_config breakage couple of months ago.
It completel
Your still forgot to explain what was broken in your case and why.
Every SSH access was broken bescause ssh now insists on finding iles /etc/ssh/ssh_config.d/*.conf which do no exist on my laptop
And? Where is the problem? user@uefi:~> ssh -v bor@10.0.2.2 OpenSSH_8.9p1, OpenSSL 1.1.1s 1 Nov 2022 debug1: Reading configuration data /usr/etc/ssh/ssh_config debug1: /usr/etc/ssh/ssh_config line 24: include /etc/ssh/ssh_config.d/*.conf matched no files debug1: /usr/etc/ssh/ssh_config line 25: include /usr/etc/ssh/ssh_config.d/*.conf matched no files debug1: /usr/etc/ssh/ssh_config line 27: Applying options for * debug1: Connecting to 10.0.2.2 [10.0.2.2] port 22. ... debug1: Trying private key: /home/user/.ssh/id_dsa debug1: Next authentication method: password bor@10.0.2.2's password:
ssh fails completely to even use keys loaded into ssg-agnet because it no insissts to find the user key files in /etc/ssh/ssh_config.d!
You still did not provide a single line to prove your claim.
this stuff is seriously broken and completely sucks! this change causes nothing than grief without any giving any real benefit on my single-user laptop.
It is impossible to fix problem when all we know is some expletives.