SSH to opnsense fails after upgrade to 26.7.2_2

[revr3nd]

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

[Patrick M. Hausen]

What's the shell of the user set to? Does that shell exist?

[revr3nd]

User shell is /bin/sh

[franco]

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

[Patrick M. Hausen]

Try "ssh -v" then.

[revr3nd]

Try "ssh -v" then.

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

[dseven]

I 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...

[revr3nd]

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).

[dseven]

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...

[viragomann]

shell login is only permitted for root by default.
Did you grant this "admin_user" shell access?

[revr3nd]

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

[meyergru]

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.

[Patrick M. Hausen]

But ... RSA? Still supported just fine AFAIK.

[franco]

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. 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

[dseven]

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")