ssh(1) fatal()s when parsing an unknown ~/.ssh/config option. This is rather annoying since ~/.ssh/config may be shared with multiple versions of OpenSSH as well as with OpenSSH derivatives (or even non- derivates that just honor ~/.ssh/config), and since each such implementation may support different sets of features and associated config options. At least when parsing ~/.ssh/config ssh(1) should not fatal() on unknown options, but verbose(). When parsing options given on the command line, however, calling fatal() seems appropriate, and possibly when parsing $PREFIX/etc/ssh_config.
Don't Cc the list on bugs!
Oops, I accidentally closed this without an explanation: The options in ssh_config may have serious security implications. For example, consider one version not understanding an option which restricted access. Another thing to consider: we already have some non-fatal backwards compatibility (with sDeprecated and sUnsupported in readconf.c), but we can't change the past to give forward compatibility :)
Which options in particular do you have in mind which don't have reasonable defaults? In any case, ssh(1) could prompt, if it isn't in batch mode, about unknown options.
Also, with respect to older version , we should stop the rot for the future. I think prompting in non-batch mode sounds good.
We already have "stopped the rot". Deprecated and known-but-not-supported options are non-fatal. We won't prompt - that is ugly beyond belief. What particular options are you having problems with? I have used the same ssh_config for years with no problems.
GSS options. E.g., GssKeyEx (which Solaris 10 supports and OpenSSH doesn't).
Why? We don't bend over backwards to ensure our ssh's client configuration files are compatible with lsh or SSH2 from SSH Corp. I'm wondering why we should for SunSSH. Which is what this boils down to. - Ben
No, it isn't just about making OpenSSH's configuration more compatible with derivatives of it, it's also about making OpenSSH's configuration more compatible with itself across its variousversions (just because you've released a new version doesn't mean that all will upgrade all at once). I'm thinking though that Damien is right that we can't have ssh(1) just verbose() (even aside from possibly security-sensitive unknown parameters) and that prompting is too obnoxious. There may be a better way to deal with this though. Here's a better approach: provide one parameter to list other known parameters that ssh(1) would verbose() or debug() about if it didn't actually know them. Of course, one would typically only use this while transitioning from one version of OpenSSH to another and/or for co-existence with SUNWssh and other derivatives. BTW, here's a list of parameters supported by OpenSSH 3.8* that the Solaris 10 SUNWssh doesn't yet support: RekeyLimit ConnectTimeout AddressFamily ServerAliveInterval ServerAliveCountMax Older versions of OpenSSH don't support all of those either. And as I mentioned before, Solaris 10's ssh(1) supports a GssKeyEx option that OpenSSH's doesn't.
If I understand you, you're talking about adding a "IgnoreIfUnknown" directive or similar to ssh_config, and have ssh ignore any option on that list if it doesn't understand it, but process normally if it does understand it? eg: IgnoreIfUnknown RekeyLimit GssKeyEx This seems to be mostly an issue for $HOME/.ssh/config when homedirs are shared between hosts. The simple solution is: don't use the new options until all the machines have been upgraded, or if you really need them then put them in the host-specific /etc/ssh/ssh_config.
> ------- Additional Comment #9 From Darren Tucker 2004-05-10 10:13 ------- > If I understand you, you're talking about adding a "IgnoreIfUnknown" directive > ... Correct. Customers don't upgrade all at once, sometimes not for years.
> ------- Additional Comment #9 From Darren Tucker 2004-05-10 10:13 ------- > ... > > This seems to be mostly an issue for $HOME/.ssh/config when homedirs are shared > between hosts. The simple solution is: don't use the new options until all the > machines have been upgraded, or if you really need them then put them in the > host-specific /etc/ssh/ssh_config. That's not a realistic solution. Some of these options are best used with Host specifications, and different users may want different settings.
I agree with Nicolas. FYI, as a workaround, I have two config files and a ssh wrapper that does a "ssh -V 2>&1" to determine the version and select the adequate config file with $cmd -F $SSH_CONFIG "$@".
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?
zsh has a syntax which allows me to use a conditional on the version, e.g. if is-at-least 4.3.5; then do this fi Maybe openssh-client could get that too?& I do prefer the "duck typing" approach of checking for options directly, but I also see the security problems. So instead, assuming an option appeared in 4.3, why not let the user say so
bugzilla cropped my comment. It ended with IfVersionAtLeast 4.3 NewOption yes EndIf That is all. :)
(In reply to comment #14) > zsh has a syntax which allows me to use a conditional on the version, > e.g. > > if is-at-least 4.3.5; then > do this > fi > > Maybe openssh-client could get that too?& I do prefer the "duck typing" > approach of checking for options directly, but I also see the security > problems. So instead, assuming an option appeared in 4.3, why not let > the user say so In general I find feature testing superior to version testing, but this solution would also prove sufficient.
Created attachment 1610 [details] Patch which allows OpenSSH to ignore unknown options. This is a patch which implements alternative 1 from Josh Triplett. This patch makes ssh ignore all unknown options which are prefixed with '@'. For example, the following works: Host * @InvalidOption asdf Any chance of having this patch (or something similar) included in OpenSSH?
OpenSolaris shipped this ssh_config(4) parameter: IgnoreIfUnknown Specifies a comma-separated list of ssh_config parame- ters, which, if unknown to ssh(1), are to be ignored by ssh. This parameter is primarily intended to be used in the per-user ssh_config, ~/.ssh/config. While this parameter can also be used in the system wide /etc/ssh/ssh_config file, it is generally useless as the capabilities of the ssh(1) client on that host should match that file. There is no DontIgnoreIfUnknown as I had originally proposed in PSARC/2004/505 (see http://mail.opensolaris.org/pipermail/opensolaris-arc/2007-October/004417.html). Solaris manpage: http://docs.sun.com/app/docs/doc/819-2251/ssh-config-4?l=ja&a=view OpenSolaris source: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/ssh/include/readconf.h http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/ssh/libssh/common/readconf.c
(In reply to comment #17) > Created attachment 1610 [details] > Patch which allows OpenSSH to ignore unknown options. > > This is a patch which implements alternative 1 from Josh Triplett. This > patch makes ssh ignore all unknown options which are prefixed with '@'. > For example, the following works: > > Host * > @InvalidOption asdf > > Any chance of having this patch (or something similar) included in > OpenSSH? This patch looks very promising. However, it doesn't handle the case of ignoring an option that OpenSSH knows about but doesn't support, such as the GSSAPI* options on an installation of OpenSSH that got configured without GSSAPI support. These options have an opcode of oUnsupported. This seems simple enough to fix: change "return keywords[i].opcode;" to: if (ignoreunknown && keywords[i].opcode == oUnsupported) return oIgnored; return keywords[i].opcode; Real-world application of this: I set "GSSAPIAuthentication no" in my ~/.ssh/config, and OpenSSH on my N900 doesn't have GSSAPI support, so I get a warning message every time I use ssh.
Created attachment 2252 [details] add ability to selectively ignore unknown options This is a minimally-intrusive patch to add this
committed. will be in openssh-6.3
*** Bug 1529 has been marked as a duplicate of this bug. ***
Close all resolved bugs after 7.3p1 release