Parsing SSH Config Fails when "Match" is encountered

[ChadThomsonPSC]

Type: Bug

With an SSH configuration file that uses includes, the parsing of the included config files stops upon encountering the valid SSL keyword "Match", regardless of casing, spacing, or surrounding context.

With several configuration files representing individual host configurations, the SSH extension seems to be reading the files in reverse-lexical (alpha-numeric reversed) order.

The first few configuration files read contain simple "Host " declarations. Those hosts are visible in both the Remote Explorer view, as well as the "Remote-SSH: Connect to host..." dialog. When a subsequent file contains even the simplest of "Match" stanza, all remaining hostnames are not displayed in either view or dialog.

Reproducing this can be acheived by generating a similar configuration with a Match stanza, and observing the results. Following commenting out the Match stanza, by prefixing with "#", and saving the file, simply opening either the Remote Explorer view (and issuing a refresh) or invoking the "Remote-SSH: Connect to host..." dialog from the command pallet, will review all additional hosts read from configuration files, up to the next "Match" stanza.

I have reviewed the closed and open issues, as well as tested extensively. Include path, relative or fully-qualified, does not seem to be an issue on Windows or MacOS (M2). I have also tested using a configuration file specific for the Remote SSH extension, and also leaving the configuration file property empty, allowing the default SSH configuration file (~/.ssh/config) to be used. In any case, the result is the same -- failure upon hitting a Match stanza.

Extension version: 0.109.2024022215 VS Code version: Code 1.86.1 (Universal) (31c37ee8f63491495ac49e43b8544550fbae4533, 2024-02-07T09:09:01.236Z) OS version: Darwin arm64 23.4.0 Modes:

System Info

|Item|Value| |---|---| |CPUs|Apple M2 Pro (12 x 24)| |GPU Status|2d_canvas: enabled
canvas_oop_rasterization: enabled_on
direct_rendering_display_compositor: disabled_off_ok
gpu_compositing: enabled
multiple_raster_threads: enabled_on
opengl: enabled_on
rasterization: enabled
raw_draw: disabled_off_ok
skia_graphite: disabled_off
video_decode: enabled
video_encode: enabled
webgl: enabled
webgl2: enabled
webgpu: enabled| |Load (avg)|3, 2, 2| |Memory (System)|32.00GB (4.79GB free)| |Process Argv|| |Screen Reader|no| |VM|0%|

[roblourens]

Can you give an example? Maybe https://github.com/microsoft/vscode-remote-release/issues/9479

[ChadThomsonPSC]

Match Stanza

I suspect the issue may be based around incorrect parsing of the Match stanza.

Regardless of Include being present, when a Match stanza is present, similar to...

Host cloudflared
    HostName 10.10.10.1

Match originalhost="cloudflared"
    IdentitiesOnly  true

... the following error is presented:

Missing value for match criteria
   originalhost=cloudflared

The error message is only displayed when the Match stanza is in the main configuration file. When Match is used within any Include-ed file, and the exception occurs, parsing then stops and no error message is presented.

Note: the absence of quotes around originalhost=cloudflared, and the configuration in the stanza is valid.

Unfortunately, there are no hints about what is actually wrong with the section.

[mjpieters]

Can you give an example? Maybe #9479

Yes, I think it's the same thing, a (fixed) bug in the ssh-parse project (issue cyjake/ssh-config#74).

[mjpieters]

I can confirm that the fix cyjake/ssh-config#74 fixes this issue for me: I opened ~/.vscode/extensions/ms-vscode-remote.remote-ssh-0.110.2024032215/ in vscode, searched for [ \t]/.test and replaced the single occurence with [ \t=]/.test.

[ryanc-me]

Same issue here (in my caase it was a Match host="123.123.123.123" stanza), and the fix mentioned by @mjpieters worked for me too.

[andreamah]

Hi @mjpieters @ryanc-me @ChadThomsonPSC! Can you try verifying that this is fixed on the latest prerelease version of remote-ssh? Thanks!

[mjpieters]

Hi @mjpieters @ryanc-me @ChadThomsonPSC! Can you try verifying that this is fixed on the latest prerelease version of remote-ssh? Thanks!

I can confirm v0.111.2024040515 is working for me.