Messages

I do have a destination NAT rule that redirects SSH on the WAN interface to a git server (WAN TCP/22 to an internal server on port TCP/222). The looks here sounds like the SSH directly to the firewall (NOT on the WAN interface) is also getting wrapped up in this destination NAT rule.

I can confirm after disabling that NAT rule I am able to successfully SSH to the firewall.

So the issue here is that the NAT rules are matching and processing the SSH traffic meant for the firewall. It looks like the NAT rule is ignoring the interface the traffic is coming in on.

Breakdown of the rule:
-- Interface: ZN_WAN (group with WAN1 and WAN2 interfaces)
-- Version: IPv4+IPv6
-- Protocol: TCP
-- Destination Address: This firewall
-- Destination Port: TCP/22
-- Redirect Target IP: Git server
-- Redirect Target Port: 222

I'll continue to mess with the rule to make it more specific to only the WAN IPs, but this is a change is how the NAT rules are processed from 26.7.1

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 :/

Yes, the pubkey is associated to the user, and worked prior to the upgrade. I want to baseline that this configuration was working fine with SSH access on 26.7.1, and only broke after upgrade to 26.7.2_2

Password authentication is enabled in the settings. I have enabled and disabled the SSH service as well as password authentication trying to force this back into working. Also restarted the ssh service via the webgui.
No luck on restoration

Ah thank you. See below output:

~$ ssh -v admin_user@192.168.11.1
OpenSSH_9.2p1 Debian-2+deb12u10, OpenSSL 3.0.20 7 Apr 2026
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to 192.168.11.1 [192.168.11.1] port 22.
debug1: Connection established.
debug1: identity file /home/admin_user/.ssh/id_rsa type 0
debug1: identity file /home/admin_user/.ssh/id_rsa-cert type -1
debug1: identity file /home/admin_user/.ssh/id_ecdsa type -1
debug1: identity file /home/admin_user/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/admin_user/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/admin_user/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/admin_user/.ssh/id_ed25519 type -1
debug1: identity file /home/admin_user/.ssh/id_ed25519-cert type -1
debug1: identity file /home/admin_user/.ssh/id_ed25519_sk type -1
debug1: identity file /home/admin_user/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/admin_user/.ssh/id_xmss type -1
debug1: identity file /home/admin_user/.ssh/id_xmss-cert type -1
debug1: identity file /home/admin_user/.ssh/id_dsa type -1
debug1: identity file /home/admin_user/.ssh/id_dsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u10
debug1: Remote protocol version 2.0, remote software version Go
debug1: compat_banner: no match: Go
debug1: Authenticating to 192.168.11.1:22 as 'admin_user'
debug1: load_hostkeys: fopen /home/admin_user/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: rsa-sha2-512
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
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-rsa SHA256:pshHB4mhETWsJKPOg0X5KPU2rIirj5uxkFjkeaYKG7c
debug1: load_hostkeys: fopen /home/admin_user/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: Host '192.168.11.1' is known and matches the RSA host key.
debug1: Found key in /home/admin_user/.ssh/known_hosts:7
debug1: ssh_packet_send2_wrapped: resetting send seqnr 3
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: ssh_packet_read_poll2: resetting read seqnr 3
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /home/admin_user/.ssh/id_rsa RSA SHA256:lx2uLAavi5uG+pJGiZYpUALPIxTswcH1TyvtFmH0ASs
debug1: Will attempt key: /home/admin_user/.ssh/id_ecdsa
debug1: Will attempt key: /home/admin_user/.ssh/id_ecdsa_sk
debug1: Will attempt key: /home/admin_user/.ssh/id_ed25519
debug1: Will attempt key: /home/admin_user/.ssh/id_ed25519_sk
debug1: Will attempt key: /home/admin_user/.ssh/id_xmss
debug1: Will attempt key: /home/admin_user/.ssh/id_dsa
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,rsa-sha2-256,rsa-sha2-512,ssh-rsa,ssh-dss>
debug1: kex_input_ext_info: ping@openssh.com (unrecognised)
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/admin_user/.ssh/id_rsa RSA SHA256:lx2uLAavi5uG+pJGiZYpUALPIxTswcH1TyvtFmH0ASs
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/admin_user/.ssh/id_ecdsa
debug1: Trying private key: /home/admin_user/.ssh/id_ecdsa_sk
debug1: Trying private key: /home/admin_user/.ssh/id_ed25519
debug1: Trying private key: /home/admin_user/.ssh/id_ed25519_sk
debug1: Trying private key: /home/admin_user/.ssh/id_xmss
debug1: Trying private key: /home/admin_user/.ssh/id_dsa
debug1: No more authentication methods to try.
admin_user@192.168.11.1: Permission denied (publickey).

Try "ssh -v" then.

I can't ssh into the device to do this. :/

User shell is /bin/sh

I have upgraded my opnsense to 26.7.2_2, and I can no longer SSH to the device with error: Permission denied (publickey).

I have public key authentication enabled on my non-root user, and password authentication enabled via the Administration settings. Regardless, I get denied before any password prompt is presented.

This issue was not present on the prior version 26.7.1

Great thank you for locating this!

I am also running into this issue about every 3 days, and it kills all traffic with divert rules until I manually restart the Suricata service.

Currently running most recent stable version
OPNsense 26.1.3-amd64

Most recent example:
2026-03-08T18:34:56-07:00 Error suricata [101733] <Error> -- thread W-8000 failed
2026-03-08T18:34:56-07:00 Warning suricata [103270] <Warning> -- Write to ipfw divert socket failed: Permission denied

I've resorted to disabling divert mode until root cause can be identified and worked out