Re: bookworm upgrade report: boring

[Celejar <celejar@gmail.com>]

On Tue, 13 Jun 2023 16:46:36 +0200
Vincent Lefevre <vincent@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