4disable using /etc/ssh/ssh_config.d/
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: * 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
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.
* 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". Martin
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
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.
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 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! 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. ciao, michael.
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.
On 1/7/23 12:32, Andrei Borzenkov wrote:
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?
Are you kidding or trolling or what? Do openSUSE devs all expect that all users here to split their $HOMe/.ssh/config into config snsippets just to satisfy wthis insane config parsing semantics? This
Am 07.01.23 um 13:25 schrieb Michael Ströder:
Are you kidding or trolling or what? Do openSUSE devs all expect that all users here to split their $HOMe/.ssh/config into config snsippets just to satisfy wthis insane config parsing semantics?
This
I suggest you write up a bug report at bugzilla.opensuse.org and use coherent sentences. This thread reads like a bar brawl. - Ben
W dniu 7.01.2023 o 13:25, Michael Ströder pisze:
On 1/7/23 12:32, Andrei Borzenkov wrote:
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?
Are you kidding or trolling or what? Do openSUSE devs all expect that all users here to split their $HOMe/.ssh/config into config snsippets just to satisfy wthis insane config parsing semantics?
This
/etc/ssh/ssh_config.d/*.conf is independent from $HOME/.ssh/config. Users should not need to put anything into /etc/ssh/ssh_config.d. The change in openSUSE packaging allows administrators to avoid editing /etc/ssh/ssh_config and instead put their changes in separate files in /etc/ssh/ssh_config.d/*.conf. Likewise for sshd_config. I agree with Andrei, that you should show your config, because I also think that the change you're pointing to is not a source of your problem.
On 07.01.2023 15:25, Michael Ströder wrote:
On 1/7/23 12:32, Andrei Borzenkov wrote:
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?
Are you kidding or trolling or what?
No. You claimed that ssh is broken because it tries to access non-existent files under /etc/ssh/ssh_config.d. I demonstrated (in the part that you gratuitously trimmed off) that on my system ssh tries to access these files, files under /etc/ssh/ssh_config.d (or for that matter /usr/etc/ssh/ssh_config.d) do not exist and ssh works.
Do openSUSE devs all expect that all users here to split their $HOMe/.ssh/config into config snsippets just to satisfy wthis insane config parsing semantics?
This
Good morning. On 07.01.23 14:24, Andrei Borzenkov wrote:
On 07.01.2023 15:25, Michael Ströder wrote:
Are you kidding or trolling or what?
YOU obviously are.
No. You claimed that ssh is broken because it tries to access non-existent files under /etc/ssh/ssh_config.d. I demonstrated (in the part that you gratuitously trimmed off) that on my system ssh tries to access these files, files under /etc/ssh/ssh_config.d (or for that matter /usr/etc/ssh/ssh_config.d) do not exist and ssh works.
Do openSUSE devs all expect that all users here to split their $HOMe/.ssh/config into config snsippets just to satisfy wthis insane config parsing semantics?
seife@strolchi:/dev/shm> zypper se -si openssh-clients Loading repository data... Reading installed packages... S | Name | Type | Version | Arch | Repository --+-----------------+---------+-----------+--------+------------ i | openssh-clients | package | 8.9p1-7.1 | x86_64 | factory-oss => latest available package installed seife@strolchi:/dev/shm> ssh -v server.home.s3e.de OpenSSH_8.9p1, OpenSSL 1.1.1s 1 Nov 2022 debug1: Reading configuration data /home/seife/.ssh/config debug1: /home/seife/.ssh/config line 21: Applying options for server.home.s3e.de debug1: /home/seife/.ssh/config line 73: Applying options for *.home.s3e.de debug1: /home/seife/.ssh/config line 76: Applying options for * 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 server.home.s3e.de [192.168.200.1] port 22. debug1: Connection established. debug1: identity file /home/seife/.ssh/id_ed25519 type 3 debug1: identity file /home/seife/.ssh/id_ed25519-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_8.9 debug1: Remote protocol version 2.0, remote software version OpenSSH_8.4 debug1: compat_banner: match: OpenSSH_8.4 pat OpenSSH* compat 0x04000000 debug1: Authenticating to server.home.s3e.de:22 as 'seife' [...] [...] debug1: channel 0: setting env LANG = "de_DE.utf8" debug1: channel 0: setting env COLORFGBG = "15;0" debug1: channel 0: setting env LC_MESSAGES = "en_US.UTF-8" debug1: channel 0: setting env LC_CTYPE = "en_US.UTF-8" Last login: Sun Jan 8 11:42:48 2023 from 192.168.200.12 Have a lot of fun... seife@server:~> One example that it is actually using my ~/.ssh/config is, that it is sending COLORFGBG wich is configured there. I would not bet that the order of including the files is "correct" (or as I would expect it to be), because I have no idea how openssh handles the order of setting and overriding options, but as /etc/ssh/ssh_config.d/ is empty here, this does not matter right now. So your given information is really not enough to see what the problem is. Opening a bug report with properly spelt out problem description and then filling in the requested information is probably the best way to get your issue fixed. Have fun, -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On Sun, 2023-01-08 at 11:50 +0100, Stefan Seyfried wrote:
debug1: Reading configuration data /home/seife/.ssh/config 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
Here we can see that the user config file is read first, and that it's no problem if no .conf files exist in these locations.
One example that it is actually using my ~/.ssh/config is, that it is sending COLORFGBG wich is configured there.
I would not bet that the order of including the files is "correct" (or as I would expect it to be), because I have no idea how openssh handles the order of setting and overriding options, but as /etc/ssh/ssh_config.d/ is empty here, this does not matter right now.
Exactly. (Side note: ssh configuration can be surprising sometimes, because in contrast to many other packages, the "the first obtained value for each parameter is used", with the notable exception of directives that can take multiple values, like IdentityFile or SendEnv). @Michael Ströder, it's still unclear to me how this change would have broken your setup. Regards, Martin
On Sun, Jan 08, Stefan Seyfried wrote:
I would not bet that the order of including the files is "correct" (or as I would expect it to be), because I have no idea how openssh handles the order of setting and overriding options, but as /etc/ssh/ssh_config.d/ is empty here, this does not matter right now.
The order is "correct" has openssh has a really wired behavior in parsing configuration files :( I discussed this problems with upstream 1-2 years ago, and while several people agreed with me, one of the core maintainers stopped this because "it's working for a big competitor this way" and thus they are not interested in making any changes. About the original problem: This patch is clearly not the fault, as it doesn't change anything if you don't use the directories. Other distributions are doing the same already much longer than we do. So fundamental problems with it would be known and solved already since a very long time. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)
participants (7)
-
Adam Mizerski -
Andrei Borzenkov -
Ben Greiner -
Martin Wilck -
Michael Ströder -
Stefan Seyfried -
Thorsten Kukuk