No SSH access after upgrade to 14.1

[malavon]

The 13.3 sshd gotcha is a bit annoying because I think the only change is a commented string VersionAddendum FreeBSD-20240104 so it doesn't seem worth the grief it causes when it goes wrong.

Fun fact: this is actually defaulted in code (it's commented out in my default config).

 

[_martin]

What is the actual error you're getting when logging in? I was not able to tell from the debug1 output you shared.

 

[Eric A. Borisch]

Fun fact: this is actually defaulted in code (it's commented out in my default config).

Right, the update is to maintain the “list of commented options with defaults” nature of sshd_config. The compiled-in default changed, so sshd_config is updated to reflect that.

It would be nice if we could teach freebsd-update how to test certain files during an update. With sshd -t -f /tmp/sshd_config.tmp for example, but ideally also using any new to-be-installed sshd…

 

[cracauer@]

Right, the update is to maintain the “list of commented options with defaults” nature of sshd_config. The compiled-in default changed, so sshd_config is updated to reflect that.

It would be nice if we could teach freebsd-update how to test certain files during an update. With sshd -t -f /tmp/sshd_config.tmp for example, but ideally also using any new to-be-installed sshd…

Well, some software detects conflict markers and refuses to proceed. Editor exits with markers in /etc/passwd or sshd_config have no valid purpose.

 

[Andriy]

Having two system images or two datasets and using options like bootonce or bectl activate -t is the best approach to remote upgrades that I have seen so far.
If things go bad the system either automatically reboots back to the old image or, at most, you ask someone to power-cycle it.
Then there is a chance to examine some logs and configuration from the new image in order to try to fix it.

 

[Bucky]

Yes.

Luckily, I still have SSH access to the important jails on the server, so not all sshd configurations are affected. But it’s still a journey of 150 km to the server for one way.

I don't suppose the server has IPMI access?

 

[Cath O'Deray]

… options like bootonce or bectl activate -t is the best approach to remote upgrades that I have seen …

I treat -t as good practice for all pkg upgrades, including upgrades that are for ports alone.

I can think of only one downside: need to remember to activate in the normal way (not temporary) after boot succeeds.