How do SSH keys and directory services work together for Git access control?

How SSH keys and directory services split authentication from authorisation

SSH keys are the cryptographic proof used at login time, while the directory service becomes the source of record for who the person is, which groups they belong to, and which attributes should drive access decisions. That split keeps Git access control from collapsing into one-off local accounts, and it gives administrators a cleaner way to centralise access changes across repositories and teams.

In practice, the SSH server accepts the key as an authentication factor and then looks up the user in the directory service to resolve roles, group membership, or other policy inputs. That means the same person can authenticate successfully yet still be limited by repository policy, environment, or team membership. It is the combination that matters: cryptographic login plus directory-backed authorisation.

For teams managing many developers, contractors, and automation identities, this separation is what makes access control scalable. SSH keys answer the question “can this client prove possession of the private key?”, while directory services answer “what should this account be allowed to do now?”. When those responsibilities are separated, Git access is easier to audit, easier to revoke, and less dependent on manual account creation.

Why this model is stronger than local passwords and hand-built accounts

Local passwords and manually maintained Unix accounts often create drift between HR, IAM, and repository permissions. A directory-backed model reduces that drift because account status, group membership, and attribute changes can flow from the central identity source rather than being recreated on each server. That improves consistency when users join, move between teams, or leave the organisation.

The security benefit is not just convenience. Git servers often sit behind other systems such as bastions, CI/CD runners, or developer platforms, so stale local accounts can become an unnecessary access path. A directory service gives you a single place to disable users, remove group membership, and apply policy changes, while SSH keys continue to provide strong client authentication without exposing reusable passwords.

Internal access control guides such as Authorisation Models Guide and IAM and IGA Basics are useful here because this pattern is fundamentally about separating authentication from role, entitlement, and lifecycle governance. For implementation detail, NIST SP 800-53 Rev 5 Security and Privacy Controls gives the broader control language around identification, authentication, and access enforcement.

Where Git access control breaks down in real deployments

The most common failure is treating SSH key presence as equivalent to permission. A valid key only proves possession of the private key; it does not say whether the user still belongs in the project, whether the key should still exist, or whether the account should have read, write, or admin access. If the directory service is not consulted, teams often keep over-permissive access long after the user’s role changed.

Another common issue is orphaned keys. When users leave or move teams, the directory entry may be removed or changed, but the SSH key may still remain on servers, deploy targets, or authorized key stores. At that point, the access path persists even though the business relationship has ended. For Git platforms, that can expose repositories, branches, hooks, or deployment credentials tied to the same login path.

For operationally important Git environments, the pattern is to use directory membership as the policy source and SSH keys as the transport mechanism for authentication. That is the same design logic behind stronger SSH governance, where key inventory, rotation, and removal of stale access are managed centrally rather than left to each host. The SSH Key and SSH Certificate Management Guide is especially relevant when the server-side trust boundary depends on authorised keys or SSH certificates.

Risk and Threat Considerations

Git access control becomes fragile when authentication and authorisation drift apart. A key can remain valid after a user changes teams, a directory attribute can be stale, or a local exception can outlive its intended purpose, all of which can leave repository access broader than the business expects.

Failure mechanism: Attackers or insiders benefit when a valid SSH key is still accepted even though the related directory record no longer reflects current access, or when server-side key stores are not cleaned up after a joiner-mover-leaver event.

Impact: The result can be unauthorised repository access, code theft, malicious commits, secret exposure, or use of Git access as a stepping stone to CI/CD and production systems.

Practitioner Guidance

What to verify: Confirm that the SSH layer authenticates only against approved keys or certificates, and that authorisation is always resolved from a current directory-backed source rather than from static local files. If the server still trusts local exceptions, treat that as a policy gap.

What good looks like: A user’s directory state, group membership, and effective repository permissions should change together quickly enough that leaving a team or leaving the company removes Git access without manual cleanup on each host. Access reviews should be able to show why a user can reach a repository, not just that a key exists.

Practitioner takeaway: The cleanest Git access model is not “SSH keys or directory services”, but SSH keys for proving the client and directory services for deciding the entitlement, with timely revocation and no orphaned server-side exceptions.

Related resources from NHI Mgmt Group

• How should teams control Git repository access with directory services in Linux environments?
• How do continuous discovery and access control work together for AI agents?
• How do feature flags and entitlements work together in AI agent access control?
• How should security teams balance on-premises directory services with cloud access control in a hybrid environment?