No SSH access after upgrade to 14.1

sickboy

sickboy

Greetings,

I’ve the following problem: after a remote upgrade of my server from 14.0 to 14.1, I’m not able to connect via SSH anymore:

Code: 
$ ssh user@host -v
...
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: sntrup761x25519-sha512@openssh.com
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

Algorithms on the the client (14.1):

Code: 
$ ssh -Q kex
diffie-hellman-group1-sha1
diffie-hellman-group14-sha1
diffie-hellman-group14-sha256
diffie-hellman-group16-sha512
diffie-hellman-group18-sha512
diffie-hellman-group-exchange-sha1
diffie-hellman-group-exchange-sha256
ecdh-sha2-nistp256
ecdh-sha2-nistp384
ecdh-sha2-nistp521
curve25519-sha256
curve25519-sha256@libssh.org
sntrup761x25519-sha512@openssh.com
$ ssh -Q key
ssh-ed25519
ssh-ed25519-cert-v01@openssh.com
sk-ssh-ed25519@openssh.com
sk-ssh-ed25519-cert-v01@openssh.com
ecdsa-sha2-nistp256
ecdsa-sha2-nistp256-cert-v01@openssh.com
ecdsa-sha2-nistp384
ecdsa-sha2-nistp384-cert-v01@openssh.com
ecdsa-sha2-nistp521
ecdsa-sha2-nistp521-cert-v01@openssh.com
sk-ecdsa-sha2-nistp256@openssh.com
sk-ecdsa-sha2-nistp256-cert-v01@openssh.com
ssh-dss
ssh-dss-cert-v01@openssh.com
ssh-rsa
ssh-rsa-cert-v01@openssh.com

How can I establish an SSH connection?
 
Could be the file /etc/ssh/sshd_config that has been merged during the upgrade, if so you probably deleted your own configuration.
 
For a machine that has no recovery options except working ssh access I would consider setting up a second ssh demon with a separate /etc/ssh directory.

Or be brutal and enable telnet or rsh. You can always change the password right away after re-enabling ssh.
 
sickboy said:
Bummer. That will make some travelling necessary …
Click to expand...
I hope it's not too far?
In order to prevent this to happen again take a look at these threads, they have useful information:
forums.freebsd.org

Solved - freebsd-update: files have been modified locally

Hello everybody, when running freebsd-update on my 13.2-RELEASE-p2 boxes, I get: Fetching metadata signature for 13.2-RELEASE from update1.freebsd.org... done. Fetching metadata index... done. Inspecting system... done. Preparing to download files... done. The following files are affected by...
forums.freebsd.org forums.freebsd.org
forums.freebsd.org

Solved - freebsd-update : modified files issue

How would I go about solving this issue? I don't have the original sshd_config file. $ sudo freebsd-update fetch Looking up update.FreeBSD.org mirrors... 3 mirrors found. Fetching metadata signature for 13.2-RELEASE from update1.freebsd.org... done. Fetching metadata index... done. Inspecting...
forums.freebsd.org forums.freebsd.org

hruodr said:
The imposed merges during upgrades are terrible, one is not prepared to do them at the moment.
Click to expand...
Some people from Linux world do know this already, IMO it's not that hard but indeed you must be prepared to do so.
 
gotnull said:
Some people from Linux world do know this already, IMO it's not that hard but indeed you must be prepared to do so.
Click to expand...
You seem to think that configuration of very different programs are things that may be done on the fly,
during installation, according to a general principle that is not much hard, without seeing and with the left hand.
Absolute nonsense!

When configuring I read man pages, documentation, use google to find more info in internet, I want to do
with an editor with care. I really do not understand what you wrote, and think it is not understandable.

BTW, I have little idea of linux, I was never a real linux user, are linux users such geniuses?
 
Bummer indeed. IMHO FreeBSD is missing an opportunity to advertise its features in cases like this. With boot environments widely available, it should be standard procedure now to update into a cloned boot environment and then activate that for a one-time boot: bectl activate -t updated_BE

For my headless boxen at home I would just reboot them manually if not accessible via ssh, for a remote server you'd have to make it auto-reboot after a timeout, through a cron job or something.

The only downside is that you have to remember to activate the boot environment permanently if the update was successful. And kill the auto-reboot timeout if on a remote server.
 
What likely happened is that during the merges of configuration a merge conflict arose and maybe, possibly, while fixing these you left one of these "<<<" or ">>>" lines, invalidating the configuration. I've had issues like this before as well, even on master.passwd. I can't imagine I'm the only one.
 
malavon said:
What likely happened is that during the merges of configuration a merge conflict arose and maybe, possibly, while fixing these you left one of these "<<<" or ">>>" lines, invalidating the configuration. I've had issues like this before as well, even on master.passwd. I can't imagine I'm the only one.
Click to expand...

Yeah. This scheme is manageable, but screwups are easily made. Especially if you have 2 conflicts and stop fixing after the 1st.

In the case of sshd_config I'd say this is doing more harm than good.
 
hruodr said:
You seem to think that configuration of very different programs are things that may be done on the fly,
during installation, according to a general principle that is not much hard, without seeing and with the left hand.
Absolute nonsense!

When configuring I read man pages, documentation, use google to find more info in internet, I want to do
with an editor with care. I really do not understand what you wrote, and think it is not understandable.

BTW, I have little idea of linux, I was never a real linux user, are linux users such geniuses?
Click to expand...
If you are mad at the merge procedure during freebsd-update, file your complain to the FreeBSD developers not me, thank you.
 
noise said:
… it should be standard procedure now to update into a cloned boot environment and then activate that for a one-time boot: bectl activate -t updated_BE …
Click to expand...

+1

That's better than the current automation with a default that might become a non-default default.
 
I've been bitten by enough remote OS upgrades over the years to go through the steps two or three times on a local network and carefully document any gotchas.

Doesn't help the OP this time, and things can still go horribly wrong (so my next layer of "protection" is BMCs).

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.

But all OSs have their quirks, annoyances, pros and cons, so I make some notes, learn for the next time.
 
When merging config files just keep searching for those "<<<" and ">>>" and only close the editor when no more are present. Learnt it the hard way as well.
For critical stuff like sshd, make sure to restart the service manually before disconnecting/rebooting. The running connected process (at least in the cases I had this happen to me) will not be killed and thus be running on the old config. IF the daemon doesn't start, it's palmsweating until it's fixed.
This doesn't work for firewall rules though, if it decides to block every connection due to a mistake in config then it's toast.
 
You must log in or register to reply here.
Back
Top