I recognized your "breakage" scenario, step (3) specifically:

3) User removes o-s-d-c
# Here o-s should not fail because of KerberosUniqueCCache

I just don't like to have a solution based solely on *where* that config option was added (a specific file in a .d directory).

> Another option might be to just patch the standard sshd to accept but
> ignore this config option (and ideally emit a warning instead of
> silently ignoring it).

I was briefly excited about this, when I saw that ssh has an option called IgnoreUnknown, but it's only for the client... :/

I'm toying now with a script for ExecStartPre in ssh's service unit file. It could check if the sshd that is about to start recognizes KerberosUniqueCCache or not, and then comment it in the config file if necessary to allow sshd to start. This would avoid the catastrophe of remotely killing sshd and the only means to login on to the system. But won't address your step (4):

4) User reinstalls o-s-d-c
# Here the settings the user made in step #2 should have persisted

I.e., it wouldn't restore KerberosUniqueCCache.

I'm also not a big fan of changing config files automatically like that, but hey, it allows sshd to start.

Finally, I'm also contemplating again the decision to use update-alternatives. I'm wondering what would be different if we had instead conflicting server packages. I think not much, because both packages would still be using the same config files, and we would have the same problem of a config option that only one of the packages understands. The only change is the point in which the sshd binary changes, now it's at install/remove time, where we do have hooks (preinst/postinst), and not via update-alternatives.

> Perhaps we can also modify the manpage part of the patch

Going back to what this option actually does:

KerberosUniqueCCache:
no (default in patched sshd): new behavior introduced by this patch
yes: same behavior as unpatched sshd

We don't really need this option at the moment, do we? If you don't want the new behavior, stick with openssh-server. If you want the new behavior, install openssh-server-default-ccache. This option really only makes more sense if you have just one server package, and then you can enable or disable the new behavior.

We could perhaps not include it. At the risk of being different and carry regrets about this decision for quite a while.

To summarize, some of the ideas we had, in no particular order, hope I didn't miss any:

a) constrict the KerberosUniqueCCache option to a specific config file, which we can then manipulate (via alternatives, or something else). Document that users should only change the option in that specific file.

b) ExecStartPre and remove the option from the config (wherever it was found) if the current sshd doesn't understand it. Prevents a failing-to-start-sshd, but makes a change to the config file "behind the user's back". Should only happen if mistakes were made. Somewhat easy mistakes, however.

c) Change the handling of unknown options in unpatched sshd so that if KerberosUniqueCCache is present and unknown, the server won't fail to start (like IgnoreUnknown in the ssh client). Patch on top of patch.

d) Just document this behavior carefully: if the admin removes openssh-server-default-ccache and doesn't remove KerberosUniqueCCache, or if they change the default sshd server via update-alternatives in the same way, it's on them. "Known Issue" for the moment, and gather feedback. Perhaps combined with (b) as a safeguard.

e) Abandon alternatives, create two conflicting packages with essentially same content, and handle config file in maintainer scripts (preinst/postinst). Similar to (b) (ExecStartPre), but at install/remove time.

f) Drop the KerberosUniqueCCache option from the patch. Treat patched sshd as if that option was set to "no" always. That's like a double delta on top of openssh now :)