[Bug 3791] New: Option for sshd to allow "invalid users" (no local account) to connect with trusted ssh certificates

[bugzilla-daemon at mindrot.org]

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

            Bug ID: 3791
           Summary: Option for sshd to allow "invalid users" (no local
                    account) to connect with trusted ssh certificates
           Product: Portable OpenSSH
           Version: -current
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: forfuncsake at gmail.com

Issue:

In environments where servers are configured to use trusted user
certificate authorities via the TrustedUserCAs option in sshd_config,
the current OpenSSH implementation does not support automatic user
account creation based on the user certificate when local accounts do
not already exist on the system.


Proposal:

Introduce a configuration option (or set of options) to allow a trusted
SSH user certificate to be verified and passed to PAM modules, even if
a local account for that user is not yet present on the host. If a
connection with an invalid or missing user is authorized by PAM,
perform an additional NSS lookup after PAM completes, in case the
module has created the target account during this authorization
attempt.


Expected Benefit:

- Simplifies user management in environments without central directory
services (e.g., LDAP) accessible to all hosts.
- Enables seamless provisioning of user accounts based solely on
trusted certificates, without requiring pre-existing local accounts.


Testing / Experience:

In an attempt to map out a solution for automatic account provisioning
based solely on a trusted user certificate, I configured a pam_exec.so
script to log available parameters/environment variables, hoping to use
certificate details in the script logic. However, since the certificate
was unavailable at that stage, I proceeded by allowing a hardcoded
specific username for testing.
I then used the AuthorizedPrincipalsCommand to parse the verified
certificate and create a local account if it didn't already exist.
During testing, I discovered that the initial NSS username lookup
caused the non-existent user to be considered "invalid", ultimately
blocking login even though subsequent PAM authorization were able to
run and succeeded. After the account was created via the
AuthorizedPrincipalsCommand, a second connection attempt succeeded.

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