cve-2026-35414 break down

Daniel_Kavan — Thu, 14 May 2026 14:41:35 GMT

sk65269 - Check Point response to OpenSSH CVEs

RE: CVE-2026-35414

Can anyone add where and how or steps to check to this description? I'm trying to confirm customer that has certificate authentication thru check point management ICA for VPN users if they aren't vulnerable.

Vulnerable, Conditional. This is a combination of a very rare setup: certificate authentication configured (not regular public key auth) + the CA key must be trusted via the cert-authority option (not via TrustedUserCAKeys) + the principals = option must list more than one principal + the attacker must either control or compromise the CA.

Re: cve-2026-35414 break down

Bob_Zimmerman — Thu, 14 May 2026 16:24:26 GMT

I've worked with OpenSSH for decades, including hanging out on the development list and even contributing some minor patches. I have never personally seen a single environment which uses this feature, and I've only even heard of two.

The short version is you set up an SSH server key for the CA, you use ssh-keygen(1) to have the CA sign itself, then use that key to sign keys generated by users. The process of signing a user key involves specifying the users for whom that user key is valid. This is shown in the ssh-keygen(1) manpage in this line:

ssh-keygen -s ca_key -I key_id -n user1,user2 user_key.pub

Then you tell the SSH server to trust user keys signed by a particular CA key, typically with a TrustedUserCAKeys entry in the sshd_config(5) file. It can be done with an AuthorizedKeysFile entry instead, which is required for this CVE to be an issue.

See the comma in the command above? That's the "more than one principal" which is required for this CVE to be an issue.

topic Re: cve-2026-35414 break down in Firewall and Security Management

cve-2026-35414 break down

Re: cve-2026-35414 break down