Mailing List Archive

[Bug 866] ssh(1) is too picky about unknown options in ~/.ssh/config
http://bugzilla.mindrot.org/show_bug.cgi?id=866

Summary: ssh(1) is too picky about unknown options in
~/.ssh/config
Product: Portable OpenSSH
Version: 3.8p1
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: ssh
AssignedTo: openssh-bugs@mindrot.org
ReportedBy: Nicolas.Williams@sun.com
CC: openssh-unix-dev@mindrot.org


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.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 866] ssh(1) is too picky about unknown options in ~/.ssh/config [ In reply to ]
http://bugzilla.mindrot.org/show_bug.cgi?id=866

djm@mindrot.org changed:

What |Removed |Added
----------------------------------------------------------------------------
CC|openssh-unix-dev@mindrot.org|
Status|NEW |RESOLVED
Resolution| |WONTFIX



------- Additional Comments From djm@mindrot.org 2004-05-08 08:55 -------
Don't Cc the list on bugs!



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 866] ssh(1) is too picky about unknown options in ~/.ssh/config [ In reply to ]
http://bugzilla.mindrot.org/show_bug.cgi?id=866





------- Additional Comments From djm@mindrot.org 2004-05-08 08:58 -------
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 :)



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 866] ssh(1) is too picky about unknown options in ~/.ssh/config [ In reply to ]
http://bugzilla.mindrot.org/show_bug.cgi?id=866





------- Additional Comments From Nicolas.Williams@sun.com 2004-05-08 09:17 -------
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.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 866] ssh(1) is too picky about unknown options in ~/.ssh/config [ In reply to ]
http://bugzilla.mindrot.org/show_bug.cgi?id=866





------- Additional Comments From Nicolas.Williams@sun.com 2004-05-08 09:22 -------
Also, with respect to older version , we should stop the rot for
the future.

I think prompting in non-batch mode sounds good.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 866] ssh(1) is too picky about unknown options in ~/.ssh/config [ In reply to ]
http://bugzilla.mindrot.org/show_bug.cgi?id=866





------- Additional Comments From djm@mindrot.org 2004-05-08 09:25 -------
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.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 866] ssh(1) is too picky about unknown options in ~/.ssh/config [ In reply to ]
http://bugzilla.mindrot.org/show_bug.cgi?id=866





------- Additional Comments From Nicolas.Williams@sun.com 2004-05-08 09:27 -------
GSS options. E.g., GssKeyEx (which Solaris 10 supports and OpenSSH doesn't).



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 866] ssh(1) is too picky about unknown options in ~/.ssh/config [ In reply to ]
http://bugzilla.mindrot.org/show_bug.cgi?id=866





------- Additional Comments From mouring@eviladmin.org 2004-05-08 09:51 -------
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




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 866] ssh(1) is too picky about unknown options in ~/.ssh/config [ In reply to ]
http://bugzilla.mindrot.org/show_bug.cgi?id=866





------- Additional Comments From Nicolas.Williams@sun.com 2004-05-09 12:05 -------
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.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 866] ssh(1) is too picky about unknown options in ~/.ssh/config [ In reply to ]
http://bugzilla.mindrot.org/show_bug.cgi?id=866





------- Additional Comments From dtucker@zip.com.au 2004-05-10 10:13 -------
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.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 866] ssh(1) is too picky about unknown options in ~/.ssh/config [ In reply to ]
http://bugzilla.mindrot.org/show_bug.cgi?id=866





------- Additional Comments From Nicolas.Williams@sun.com 2004-05-11 02:43 -------

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



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 866] ssh(1) is too picky about unknown options in ~/.ssh/config [ In reply to ]
http://bugzilla.mindrot.org/show_bug.cgi?id=866

Nicolas.Williams@sun.com changed:

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



------- Additional Comments From Nicolas.Williams@sun.com 2004-05-11 03:32 -------
> ------- 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.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.