On Fri, May 26, 2023 at 7:55 AM Andreas Hasenack
<email address hidden> wrote:
> Regarding the config file, I'm still thinking about options. One problem is that we can switch between the sshd implementations with the update-alternatives --config command, it doesn't have to be with installing and removing packages. Maybe add that config file snippet you suggested as another update-alternatives slave, like the manpage? I'll think about it, but even that would not totally prevent errors.
That's a good point. Ideally we'd have
/etc/ssh/sshd_config.d/openssh-server-default.ccache.conf ->
openssh-server-default-ccache.conf.real if the o-s-d-c sshd
alternative is selected, but have *no*
/etc/ssh/sshd_config.d/openssh-server-default.ccache.conf link at all
if the standard sshd alternative is selected. What happens when only 1
alternative option provides a given slave?
btw, instead of just being prescriptive about the problem I was
looking to solve with the snippet + symlink was with configuration
file handling, let me be explicit about the problem I was trying to
solve - I'm not sure if it was obvious. If someone makes
o-s-d-c-specific config changes, we should aim to keep track of them
even after o-s-d-c is removed (but not purged). Here is the use/test
case I had in mind:
1) User installs o-s-d-c
2) User makes some o-s-d-c changes that normal o-s does not parse
(i.e. setting KerberosUniqueCCache)
3) User removes o-s-d-c
# Here o-s should not fail because of KerberosUniqueCCache
4) User reinstalls o-s-d-c
# Here the settings the user made in step #2 should have persisted
5) User purges o-s-d-c
# Now the settings in step #2 should be cleared
> People could still add this option to the main sshd_config file.
> If there were a "hook" mechanism we could use, so that whenever update-alternatives is called, we can check if the current config file is ok for the currently selected sshd server, then we could use that.
Perhaps we can also modify the manpage part of the patch to clarify
that this setting should only be defined in the o-s-d-c-specific
snippet, and not any other sshd config file. That, combined with
including a commented out KerberoseUniqueCCache setting in the snippet
for discoverability feels like a complete solution to me.
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). But that might cause an upgrade path problem if
we want to retain the option to drop this patch in the future. That
is, if a 22.04 PPA user decided to dist-upgrade to a 24.04 that
included neither this feature nor a patch to recognize and ignore
KerberoseUniqueCCache, then it'd be good for that the KUCC config to
be quarantined off to avoid causing 24.04's sshd to fail to start.
On Fri, May 26, 2023 at 7:55 AM Andreas Hasenack
<email address hidden> wrote:
> Regarding the config file, I'm still thinking about options. One problem is that we can switch between the sshd implementations with the update-alternatives --config command, it doesn't have to be with installing and removing packages. Maybe add that config file snippet you suggested as another update-alternatives slave, like the manpage? I'll think about it, but even that would not totally prevent errors.
That's a good point. Ideally we'd have sshd_config. d/openssh- server- default. ccache. conf -> server- default- ccache. conf.real if the o-s-d-c sshd sshd_config. d/openssh- server- default. ccache. conf link at all
/etc/ssh/
openssh-
alternative is selected, but have *no*
/etc/ssh/
if the standard sshd alternative is selected. What happens when only 1
alternative option provides a given slave?
btw, instead of just being prescriptive about the problem I was
looking to solve with the snippet + symlink was with configuration
file handling, let me be explicit about the problem I was trying to
solve - I'm not sure if it was obvious. If someone makes
o-s-d-c-specific config changes, we should aim to keep track of them
even after o-s-d-c is removed (but not purged). Here is the use/test
case I had in mind:
1) User installs o-s-d-c Cache) Cache
2) User makes some o-s-d-c changes that normal o-s does not parse
(i.e. setting KerberosUniqueC
3) User removes o-s-d-c
# Here o-s should not fail because of KerberosUniqueC
4) User reinstalls o-s-d-c
# Here the settings the user made in step #2 should have persisted
5) User purges o-s-d-c
# Now the settings in step #2 should be cleared
> People could still add this option to the main sshd_config file.
> If there were a "hook" mechanism we could use, so that whenever update-alternatives is called, we can check if the current config file is ok for the currently selected sshd server, then we could use that.
Perhaps we can also modify the manpage part of the patch to clarify CCache setting in the snippet
that this setting should only be defined in the o-s-d-c-specific
snippet, and not any other sshd config file. That, combined with
including a commented out KerberoseUnique
for discoverability feels like a complete solution to me.
Another option might be to just patch the standard sshd to accept but CCache, then it'd be good for that the KUCC config to
ignore this config option (and ideally emit a warning instead of
silently ignoring it). But that might cause an upgrade path problem if
we want to retain the option to drop this patch in the future. That
is, if a 22.04 PPA user decided to dist-upgrade to a 24.04 that
included neither this feature nor a patch to recognize and ignore
KerberoseUnique
be quarantined off to avoid causing 24.04's sshd to fail to start.
-dann