[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: bookworm upgrade report: boring



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.

> 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.

> 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.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


Reply to: