How FreeIPA centralizes SSH key management
FreeIPA can hold each user's SSH public keys and each host's SSH host keys in the directory, so enrolled Linux machines stop depending on hand-edited files. Without central management, a ~/.ssh/authorized_keys file on each server becomes the de facto record of who can log in, and those files drift as people join, change roles and leave. A leaver's key often survives on hosts nobody remembers, and each new host starts with its own copy of the list. Host keys have a similar problem: known_hosts entries copied by hand or accepted on first connection leave teams with no reliable answer when a host key changes. Central storage gives you one place to review, disable and rotate keys, and it gives auditors one place to ask who could reach which machine.
On each client, SSSD (the System Security Services Daemon) answers the SSH daemon's lookups. Once a host is enrolled, SSSD can supply authorized keys and host keys from FreeIPA, so the same user record also governs Kerberos login, host access rules and account status. FreeIPA is described in its About page as an integrated identity solution, and its code is licensed under GPL-3.0-or-later as a community project with no paid edition. The costs you plan for are therefore infrastructure, staff time and any support contract you buy, not a license fee. Teams usually need this when leavers must lose SSH access everywhere at once, when auditors ask for evidence of who held access to a system, or when a fleet must trust a host key that was rotated on purpose. The central record is only as good as enrollment: a host rebuilt outside FreeIPA can still carry old local keys.
Before you design around this, confirm three things on each distribution you run. First, the OpenSSH version and whether sshd is configured to ask SSSD for keys, which normally means an AuthorizedKeysCommand entry in sshd_config that calls the SSSD helper. Check the exact path and syntax for your release. Second, the ssh responder in sssd.conf and the SSSD version, because key lookup depends on both. Third, which FreeIPA release your servers run and whether that release's documentation describes SSH key storage the way you expect. Then test with a disposable account: add a key, log in, disable the account, and confirm that key login stops on a host that also keeps a local authorized_keys file. Plan a rotation schedule for user and host keys before go-live, because changing a host key triggers warnings on every client that cached the old one.
Which SSH key storage approach fits each estate
This table compares four ways to store and distribute SSH keys: per-host authorized_keys files, central keys in FreeIPA with SSSD lookups, a hybrid transition period, and certificate-based access from the FreeIPA CA. Read each row against your estate's host count, change process and audit needs, then check the confirmation column before you commit to a design.
| Approach | When it fits | What changes for administrators | What to confirm first |
|---|---|---|---|
| Per-host authorized_keys files | Small estates with few hosts, a stable set of administrators, and no central identity requirement for SSH | Each host owner edits files directly, so offboarding means touching every host and drift between hosts is likely | Whether an audit or access review requires a single record of who can reach which host |
| Central keys in FreeIPA with SSSD lookups | Estates already enrolled in FreeIPA where user accounts and SSH access should follow one directory record | Users manage their public keys in IPA, and enrolled hosts read them through SSSD, so per-host file edits stop for those users | The SSSD version and sshd configuration on each client distribution, and how sshd is pointed at SSSD for key lookup |
| Hybrid transition period | Estates moving from local files while some hosts, service accounts or legacy tools still depend on authorized_keys | Administrators maintain two sources during the transition, so the cutover order and the list of exceptions must be written down | Which accounts and hosts still read local files, and a dated plan for removing those local entries |
| Certificate-based SSH access from the FreeIPA CA | Estates that want short-lived access tied to identity and can run a certificate-issuing workflow for SSH | Access is granted by issuing certificates rather than installing keys, and hosts must trust the CA, which changes how revocation and renewal are handled | Whether your FreeIPA CA setup and OpenSSH versions support this flow, and who approves and revokes certificates |
| Revocation and offboarding | Any estate that must remove SSH access quickly when a person leaves or a key is lost | Removing a directory entry or certificate stops new logins, but cached or already open sessions need separate handling | How long cached data persists on clients and whether your process covers existing sessions |
Setting up central SSH keys in FreeIPA step by step
This sequence moves SSH trust from scattered per-host files into FreeIPA, so user keys and host keys are managed once and read by every enrolled machine through SSSD, with each change verified before local files are removed.
Confirm enrolled clients and SSSD health
Before changing anything, check that every host in scope is enrolled and that SSSD resolves FreeIPA identities on it. Run a lookup for a test user and a test group on each host, confirm the host appears in the FreeIPA host list, and check that the SSSD service is running without errors in its logs. Hosts that fail here will not read central keys later, so fix enrollment, DNS and time synchronization first. The step is done when every in-scope host returns the same identity results from a test lookup.
Inventory existing authorized_keys and known_hosts files
Collect every local authorized_keys and known_hosts file across the in-scope hosts, including service accounts and root. Record the account, the key type, the key comment and the host it lives on, and flag keys that belong to people who have left or to shared accounts. Save a count of keys per host and per account as your baseline, because you will compare against it during cutover. The step is done when you have a complete list and a baseline count that the team has reviewed.
Load user SSH public keys into FreeIPA
Add each user's public key to their FreeIPA user entry, either through the web UI or the command line, after confirming the key owner and removing keys that should no longer work. Keep private keys out of this process entirely. Confirm the key is stored by listing the user's entry and comparing the count with the inventory for that person. The step is done when every user who needs central access has their keys stored and the counts match the reviewed list.
Publish host public keys for enrolled hosts
Upload each enrolled host's SSH host public keys to its FreeIPA host entry so clients can build known hosts data centrally. Generate the keys for the host type you use, confirm the key algorithms match what sshd offers, and check that the host entry shows them. Compare the fingerprints in FreeIPA with the fingerprints reported by each host's sshd to catch mismatches before clients rely on them. The step is done when every in-scope host's fingerprints match on both sides.
Configure sshd and SSSD to read central data
On a pilot host, set sshd to look up authorized keys through SSSD by configuring AuthorizedKeysCommand and its user for the SSSD lookup, and enable the SSH key domain option in SSSD's configuration. Restart the services and confirm that sshd reads the configuration without errors. Keep the existing local authorized_keys files in place during this step so you have a fallback. The step is done when the pilot host accepts a key that exists only in FreeIPA and the configuration matches the version your distribution documents. Confirm exact option names against the sshd and SSSD manual pages for your release.
Test logins with a pilot group
Choose a small pilot group of users and two or three pilot hosts, then test each user's login from a fresh session while keeping an existing session open as a fallback. Confirm that each login succeeds using only the FreeIPA key, that a removed or wrong key is refused, and that known hosts resolution works for outbound SSH from pilot hosts. Log the results and any sshd or SSSD messages. The step is done when every pilot user logs in from a second session with the central key and the failure cases behave as expected.
Roll out to hosts and remove local files in waves
Extend the configuration to the remaining hosts in waves, and after each wave, repeat the second-session login test and compare the current key counts with the baseline from the inventory. Only when a wave passes, back up and then remove the local authorized_keys entries that the central store now covers, starting with non-privileged accounts. Keep root and break-glass access under a documented exception until the team agrees on its handling. The step is done when every wave has passed its comparison and the remaining local files contain only items you have approved to keep.
Security risks when keys move into the directory
Putting SSH public keys in a central directory changes who can alter access and how far a single compromise reaches. Each card below pairs one risk with a control you can set and verify before keys move into FreeIPA.
Who can write keys
Any identity allowed to modify a user entry can add a public key that grants shell access. Limit write rights on the SSH key attribute to the account lifecycle process and to users changing their own keys, and review delegation rules and admin group membership. Check the effective permissions for a test administrator account before go-live.
Directory and replica protection
Once keys live in the directory, a compromised replica or server administrator can change keys for every enrolled host. Restrict root access on IPA servers, keep them dedicated to IPA, and confirm that backups and replica copies are held under the same access rules as the primary data.
Fallback during outages
If a client cannot reach FreeIPA, it may lose the ability to fetch authorized keys, so administrators may be locked out or forced to use shared local accounts. Decide in advance how emergency access works, document which accounts keep local keys, and test cached logins with SSSD on representative hosts before relying on them.
Host key changes and spoofing
Known hosts distributed from the directory let users trust a host key without a prompt, so a changed or forged host key can pass unnoticed. Limit who can replace host key entries, alert on changes to them, and require a documented reason and approval for any host key rotation. Verify fingerprints on a sample of hosts after each change.
Stale keys after leavers
A departing user whose account is disabled but whose keys remain in an old backup, cache or group may keep access on hosts that still hold cached data. Tie key removal to the offboarding workflow, disable accounts as the first step, and confirm that SSSD caches on laptops and remote servers expire or clear as expected.
Logging of key use
Central key storage does not show which key authenticated a session unless the SSH daemon and the log pipeline record it. Confirm that sshd logs the key fingerprint on each accepted login, forward those logs off the host, and retain them long enough for your investigation and review needs.
Rotating user and host keys without locking people out
This sequence adds each new key before the old one is removed, so users and hosts keep a working login path while the change is verified. It also keeps clients that cache host keys from rejecting a host after its identity changes.
Add the new user key alongside the old one
The user, or an administrator acting for them, adds the new public key to the user entry while the existing key stays in place. Use
ipa user-modwith the SSH public key option and confirm on your FreeIPA version, withipa user-mod --help, whether the option appends or replaces the list, because a replacement that omits a working key cuts off access. This step is done whenipa user-showlists both keys andsss_ssh_authorizedkeyson a test host returns both.Verify login with the new key on pilot hosts
Pick a small group of hosts that cover different roles and log in as the user with the new key. Confirm that sshd retrieves keys through SSSD on each host, and that the old key still works during the overlap. Clients query the replica they are configured to use, so a change made on one server may not appear on another until replication completes. This step is done when every pilot host accepts the new key and the old key, and the test results are recorded.
Confirm replication reaches every replica
Check that each replica in each datacenter holds the updated user entry before you touch other hosts. FreeIPA's deployment recommendations call for at least two to three replicas in each datacenter, so a host can be served by any of them. Use
ipa-replica-manage listto review the topology, then query the user entry on each server directly. This step is done when every replica returns both keys for the user, and any replica that lags has been investigated before the rotation continues.Remove the old user key after verification
Once the pilot hosts and all replicas show the new key, remove the old key from the user entry. Use the same option as the addition step, and copy the final key list into your change record first. Some users keep a second key for a hardware token or a second workstation, so check with them before removal. This step is done when
ipa user-showlists only the intended keys, a host that had only the old key now refuses it, and the new key still logs in.Publish the new host key before changing identity
Before regenerating SSH host keys on a machine, add the new public host key to the host entry with
ipa host-modand its SSH host key option. Clients that rely on SSSD for known hosts can then learn the new key from FreeIPA rather than encountering an unknown identity. Regenerate the keys on the host and restart sshd only after the entry shows both keys. This step is done whenipa host-showlists the new key and the host's old and new keys both appear in its published list.Refresh cached known hosts on clients
Clients that keep a local known_hosts file, or that cache host data in SSSD, may still hold the old fingerprint after the host changes. Keep both host keys published for an agreed overlap period, then review a sample of client machines for stale entries and remove any that pin the old key. Confirm how your SSSD version exposes known hosts to clients through its documentation before you rely on it. This step is done when connections to the rotated host succeed on the sample without a host key warning.
Back up before rotation and test restores in isolation
Take a FreeIPA backup before the rotation starts so there is a known state to return to. FreeIPA's backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so a restore is an incident response step, not a routine rollback. Test restores on an isolated system, and note that the first server handles certificate renewal and CRL publication by default. This step is done when a backup exists, a test restore has been completed on an isolated system, and the team has written down which server to use for recovery.
Limits to confirm in your environment
SSH key management with FreeIPA depends on several moving parts: the distribution, the SSSD version, the sshd build and the automation already touching your hosts. The cards below list what to verify in a lab before rollout, and who to ask for each answer.
Distributions and SSSD versions
Central key lookup depends on the SSSD release shipped on each client OS, and support statements differ between RHEL-family clients and other distributions. Confirm which client OS versions your FreeIPA server version supports, then check the installed SSSD version on a representative host of each OS. Ask the vendor or your distribution maintainer whether the SSH key lookup feature is available and enabled by default in that release.
Whether sshd reads the central source
sshd must be configured to ask SSSD for authorized keys through the AuthorizedKeysCommand directive, and the build of OpenSSH on each host must support that path. Some hardened images, appliances and older builds ship without it or use a different configuration layout. Test a login with a key that exists only in FreeIPA, with no local authorized_keys file present, and confirm sshd logs show the lookup succeeded.
Existing automation that writes keys
Configuration management, provisioning scripts and onboarding tools may still append keys to authorized_keys files on each host. Once FreeIPA is authoritative, those writes can drift from the central record and create keys you did not intend to trust. Inventory every tool that touches authorized_keys, decide whether each one is retired or repointed, and run a test that adds and removes a key centrally to observe what the automation does next.
Container and jump host patterns
Containers often lack SSSD, and short-lived workloads may not enroll with FreeIPA at all, so key lookup fails for them. Jump hosts, bastions and build agents also need a decision about whether they trust central keys, local keys or both. Map each access path, including ephemeral containers and service accounts, and confirm in a lab which of them can resolve the user and read the central key before you write the policy.
Certificate-based SSH gaps
Storing public keys centrally does not by itself provide SSH certificate issuance, host certificate validation or certificate revocation for SSH. If your policy requires short-lived SSH certificates or certificate revocation, confirm with the vendor whether the FreeIPA release you plan to run covers that path, and which parts you would build yourself. Write down the gap as a named risk with an owner, not as an assumed capability.
Questions teams ask before moving SSH keys into FreeIPA
How much effort does a pilot for SSH key management in FreeIPA take?
A pilot usually takes less effort than the full migration, but the size depends on what you are proving. Effort rises with the number of hosts you want in the pilot, the number of Linux distributions in use, and whether sshd and SSSD settings are changed by hand or by automation. A useful pilot covers a small set of representative hosts per distribution, one test group of users, and one rollback path. Ask any partner to state the pilot scope, the hosts included, and the acceptance checks in writing before work starts. No duration figure is given here because none has been researched for this topic, so confirm it against your own estate.
Can our own team move SSH keys into FreeIPA without a partner?
Yes, if your team already runs FreeIPA and has people comfortable with SSSD, sshd configuration and change control. The work has three parts: loading public keys into user and host entries, configuring SSSD to serve authorized keys and known hosts, and removing per-host authorized_keys files only after login is verified. Teams with a small estate and an existing FreeIPA deployment often handle the first pilot in-house. Teams without FreeIPA experience usually benefit from an outside review of the SSSD settings and the removal plan, because a mistake can lock administrators out of servers.
What do we need to provide for a key migration?
Plan for three kinds of access and time. First, FreeIPA directory administrators who can create user and host entries, set attributes and approve the schema changes your SSSD configuration depends on. Second, root or equivalent access on each target host to change sshd and SSSD settings, plus a console or out-of-band path in case SSH access breaks. Third, change windows for each group of servers, with a named owner who can confirm logins work afterward. Also provide an inventory of current authorized_keys files, since that list defines what must be migrated and what can be retired.
How long does a migration take for a large estate?
The duration depends mainly on host count, the number of distinct configurations, the number of change windows you can run, and how many keys need review before they are moved. Estates with one standard image usually move in batches quickly after the pilot. Estates with many snowflake hosts, shared service accounts, or keys with unclear owners take longer, because someone must decide which keys to keep. No duration is given here because no researched figure exists for this topic. Ask for a timeline built from your host inventory and batch plan, not from a generic number.
What does it cost to maintain SSH key management in FreeIPA after go-live?
FreeIPA itself is licensed under GPL-3.0-or-later and has no paid edition, so the license is not the recurring cost. The recurring costs are the staff time to run FreeIPA servers, patch them, review new keys and onboard or offboard users, plus the infrastructure the servers run on. Key rotation adds ongoing work: someone must define the rotation policy, track which keys were replaced, and confirm that hosts pick up changes. If you retain an outside partner, that cost is set by the retainer scope. Ask any quote to separate one-time migration work from recurring operations and support.
What breaks if we remove authorized_keys files too early?
Administrators can lose SSH access to servers. Removing per-host files before SSSD serves keys correctly on every target host is the most common failure. Keep a tested fallback, such as an administrator console or a second login path, until you have verified key lookup from SSSD for each distribution and each service account that depends on keys. Also check that sshd is configured to read keys from SSSD, that the relevant hosts can reach the FreeIPA servers, and that cached data does not hide a removed key. Keep the old files in an archive for a defined period before deletion.
How do we handle key rotation and host key changes once keys are central?
Central storage makes rotation a directory change instead of a per-host edit, but it does not rotate keys by itself. Define who may add and remove keys, how long a key may live, and how a compromised key is revoked. For host keys, record the fingerprint change, update the stored entry, and confirm that clients receive the new known hosts data before the old key is retired. Test rotation on a pilot host first. Confirm each step with your FreeIPA version and your sshd and SSSD versions, because behavior can differ between releases.
What changes for administrators and users after the move
Once user public keys live in FreeIPA, users stop editing files on each host to add or remove a key. They manage their keys through the FreeIPA web interface or the ipa command line, and SSSD on each enrolled machine serves those keys to sshd. A user who replaces a laptop or rotates a key changes it in one place, and the change applies to every host they are allowed to reach. Confirm with your own pilot that users understand the new workflow, and decide whether key self-service is open to all users or limited to certain groups before you announce the change.
For administrators, the main gain is that stale keys stop accumulating in authorized_keys files scattered across the estate. Instead of searching hosts for keys belonging to departed staff, you review one directory. Host keys follow the same logic: known hosts are published centrally, so the work of distributing fingerprints or cleaning up changed host keys moves out of individual operator sessions. The trade-off is that the central store becomes a critical dependency, so plan replica coverage and test what a host does when it cannot reach an IPA server, which is covered in the offline login topic.
For the help desk, the change is a single point of control. Disabling a user account in FreeIPA stops Kerberos and password logins and removes that user's key from SSH on every enrolled host, without a per-host clean-up. Account lifecycle, group membership and access rules such as host-based access control and sudo are managed elsewhere in FreeIPA, so the SSH key work should be read alongside those controls. Before go-live, check that your offboarding runbook names FreeIPA as the step that revokes SSH access, and see the client enrollment and offline login topics for how enrolled hosts behave when they are offline.
How DeployOpen scopes and delivers SSH key management
DeployOpen scopes SSH key management as a written, fixed-scope engagement in which the client's team and DeployOpen agree up front which hosts, user populations and key types are in scope. The work starts with an inventory of existing `authorized_keys` files, known_hosts entries, service accounts that rely on keys, and the sudo and HBAC rules that decide who can reach each host. That inventory tells both sides how many keys exist, which ones belong to people who still work at the organization, and which hosts need central key lookup configured first. The output is a written list of the decisions the client must make, such as whether host keys will be published centrally, which key algorithms are allowed, and who approves key changes.
Delivery then moves through a pilot on a small group of hosts, followed by a phased rollout. In the pilot, DeployOpen configures SSSD to read authorized keys from FreeIPA on test machines, checks login and sudo behavior, and confirms that removing a user's key in FreeIPA stops access as expected. The client receives runbooks for adding and revoking keys, rotating host keys, and removing legacy per-host files once a host is verified. Everything is deployed and documented inside the client's own cloud accounts, data centers or air-gapped networks, and DeployOpen does not hold the client's keys or directory data outside that environment. Where an auditor needs evidence of key lifecycle controls, DeployOpen prepares the configuration records, change logs and test results, but it does not issue audit reports or attestations, which remain the job of independent assessors.
Handover covers the runbooks, configuration in version control where the client wants it, and a short training session for the operators who will own the process after go-live. Clients who want continued help can add an optional retainer for ongoing support, upgrades and periodic review of the key lifecycle. Before requesting a quote, confirm with DeployOpen the host count, the number of user accounts with stored keys, the distributions in use and whether any hosts sit outside the directory's reach, since each of these changes the written scope.
