openssh bugs - Apr 2025 - [Bug 3807] New: Authentication failure due to expired certificates

https://bugzilla.mindrot.org/show_bug.cgi?id=3807

            Bug ID: 3807
           Summary: Authentication failure due to expired certificates
           Product: Portable OpenSSH
           Version: -current
          Hardware: 68k
                OS: All
            Status: NEW
          Severity: major
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: mariano.cano at gmail.com

At least from openssh 9.6, when the sshd server is configured with
certificates, child processes created on a new connection won't pick a
refreshed certificate and will use the one available when the server
started, even though you can see in the logs that the certificate has
been reprocessed. 

I've tested this in the following versions:

* 9.9: fail
* 9.6: fail
* 9.2: ok
* 8.2: ok

Fail means that a refreshed certificate is not used, and ok means that
it was used.

The configuration looks like this:

Match all
        TrustedUserCAKeys /etc/ssh/ca.pub
        HostCertificate /etc/ssh/ssh_host_ecdsa_key-cert.pub
        HostKey /etc/ssh/ssh_host_ecdsa_key

The logs on all versions tested show this:

... sshd[373286]: debug3: checking match for 'all' user xxx host xxx
addr xxx laddr xxx lport 22
... sshd[373286]: debug3: reprocess config:130 setting
TrustedUserCAKeys /etc/ssh/ca.pub
... sshd[373286]: debug3: reprocess config:131 setting HostCertificate
/etc/ssh/ssh_host_ecdsa_key-cert.pub
... sshd[373286]: debug3: reprocess config:132 setting HostKey
/etc/ssh/ssh_host_ecdsa_key

If we use strace to see the system calls of each process on a working
version (9.2), we can see the file being opened:

[pid 18697] openat(AT_FDCWD, "/etc/ssh/ssh_host_ecdsa_key-cert.pub",
O_RDONLY) = 4

This is not the case at least with the version 9.6

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3807

--- Comment #1 from Mariano Cano <mariano.cano at gmail.com> ---
Ok, I've compiled multiple branches from the source code, and now I
have a clearer understanding of when this started.

* V_9_6_P1: ok (with the patches that ubuntu applies it fails)
* V_9_7_P1: ok
* V_9_8_P1: fails
* V_9_9_P2: fails
* master: fails

V_9_8_P1 introduced sshd-session, it might be related to this issue.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3807

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at dtucker.net

--- Comment #2 from Darren Tucker <dtucker at dtucker.net> ---
sshd is not intended to pick up changed config files at connection
time, only at startup and reload time.  It looks like this may have
been done unintentionally for some things in some releases, probably as
an unintended side effect of sshd re-exec, but its current behaviour is
not a bug.

If you're changing config files you need to restart or reload sshd to
ensure your changes become effective.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3807

--- Comment #3 from Mariano Cano <mariano.cano at gmail.com> ---
Sounds good, but SSHD had the previous behavior for years.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.