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 during an upgrade
During upgrades, the local SSH configuration should be kept when it contains deliberate hardening or access decisions that the environment still depends on. The package maintainer’s version is usually the safer choice only when the existing file is stale, heavily modified without clear justification, or has drifted away from the supported baseline in ways that are hard to defend operationally.
SSH configuration is one of those files where continuity matters because a small change can affect remote access, maintenance access, and emergency recovery paths. If the local version encodes a nonstandard port, restricted source addresses, jump-host requirements, stronger ciphers, or other approved deviations, replacing it blindly can interrupt access or undo a control that was added for a reason.
That said, preserving the local file is not automatically the best security outcome. If the current configuration is old, inconsistent with current platform guidance, or full of one-off edits that no one can explain, the maintainer’s version may restore a known-good baseline and remove risky drift. The right decision is usually a comparison exercise, not a loyalty test between “local” and “package” copies.
What makes the local SSH file worth preserving?
The strongest reason to keep the local version is that it contains intentional, environment-specific controls that would be lost if overwritten. Common examples include access restrictions tied to network design, hardened authentication settings, logging choices, or compatibility settings required by existing tooling. Those changes may be small, but they can carry real operational and security value.
When assessing those differences, the question is whether the local settings are still actively serving the environment. A custom port, for example, is only worth preserving if it is part of an understood access model and not just legacy obscurity. Likewise, a hardening choice is only valuable if it is still compatible with current operational needs and does not block legitimate administrative workflows.
If the local file has been carefully maintained, the maintainer’s version may actually be less suitable because it reflects generic defaults rather than your actual security posture. In that case, keeping the local file preserves the documented intent of the system rather than forcing the machine back toward a configuration that was never designed for that deployment.
When the maintainer’s version is the better choice
Accept the maintainer’s version when the local file has drifted so far that it is effectively an unreviewed fork of the supported configuration. That usually shows up as accumulated edits, unclear ownership, or settings copied forward from older environments without a current rationale. In those cases, the upgrade is a good moment to realign with the supported default and then reapply only the differences that still matter.
The maintainer’s version is also preferable when the local file is known to be obsolete, incompatible with newer software behavior, or weakly documented. If the upgrade introduces new defaults or deprecates old options, keeping an outdated local file can preserve broken assumptions and create avoidable access problems after the reboot or service restart.
In practice, the safest decision is often to compare the local file against the packaged version line by line, keep only the meaningful deviations, and discard accidental cruft. That approach reduces the chance of preserving a hidden misconfiguration while still protecting the settings that genuinely support your access model.
Risk and Threat Considerations
SSH configuration changes can create immediate exposure if they alter how administrators reach the host or how attackers might abuse the service. A bad replacement can lock out legitimate operators, while a bad merge can leave weak authentication, wider exposure, or less restrictive access paths in place than intended.
Failure mechanism: Package upgrades may overwrite a locally hardened SSH policy, or they may preserve stale local edits that no longer match the current security baseline. Either outcome can undermine remote access reliability or weaken the control structure around the service.
Impact: The result can be service interruption, emergency access failure, exposure of management interfaces, or the persistence of insecure settings that should have been retired during the upgrade.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-6 — Configuration Settings | SSH upgrade choices hinge on preserving approved secure configuration settings. |
| CM-2 — Baseline Configuration | The question is about aligning a modified config with the maintained baseline. | |
| AC-17 — Remote Access | SSH directly governs remote administrative access to the host. | |
| Recommendation — Review and retain only approved SSH configuration deviations during upgrades. Compare local SSH settings against the approved baseline before accepting changes. Preserve SSH settings that enforce approved remote access restrictions. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | SSH package upgrades are a secure-configuration decision about preserving hardening. |
| CIS-6 — Access Control Management | SSH options often control who can reach administrative access paths. | |
| Recommendation — Validate SSH hardening settings before replacing the local configuration. Keep SSH restrictions that enforce approved administrative access paths. | ||
Practitioner Guidance
What to verify: Before choosing the local file, verify that each deviation from the package version has a current operational or security purpose. If you cannot explain why a setting exists, treat it as drift rather than a control.
Decision rule: Keep the local configuration when the differences are intentional, reviewed, and still necessary for secure administration. Prefer the maintainer’s version when the local file is stale, poorly understood, or difficult to reconcile with the current platform support model.
Practitioner takeaway: The goal is not to preserve local changes by default, but to preserve only the SSH settings that still represent deliberate, defensible control decisions.
Related resources from NHI Mgmt Group
- 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?
- When should organisations persist a user token in local storage instead of keeping it only in memory during development?
- Should organisations use SSH certificates instead of long-lived keys?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
