[Bug 866] ssh(1) is too picky about unknown options in ~/.ssh/config

[bugzilla-daemon at bugzilla.mindrot.org]

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


Josh Triplett <josh at freedesktop.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |josh at freedesktop.org




--- Comment #13 from Josh Triplett <josh at freedesktop.org>  2008-01-03 16:29:15 ---
I encountered the same issue.  I share my .ssh/config (along with many
other dotfiles) between machines through version control.  Among other
things, my .ssh/config turns off HashKnownHosts to avoid breaking tab
completion, and sets up ControlPath.  (The default ssh config has
HashKnownHosts turned off, but some distros or systems turn it on by
default.)  Unfortunately, some of the systems I want to share that
config file with have an older ssh that does not support HashKnownHosts
or ControlPath, causing ssh to error out when I run it.

As mentioned in previous comments, obviously ssh cannot change past
versions to add any kind of support for ignoring unknown config
options, and other implementations of ssh will not necessarily support
this mechanism either.  However, I have no doubt that something like
this will eventually happen again: a new config option will come up
that I will want to enable when available, but older systems will choke
on it.  I'd really like some way to write my .ssh/config in a way that
older versions of ssh will not choke on.  I realize that almost any
solution for this will make my .ssh/config incompatible with versions
of ssh before the introduction of the compatibility feature.  However,
once this compatibility feature becomes sufficiently widespread, the
problem will no longer occur with any new feature.

I can see two reasonably easy ways to implement this, either of which
seems to solve the problem.

1) The simpler solution: just add an option prefix that causes SSH to
simply ignore the option if it cannot understand it.  This prefix
should work anywhere a directive can appear.

2) The more complex and flexible solution: add an option prefix that
implements simple conditionals.  This could look something like "If
supported HashKnownHosts HashKnownHosts no".  This prefix should work
anywhere a directive could appear.  I don't think this needs complex
boolean logic; with "If" and "IfNot" available, nested ifs could handle
"and", and parallel ifs could handle "or" and "else".  The only complex
part here involves the definition of predicates. 
supported(SomeDirective) would handle the issues raised in this bug
report, bug I can also imagine someone wanting to check for a
particular parameter of a directive, such as if a yes/no directive
added an "ask" parameter.  The "ignore if not understood" prefix in
option 1 avoids the need for predicates, but does not provide any way
to know what part of the directive did not work, and does not provide a
way to do fallbacks.

Do either of those solutions seem like something reasonable to include
in SSH?

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching someone on the CC list of the bug.