Comment 9 for bug 1990863

I don't have a complete solution to this, but I do have several points.

- debconf prompts on upgrade are not, in general, good UX. It disrupts the flow of the upgrade. Sometimes it's necessary, but if all it's doing is telling the user they *may* have a broken config after upgrading, well, if every package for which that's true did that upgrades would be very slow indeed. And for users upgrading a large number of systems, that becomes one more nuisance. So no, I don't think we should add a prompt on upgrade for this. (There's also the practical problem that if we introduced such a prompt at this point in the release cycle, it would not realistically get translated, reducing accessibility for our users vs communicating this in other ways that could be localized out-of-band.)

- As Robie pointed out in comment #4, there is no guarantee that ansible playbooks work consistently across releases. Regardless of whether we made changes that would have allowed the migration of settings in your case, if you had had to reinstall kinetic instead of upgrading from jammy, those changes in the openssh-server maintainer scripts would not have taken effect. Your ansible playbook is therefore buggy wrt kinetic, and should be fixed, which is out of scope for Ubuntu and the bug tracker. But the following contents in a file named /etc/systemd/system/ssh.socket.d/addresses.conf should set you on the right path:
  [Socket]
  ListenStream=
  ListenStream=$portnum

- I have long been displeased with ucf's three-way-merge support. In particular, when identical content exists both in the user's version and in the new version but not in the base version, ucf will treat this as a merge conflict. This is awful, and specifically caused problems for upgrades from all cloud images when the user had not modified the sshd config at all (LP: #1990863). I've applied a workaround for this in openssh 1ubuntu7 (currently in the unapproved queue) that's specific to the cloud image case and ensures clean upgrades without prompting for users that have not modified sshd_config. I could generalize this to all users with modified configs, resulting in two prompts on upgrade but a better chance of successful three-way merging. Do you think that would be an improvement over the status quo?

- Finally, there is some code I'm evaluating landing that would add a systemd generator for the listenstream settings. This would only take effect at boot, but would make it possible for users to continue managing their port/listenaddress settings in sshd.conf as before. However, we would not land this in time for the kinetic release, but would instead consider it for the next release to improve our LTS-to-LTS compatibility.