openssh bugs - Sep 2018 - [Bug 2906] New: Need something like 'Match finalpass'

https://bugzilla.mindrot.org/show_bug.cgi?id=2906

            Bug ID: 2906
           Summary: Need something like 'Match finalpass'
           Product: Portable OpenSSH
           Version: 7.7p1
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: zenczykowski at gmail.com

If canonicalization is on this should behave like 'Match canonical'.
If it isn't it should behave like 'Match all' or 'Host *'.

See https://bugzilla.redhat.com/show_bug.cgi?id=1630166 for extra
details, but:

Basically if system /etc/ssh/ssh_config has a:

  Host *
    Key foo

clause, then this trumps any ~/.ssh/config:

  Host blah.org
    Key bar

setting if user attempts to 'ssh blah'  (where blah canonicalizes to
blah.org).

This is because of config file parse order: first ~/.ssh/config which
doesn't match on non-canonical hostname, then /etc/ssh/ssh_config which
matches on * and sets Key=foo.  Then on re-parse with canonical
hostname user's Host blah.org matches, but it's too late to set Key=bar
because it's already been set.

(perhaps related, but perhaps there should also be some sort of special
handling for 'Key +bar' or 'Key -bar' to treat it as
append/remove
instead of override, but that would be far more difficult to implement)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2906

--- Comment #1 from Maciej ?enczykowski <zenczykowski at gmail.com> ---
(and yeah I realize that there's a problem if canonicalization gets
turned on *after* the match has already been analyzed - oh well, don't
do that)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2906

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org
           Assignee|unassigned-bugs at mindrot.org |djm at mindrot.org
             Status|NEW                         |ASSIGNED

--- Comment #2 from Damien Miller <djm at mindrot.org> ---
Created attachment 3179
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3179&action=edit
Match final

Here's an implementation of a "Match final" criterion.

If parsing encounters a "Match final" during the initial parse then
re-parsing of the configuration files will be forced, regardless of
whether CanonicalizeHostname is enabled.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2906

--- Comment #3 from Maciej ?enczykowski <zenczykowski at gmail.com> ---
What are the next steps here?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2906

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |2915


Referenced Bugs:

https://bugzilla.mindrot.org/show_bug.cgi?id=2915
[Bug 2915] Tracking bug for 8.0 release
-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2906

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #4 from Damien Miller <djm at mindrot.org> ---
This has been committed and, barring catastrophe, will be in OpenSSH
8.0.

commit 9e34e0c59ab04514f9de9934a772283f7f372afe (HEAD -> master,
origin/master, origin/HEAD)
Author: djm at openbsd.org <djm at openbsd.org>
Date:   Fri Nov 23 05:08:07 2018 +0000

    upstream: add a ssh_config "Match final" predicate

    Matches in same pass as "Match canonical" but doesn't require
    hostname canonicalisation be enabled. bz#2906 ok markus

    OpenBSD-Commit-ID: fba1dfe9f6e0cabcd0e2b3be13f7a434199beffa

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2906

--- Comment #5 from Maciej ?enczykowski <zenczykowski at gmail.com> ---
Thank you!

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2906

Jakub Jelen <jjelen at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jjelen at redhat.com
             Status|RESOLVED                    |CLOSED

--- Comment #6 from Jakub Jelen <jjelen at redhat.com> ---
FYI, there is a twist with this option, if we use it in combination
with Host blocks, that worked before. They do not follow these flags
and are matched also in the second pass, which can cause unexpected
results.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2906

Jakub Jelen <jjelen at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|CLOSED                      |RESOLVED

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2906

Jakub Jelen <jjelen at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|FIXED                       |---
             Status|RESOLVED                    |REOPENED

--- Comment #7 from Jakub Jelen <jjelen at redhat.com> ---
My bad. The Match blocks are still matched even during the final pass,
which is not expected from the description in the manual page. The
second pass should not match unless there is the final keyword.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2906

--- Comment #8 from Damien Miller <djm at mindrot.org> ---
AFAIK that's working as intended. All match and host blocks will match
in the final pass unless told not to (Match !finalpass). This is the
same behaviour as "Match canonical" has had since it was introduced.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2906

--- Comment #9 from Jakub Jelen <jjelen at redhat.com> ---
Well, that probably makes sense, but with configurations like following
(for simplicity rewritten from Host blocks):

  Match host ext
      Hostname bastion.ext.example.com

  Match host *.ext.example.com
      ProxyCommand ssh -q ext -W %h:%p

  Match final
      ...

Connecting to host x.ext.example.com causes a infinite recursion of
spanning ssh processes, while it works fine without the last match
block.

I am wondering, if the "match final" should not behave less like the
canonical so in the second path, the host would be matched really
against the host that was used on commandline (like originalhost) to
avoid breaking existing configurations.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2906

--- Comment #10 from Maciej ?enczykowski <zenczykowski at gmail.com> ---
Is this perhaps not just a bug that ProxyCommand can apparently somehow
trigger more than once?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2906

--- Comment #11 from Maciej ?enczykowski <zenczykowski at gmail.com> ---
Hmm or perhaps:

Match host ext
      Hostname bastion.ext.example.com

should actually be:

Match host ext
      Hostname bastion.ext.example.com
      ProxyCommand none

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2906

--- Comment #12 from Maciej ?enczykowski <zenczykowski at gmail.com> ---
btw. are you sure your example is correct?
Perhaps you meant to have:

Match host *.ext.example.com
    ProxyCommand ssh -q ext -W %h:%p

Match host ext
    Hostname bastion.ext.example.com

Match final
    ...

(ie. opposite order)

Because - while I haven't tested it - by my naive interpretation of the
matching rules your example should have also resulted in infinite
ssh's.

For your example:

x.ext.example.com triggers the proxycommand, so we ssh to ext

ext gets converted to bastion.ext.example.com
which then triggers the proxycommand (due to ordering)

Match final should not be needed.
With the ordering I gave above, I think Match final does introduce the
problem, but then I think adding ProxyCommand none to the host ext
block still solves it...

???

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2906

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|REOPENED                    |RESOLVED

--- Comment #13 from Damien Miller <djm at mindrot.org> ---
IMO the behaviour is consistent, so I'll close this

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2906

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #14 from Damien Miller <djm at mindrot.org> ---
closing resolved bugs as of 8.6p1 release

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.