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-b...@mindrot.org
Reporter: forfuncs...@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.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs
