Keep the local configuration when the system has custom SSH settings that are important to preserve, such as nonstandard ports, access controls, or hardening choices. Replacing it with the maintainer’s version is better only when the current file is obsolete or badly drifted from the supported default. The decision should balance continuity, security, and the need to avoid breaking remote access.
When to keep the local SSH configuration
Keep the local file when it contains intentional SSH hardening or access rules that your environment depends on, such as a nonstandard port, restricted login behaviour, allowed users, or host-based controls. If you accept the package maintainer’s copy blindly, you can undo a deliberate security posture and interrupt remote administration.
The practical question is whether the file still reflects a supported, consciously managed baseline. If it does, preserving local changes usually protects continuity and avoids introducing a new outage just because the package shipped an updated default.
When replacing the maintainer version is the safer choice
Choose the maintainer’s version when the local configuration has drifted so far from the supported default that it is no longer a clean, understandable basis for administration. That is often true when the file is mostly obsolete comments, old compatibility settings, or undocumented edits that no one can explain or test reliably.
Replacing the file is also sensible when the local version no longer supports the current OpenSSH package safely or when the package update is meant to restore a known-good baseline. In that case, the upgrade is a chance to remove dead settings and reapply only the controls you actually need.
For SSH, the maintenance trade-off is especially visible because small configuration changes can have immediate operational effects. A preserved local file may be the right call, but only if the resulting service still supports the authentication paths, network reachability, and hardening choices your operators expect.
How to decide without breaking remote access
Start by comparing the local file against the vendor sample and any internal standard you use for remote access. Pay attention to the settings that affect reachability first, then the ones that affect security posture, because a locked-out host is a bigger immediate problem than a cosmetic difference.
When the local file contains only a few intentional changes, keep it and re-merge the package changes manually. When the local file is heavily modified and no longer matches a supportable pattern, adopt the maintainer version and reintroduce only the controls you can justify and test.
If the upgrade tool offers a merge view, use it to identify which lines are essential to preserve rather than treating the file as all-or-nothing. The safest outcome is usually a deliberate merge, not a default acceptance of either side.
Risk and Threat Considerations
SSH configuration is a high-value control point because it governs remote administrative access. A bad merge can weaken hardening, broaden who can log in, or leave a host unreachable at the exact moment you need access for recovery or incident response.
Failure mechanism: The maintainer file can replace local exceptions that were compensating for environment-specific needs, while an outdated local file can preserve insecure legacy settings or break authentication, port exposure, or host restrictions after upgrade.
Impact: You can end up with either expanded attack surface or loss of operational access. In practice, that means more exposure for brute force, misconfiguration, or privilege abuse, or a broken management path that delays remediation and recovery.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-4 — Secure Configuration | SSH config merges are secure configuration decisions. |
| Recommendation — Review and preserve only required SSH hardening settings during upgrades. | ||
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | The choice is about preserving or restoring a controlled configuration baseline. |
| CM-6 — Configuration Settings | SSH options like ports and login rules are configuration settings that affect security and access. | |
| Recommendation — Maintain an approved SSH baseline and reapply only justified local deviations. Validate SSH setting changes before accepting the maintainer version. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Upgrading SSH config requires controlled handling of configuration changes. |
| Recommendation — Apply configuration management to review, approve and document SSH file changes. | ||
| NIST CSF 2.0 | PR.IP-1 — Baseline Configurations | Keeping or replacing SSH config depends on managing a secure baseline. |
| Recommendation — Compare local SSH settings against the approved baseline before merging. | ||
Practitioner Guidance
What to verify: Before keeping the local file, confirm which differences are intentional and still required, especially any nondefault port, user restriction, authentication rule, or host allowance. If you cannot explain a deviation, treat it as drift rather than a control.
Decision rule: Keep the local version when it preserves a deliberate and tested security or access requirement. Replace it when the file is mostly stale, undocumented, or no longer aligned to how the service is actually administered.
Practitioner takeaway: The right choice is the one that preserves intended SSH access while removing accidental drift, because both overpreservation and overreplacement can create real operational and security harm.
Related resources from NHI Mgmt Group
- Guide: SSH Key and SSH Certificate Management Guide
- What breaks when developers keep long-lived SSH keys and secrets in local configuration instead of a managed workflow?
- What breaks when AI coding agents can execute from repository configuration instead of package installs?
- What breaks when organisations rely on package version checks without verifying what code actually runs during dependency installation?
- What breaks when organisations keep local admin rights in place instead of using just-in-time elevation?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org