SSH to opnsense fails after upgrade to 26.7.2_2

[dseven]

Well, given the release log only this sticks out:

Code Select Expand

* ssh(1), sshd(8): make the transport protocol stricter by
  disconnecting if the peer sends non-KEX messages during a post-
  authentication key re-exchange...

It's not even passing initial authentication, though - so doesn't get anywhere near key re-exchange...(?)

[revr3nd]

Regardless of key type, if password authentication is enabled, there should be a password prompt if the publickey method fails, so there's something else not right here.

OP, when this worked prior to the upgrade, were you prompted for a password, or did you get straight in with the key?

Check System -> Log Files -> Audit for clues (maybe change level to "Informational")

Only items in the audit logs are just starting and stopping of the process. Does not appear to generate any logs of connection attempts


2026-08-19T10:37:57-07:00InformationalsshdServer listening on 127.0.0.1 port 22.
2026-08-19T10:37:57-07:00InformationalsshdServer listening on fe80::1%lo0 port 22.
2026-08-19T10:37:57-07:00InformationalsshdServer listening on fe80::227c:14ff:fef4:381d%vlan0.10 port 22.
2026-08-19T10:37:57-07:00InformationalsshdServer listening on 192.168.11.1 port 22.
2026-08-19T10:37:57-07:00InformationalsshdServer listening on fe80::227c:14ff:fef4:381d%vlan0.11 port 22.
2026-08-19T10:37:57-07:00InformationalsshdServer listening on fd00:0:0:11::1 port 22.
2026-08-19T10:37:56-07:00InformationalsshdReceived signal 15; terminating.




Regarding rollback of the process itself, I will need to go on site to console into the device. This will take some time :/

[dseven]

Are you sure you're actually ssh'ing to the opnsense box? Maybe you have destination NAT for port 22 or something???

[franco]

It's not even passing initial authentication, though - so doesn't get anywhere near key re-exchange...(?)

It's a theory based on the parameters we got from the reporter--not more not less.  Release notes aim to be precise but they usually over-simplify the situation.  Unintentional or undocumented changers are a possibility too.  The revert test I mention is the best way forward...


Cheers,
Franco

[dseven]

Looking at the earlier verbose output from the client, I see:

Code Select Expand

debug1: compat_banner: no match: Go

where I get:

Code Select Expand

debug1: compat_banner: match: OpenSSH_10.4 FreeBSD-openssh-portable-10.4.p1,1 pat OpenSSH* compat 0x04000000

so I'm fairly sure that the ssh server responding for the OP is not the normal opnsense one

[meyergru]

Nice find, but:

a. More interesting than the "no match: Go" line is the line immediately before it:

Remote protocol version 2.0, remote software version Go

So there really seems to be an SSH server responding — just apparently not OpenSSH. The presented server string seems to be "SSH-2.0-Go".

b. The odd part about that is that the server presents a known host key:

Host '192.168.11.1' is known and matches the RSA host key.

That can simply mean the user accepted that key on an earlier connection, however that host key was exactly the one that was stored for 192.168.11.1. So it would be useful to check whether this fingerprint actually matches the SSH host key of the OPNsense box.

c. I would compare both the banner and the host key directly:

Code Select Expand

# on OPNsense
nc 127.0.0.1 22
ssh-keygen -lf /conf/sshd/ssh_host_rsa_key.pub

# from the affected client
nc 192.168.11.1 22
ssh-keyscan -t rsa 192.168.11.1 | ssh-keygen -lf -

If localhost says OpenSSH... while the client gets SSH-2.0-Go, then something in the network path — e.g. NAT/redirect/proxying — is clearly intercepting the connection. The interesting question is: who answers here? I doubt that it is OpenSSH on OpnSense, so the version change does not matter.

[drosophila]

Looking more closely at the entire log there must be something (ph/f)ishy going on with the connection. The algorithms don't match either, nor does the key format.
(debug1: kex: algorithm: sntrup761x25519-sha512@openssh.com
debug1: kex: host key algorithm: ssh-ed25519
vs.
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: rsa-sha2-512)

Also, the password auth is not in the available methods so it cannot succeed: Mine says:
debug1: Authentications that can continue: publickey,password,keyboard-interactive
the OPs says:
debug1: Authentications that can continue: publickey

MITM attack going on?