On Tue, 13 Jun 2023 16:46:36 +0200 Vincent Lefevre <vinc...@vinc17.net> wrote:
> On 2023-06-12 13:33:02 -0400, Celejar wrote: > > Often, but apparently not always. For example, on one of my upgrades, > > the old sshd_config had: > > > > ********** > > # Change to yes to enable challenge-response passwords (beware issues with > > # some PAM modules and threads) > > ChallengeResponseAuthentication no > > ********** > > > > whereas the new one had: > > > > ********** > > # Change to yes to enable challenge-response passwords (beware issues with > > # some PAM modules and threads) > > KbdInteractiveAuthentication no > > ********** > > In the /usr/share/doc/openssh-server/changelog.Debian.gz file: > > openssh (1:8.7p1-1) unstable; urgency=medium > [...] > - ssh(1)/sshd(8): remove references to ChallengeResponseAuthentication > in favour of KbdInteractiveAuthentication. The former is what was in > SSHv1, the latter is what is in SSHv2 (RFC4256) and they were treated > as somewhat but not entirely equivalent. We retain the old name as a > deprecated alias so configuration files continue to work as well as a > reference in the man page for people looking for it. Thanks. > > Is this important? > > If the alias is still there, this is not important. Otherwise, either > the option could be ignored (so you get the default), possibly with a > warning, or there could be a fatal error (but you would have noticed > it); I don't know how sshd behaves in case of an unknown option. > > But in any case, I would recommend to update the config. That's indeed what I did. > > What would have happened had I left the old version, > > as opposed to switching to the new version? Presumably nothing, since > > I'm using the safer default setting in either case, and I suppose I > > could have taken the time to track down the change and its > > implications, but running into these types of situations while > > upgrading can be disconcerting. > > > > > and reject the package version offered. Less stressful and speeds up > > > the installation. If necessary, I investigate afterwards. > > > > This is probably the logical thing to do, but I'm always worried that > > there may be new settings that should be set, and so on. > > I always look at the diffs (I track all the config files I modify), > and sometimes at the logs too. In general, I do some kind of merge. This is of course the responsible thing to do - my point was that these types of situations can make upgrading not quite as boring as the OP's experience :) -- Celejar
