1. Forum
  2. Usenet
  3. COMP.SECURITY.SSH

  • Understanding the config parser

    From Frank Winkler@21:1/5 to All on Wed Nov 23 15:04:29 2022
    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)
  • From Eric Pozharski@21:1/5 to Frank Winkler on Sat Nov 26 16:26:56 2022
    with <ju6njdFaistU1@mid.individual.net> 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)
  • From Frank Winkler@21:1/5 to Eric Pozharski on Fri Dec 2 13:42:16 2022
    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)
  • From Frank Winkler@21:1/5 to Eric Pozharski on Sun Dec 4 10:35:09 2022
    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)
  • From Eric Pozharski@21:1/5 to Frank Winkler on Wed Dec 7 09:39:12 2022
    with <jv37udFor3eU1@mid.individual.net> 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)