openssh bugs - May 2022 - [Bug 3436] New: consider adding unknown options to ssh -G’s output

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

            Bug ID: 3436
           Summary: consider adding unknown options to ssh -G?s output
           Product: Portable OpenSSH
           Version: v9.0p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: calestyo at scientia.org

Hey.

It would be nice, if ssh?s -G could output the key/value pairs for
unknown options, e.g. with some prefixed _ or so, to put them into a
separate "namespace".

The idea is that it would greatly allow one to use ssh -G as a config
parser in scripts.

If one had something like
Host foo
   IgnoreUnknown   MyOption
   MyOption value yes

Then one could use ssh -G to get the right value of MyOption (and
whether it's set) out-of-the-box... without needing to care on any
things like selecting the right Host or Match block, etc..

Cheers,
Chris.

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

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

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at dtucker.net

--- Comment #1 from Darren Tucker <dtucker at dtucker.net> ---
(In reply to Christoph Anton Mitterer from comment #0)
> The idea is that it would greatly allow one to use ssh -G as a
> config parser in scripts.
> 
> If one had something like
> Host foo
>    IgnoreUnknown   MyOption
>    MyOption value yes
I don't think this would be feasible in the current parser without a
significant rewrite.  The ssh -G works is that the parser runs as
normal, filling the Options structure which is then dumped to stdout. 
It's not general purpose parser.

I also don't see what the use case for this would be.  Could you give
an example?

-- 
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=3436

--- Comment #2 from Christoph Anton Mitterer <calestyo at scientia.org>
---
I'm writing a small wrapper tool (which tries to do the wrapping in a
particularly "clean" way) around ssh (and ideally also sftp/scp).

Right now it reads a:
setenv OpenSSHWrapperCommand="something"

(via ssh -G) from ssh_config, and when something comes out of that, it
`eval`s that... otherwise it `exec`s ssh "$@" .

Then I'll add further such commands, specific for ssh, sftp, scp (and
OpenSSHWrapperCommand) just being the "default" for all of them.

If -G were to print out unknown commands (which I've asked for in
another ticket, IIRC) I could directly use a command name for that,
which users would need to add to IgnoreUnknown.


Now there are several possible use cases, basically anything which
needs to be done locally, but for which LocalCommand doesn't suite.
E.g. it might be handy to set up env vars, which are then transmitted
via SendEnv.

Or we have nodes which are reachable via VPN (even with ssh... don't
ask me for the sense in that ^^) ... so the wrapper could initiate that
before.


Obviously it would be even better to have such functionality in ssh
itself, but I guess you'd rather consider it bloat.


But having some help in parsing would still be nice,...

-- 
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.