[Bug 3586] New: Create mechanism for vendor-specific extensions to be placed in config without breaking other platforms

[bugzilla-daemon at mindrot.org]

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

            Bug ID: 3586
           Summary: Create mechanism for vendor-specific extensions to be
                    placed in config without breaking other platforms
           Product: Portable OpenSSH
           Version: 9.0p1
          Hardware: All
                OS: Mac OS X
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: owen at delong.com

I realize this is a problem created by Apple, but I believe they did
the best they could under the circumstances and would like to propose a
vendor-independent solution.

Apple integrates many things in terms of password and key storage into
what is known as Apple KeyChain, which, in addition to managing keys,
certificates, and passwords, also allows synchronization across (Apple)
hosts via iCloud.

To support integrating this capability into SSH key management, Apple
added a (proprietary) extension to the ssh config file on their
systems:

UseKeyChain {yes|no}

While I don't think OpenSSH wants to add this keyword as an ignore to
every other platform, the current behavior is that the presence of this
keyword in a .ssh/config file (or /etc/ssh/ssh_config file) breaks and
prevents the processing of the rest of said config file.

I think the ideal solution is to add a Vendor or VendorSpecific (or
something similar, don't really care what it's called) keyword that
allows for vendor-specific extensions to be ignored by versions of SSH
that don't understand the keyword.

So, for example, UseKeychain would be replaced with:
VendorSpecific UseKeychain yes

Thus, an Apple system would see that as a keyword it knows and parse
it, while another system would see that as an unknown keyword and
silently ignore it without consequence.

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