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
What's the shell of the user set to? Does that shell exist?
User shell is /bin/sh
26.7.2 ships OpenSSH 10.4p1 but we haven't seen any issues with it. Also successfully tested 10.5p1 with PQ which is coming to 26.7.3.
So, yes, it could be the OpenSSH update, but there's nothing obvious:
https://www.openssh.org/txt/release-10.4
Cheers,
Franco
Try "ssh -v" then.
Quote from: revr3nd on August 19, 2026, 04:09:38 PMI can't ssh into the device to do this. :/
He means on the client. It would at least show if there's an attempt to use your key(pair) for authentication... but it wouldn't tell you why the server side is rejecting it...
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).
Do you have the public key corresponding at least one of those private keys added the the "Authorized Keys" for the user?
It looks like password authentication is not actually enabled? It should move on to the keyboard-interactive or password method if publickey doesn't work...
shell login is only permitted for root by default.
Did you grant this "admin_user" shell access?
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
Could be depending on the type of key or SSH client used, especially if the key and/or client is very old and/or defective (there were compromised / blacklisted keys because of a bad RNG). The defaults for key security are ever increased with newer OpenSSH releases. That is, bad or insecure mechanisms are slowly thrown out.
Try to create new SSH keys with a modern client, install the public key an try if that works.
But ... RSA? Still supported just fine AFAIK.
Well, given the release log only this sticks out:
* 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. Previously a malicious peer could
continue sending non-key exchange messages without penalty. These
would be buffered, causing memory to be wasted up until the
connection terminated or the server/client hit a memory limit.
Implementations that do not restrict messages sent during key
exchange as per RFC4253 section 7.1 may be disconnected.
Reported by Marko Jevtic.
It's easy to test if 10.4 had to do with this by re-installing 10.3:
# opnsense-revert -r 26.7.1 openssh-portable
# pluginctl local:openssh
If it's working it's the above, if it's not working it's a configuration issue.
Cheers,
Franco
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")
Quote from: franco on August 19, 2026, 07:35:10 PMWell, given the release log only this sticks out:
* 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...(?)
Quote from: dseven on August 19, 2026, 07:50:38 PMRegardless 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 :/
Are you sure you're actually ssh'ing to the opnsense box? Maybe you have destination NAT for port 22 or something???