Hi there !

I'm just trying to consolidate my .ssh/config and as things still aren't working as expected, I'm not sure if I understood the way the config is
parsed. What I want to achieve is a setup where a destination can hit
more than one configuration block and I thought that "match host"
applies some settings but continues parsing whereas "host" is a final statement.

As an example, with the following config file,

===== 8< =====

match host networkA,networkB
forwardAgent yes
user u1

host hostA
user u2

===== >8 =====

"ssh hostA" with an IP address in networkB is supposed to actually do
"ssh -A -l u2 hostA". But I don't see a difference between "match host"
and "host", both directives seem to be final and it looks like the
"first match" policy doesn't apply to entire "host" blocks but to every
single option, hence preventing any option from being overwritten.

IS this right? How does the config have to look like for the desired result?

Could any expert please solve my confusion? ;)

TIA

fw

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

with <[email protected]> Frank Winkler wrote:

[ out of order ]

Could any expert please solve my confusion? ;)

Not an expert, in a sense -- I've never needed (wanted) anything close
to what you want. But, for the purpose of discussion...

I'm just trying to consolidate my .ssh/config and as things still
aren't working as expected, I'm not sure if I understood the way the
config is parsed. What I want to achieve is a setup where a
destination can hit more than one configuration block and I thought
that "match host" applies some settings but continues parsing whereas
"host" is a final statement.

First, my reading of ssh_config(5) suggests that neither "configuration
block", nor "conditional block", nor "block" is canonical. But let's
stick with it (also, thinking in "block"s might be misleading).

As an example, with the following config file,

===== 8< =====

match host networkA,networkB
forwardAgent yes
user u1

host hostA
user u2

===== >8 =====

Now, what ssh(1) does if multiple blocks match is a mistery --
ssh_config(5) doesn't tell anything. I believe options are:

[1] first
[2] last
[3] random
[4] merge (with options [1]..[3] applied (recursively?))
[5] none
[6] none and bail out

"ssh hostA" with an IP address in networkB is supposed to actually do
"ssh -A -l u2 hostA". But I don't see a difference between "match
host" and "host", both directives seem to be final and it looks like
the "first match" policy doesn't apply to entire "host" blocks but to
every single option, hence preventing any option from being
overwritten.

Looks like [5] and [6] are out. From what you describe, I can't pick
among [1]..[4] -- excerpts of 'ssh -v' output are required (but not
requested, it's up to you).

IS this right? How does the config have to look like for the desired
result?

I expect (pessimisticaly), it will end up with least (I'd go with most) specific pattern per host with desired options -- one block for each
host that's where it's going :/

--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 26.11.22 17:26, Eric Pozharski wrote:

>First, my reading of ssh_config(5) suggests that neither "configuration
>block", nor "conditional block", nor "block" is canonical.

I'm still not sure if I really gut what you want to say here.

>Now, what ssh(1) does if multiple blocks match is a mistery --
>ssh_config(5) doesn't tell anything. I believe options are:
>
>[1] first
>[2] last
>[3] random
>[4] merge (with options [1]..[3] applied (recursively?))
>[5] none
>[6] none and bail out

>Looks like [5] and [6] are out. From what you describe, I can't pick
>among [1]..[4] -- excerpts of 'ssh -v' output are required (but not
>requested, it's up to you).

I can supply some output if you like. I've also been wondering which of
there options may apply but I couldn't find an answer. Another
possibility (even if most probably also wrong) could be "best".

>I expect (pessimisticaly), it will end up with least (I'd go with most)
>specific pattern per host with desired options -- one block for each
>host that's where it's going :/

I hope you're wrong (please don't take that personally ;). Currently, I
have a couple of "host" blocks with name patterns. In most cases, this
works as expected but it's far from cool.

TIA

fw

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 26.11.22 17:26, Eric Pozharski wrote:

>First, my reading of ssh_config(5) suggests that neither "configuration
>block", nor "conditional block", nor "block" is canonical.

I'm still not sure if I really gut what you want to say here.

>Now, what ssh(1) does if multiple blocks match is a mistery --
>ssh_config(5) doesn't tell anything. I believe options are:
>
>[1] first
>[2] last
>[3] random
>[4] merge (with options [1]..[3] applied (recursively?))
>[5] none
>[6] none and bail out

>Looks like [5] and [6] are out. From what you describe, I can't pick
>among [1]..[4] -- excerpts of 'ssh -v' output are required (but not
>requested, it's up to you).

I can supply some output if you like but I'm afraid this won't be very
helpful. "-v" only shows which file is being used but not what's
happening behind the scenes - and "-G" only show the result of all this.
I've also been wondering which of there options may apply but I couldn't
find an answer. Another possibility (even if most probably also wrong)
could be "best".

>I expect (pessimisticaly), it will end up with least (I'd go with
>most) specific pattern per host with desired options -- one block for
>each host that's where it's going :/
I hope you're wrong (please don't take that personal ;). Currently, I
have a couple of "host" blocks with name patterns. In most cases, this
works as expected but it's far from cool.

TIA

fw

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

with <[email protected]> Frank Winkler wrote:

On 26.11.22 17:26, Eric Pozharski wrote:

First, my reading of ssh_config(5) suggests that neither
"configuration block", nor "conditional block", nor "block" is
canonical.

I'm still not sure if I really gut what you want to say here.

I'm trying to say, (this is speculation, I haven't been involved by any measure) blocks have been added to ssh(1) some time later after ssh(1)
has been injected. That's why block-related behaviour is
underdocumented, counter-intuitive, and kind of crude. It's a hack
(like that old meaning).

I can imagine at least two alternatives. ssh(1) features "-F
configfile" option (useful feature: /etc/ssh/ssh_config will be
ignored). Or GTK based configurator with assorted registry (just like
The Rulers of Redmond have intented).

Now, what ssh(1) does if multiple blocks match is a mistery --
ssh_config(5) doesn't tell anything. I believe options are:

[1] first
[2] last
[3] random
[4] merge (with options [1]..[3] applied (recursively?))
[5] none
[6] none and bail out

Looks like [5] and [6] are out. From what you describe, I can't pick
among [1]..[4] -- excerpts of 'ssh -v' output are required (but not
requested, it's up to you).

I can supply some output if you like but I'm afraid this won't be very helpful. "-v" only shows which file is being used but not what's
happening behind the scenes - and "-G" only show the result of all
this. I've also been wondering which of there options may apply but I couldn't find an answer. Another possibility (even if most probably
also wrong) could be "best".

By any measure, you don't need unpaid support to read your logs. What
you need: three distinct blocks, however, each should be in effect.
Then by observing what option-value pairs spring in you can infer how it
works. Just remember, it can be [4].

Otherwise, source is available. Reading code isn't rocket science.

I expect (pessimisticaly), it will end up with least (I'd go with
most) specific pattern per host with desired options -- one block for
each host that's where it's going :/

I hope you're wrong (please don't take that personal ;). Currently, I
have a couple of "host" blocks with name patterns. In most cases, this
works as expected but it's far from cool.

Enjoy your GTK-free life till it lasts :[ Writings are already on the
wall.

--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)