openssh bugs - May 2004 - [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 at mindrot.org
        ReportedBy: Nicolas.Williams at sun.com
                CC: openssh-unix-dev at 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.

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

djm at mindrot.org changed:

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



------- Additional Comments From djm at 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.

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





------- Additional Comments From djm at 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.

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





------- Additional Comments From Nicolas.Williams at 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.

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





------- Additional Comments From Nicolas.Williams at 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.

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





------- Additional Comments From djm at 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.

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





------- Additional Comments From Nicolas.Williams at 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.

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





------- Additional Comments From mouring at 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.

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





------- Additional Comments From Nicolas.Williams at 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.

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





------- Additional Comments From dtucker at 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.

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





------- Additional Comments From Nicolas.Williams at 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.

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

Nicolas.Williams at sun.com changed:

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



------- Additional Comments From Nicolas.Williams at 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.