core.sshCommand is a Git configuration setting that controls which SSH command Git uses for network operations. When an attacker can inject or alter this value, Git may invoke a chosen executable instead of the intended trusted command. That makes it a sensitive execution control, not a harmless preference.
Expanded Definition
core.sshCommand is the Git configuration that determines which SSH command Git uses when it needs to reach a remote repository over SSH. It is not just a convenience setting: it changes the executable path Git trusts for that network action, so a modified value can redirect execution away from the expected system SSH client.
The important boundary is between transport selection and code execution. Git users often think of this as a connectivity preference, but the security interpretation is stricter because the setting influences what command is launched, with which arguments, and under whose trust boundary. That means the control belongs to execution hygiene and configuration integrity, not simply developer ergonomics.
Guidance versus consensus: there is broad agreement that repository and environment configuration should not be writable by untrusted actors, but implementations differ on how strictly Git config inheritance, local overrides, and wrapper scripts are governed. In practice, the common misunderstanding is to treat this as low-risk metadata even though it can alter the command Git invokes.
Examples and Use Cases
Git administrators and developers encounter core.sshCommand in a few common workflows. It is most often used to point Git at a non-default SSH binary, add a custom key path, or route connections through a wrapper that applies environment-specific options.
- A developer sets a per-repository SSH command so a project can use a dedicated key or jump host without changing global system settings.
- A build agent inherits a workspace configuration that changes Git’s SSH command, which can be useful for automation but dangerous if the workspace is writable by other processes.
- A platform team standardises Git access through a wrapper script to enforce logging or proxy behaviour, trading convenience for an additional trust dependency.
- An attacker who can edit repository-local configuration may replace the intended SSH command with a different executable, turning a network setting into an execution path.
That last case is why this setting deserves security review. The operational tradeoff is simple: more flexibility in transport handling usually means a larger configuration surface that must be protected from tampering.
For readers mapping this to non-human identity governance, the setting matters because automated Git workflows frequently use machine-owned credentials and unattended execution contexts. The relevant control question is whether the process launching Git can be trusted to preserve the intended command path.
Security Implications
When core.sshCommand is misunderstood, the failure mode is not merely a broken connection. The more serious outcome is that Git may execute an attacker-chosen command in place of the intended SSH client, which can lead to credential exposure, unexpected network behaviour, or arbitrary command execution in the context of the user or automation account.
Mismanagement also creates governance blind spots. A local config override, a malicious wrapper, or a compromised build workspace can silently change the trust boundary for repository access while leaving the Git operation looking normal from the outside. Symptoms may include unexplained outbound connections, unusual SSH arguments, failed key usage, or repository access that behaves differently across machines.
The practical consequence is blast-radius expansion. Once a Git workflow is used by CI jobs, deployment scripts, or shared developer images, a single configuration injection can affect many operations at once. That is why configuration integrity around command-invoking settings is a real security control, not a cosmetic preference.
Domain and Governance Relevance
In the primary cybersecurity domain, core.sshCommand is best understood as a command-selection control with configuration-integrity implications. It sits at the point where a network client decides which executable to trust, so the governance problem is ensuring that only approved settings can influence that decision.
Where NHIMG’s identity lens becomes relevant is in automated Git environments that rely on machine credentials, service accounts, or unattended repository access. In those contexts, tampering with the SSH command can undermine the trust model for non-human execution just as effectively as credential theft can. The issue is not that every Git setting is an identity control, but that this one can change how an identity-bearing automation path authenticates and connects.
The strongest governance rule is therefore simple: treat command-bearing Git configuration as an integrity-sensitive asset, especially where CI, deployment, or shared automation depends on stable, repeatable repository access.
OWASP Non-Human Identity Top 10 is useful here because it frames how machine-driven access paths become security-relevant when their execution context can be altered.
Risk and Threat Considerations
core.sshCommand has a material abuse risk because it controls which executable Git invokes for SSH-based network operations. If an attacker can alter the setting, they may redirect a trusted workflow into an untrusted command path and use that trust to reach credentials, internal repositories, or automation contexts.
Failure mechanism: The risk materialises through configuration injection, malicious repository-local settings, poisoned environment inheritance, or tampered wrapper scripts. Git then launches the attacker-influenced command instead of the intended SSH client, which creates an execution and trust-abuse path rather than a simple connectivity issue.
Impact: The impact can include arbitrary command execution in the user or automation context, disclosure of secrets handled by the Git workflow, unauthorized repository access, and persistence inside CI or developer environments through trusted configuration.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 4 — Secure Configuration of Enterprise Assets and Software | core.sshCommand is a configuration-integrity issue that can alter command execution. |
| Recommendation — Restrict and audit Git configuration paths that can change the executed SSH command. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorizations are Managed | Git SSH command control affects who or what can operate trusted access paths. |
| Recommendation — Constrain repository and workspace write access so untrusted actors cannot alter SSH execution settings. | ||
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | An altered SSH command can cause Git to invoke an attacker-chosen executable. |
| Recommendation — Hunt for unexpected child processes and command-line changes when Git launches SSH-related operations. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Automated Git access often depends on machine credentials exposed through the SSH path. |
| NHI-03 — Lifecycle and Inventory Management | The SSH command path is part of the managed trust surface for non-human access. | |
| Recommendation — Protect automation credentials by controlling the command path that Git uses to reach repositories. Inventory and review machine-access workflows that depend on custom Git SSH command settings. | ||
Practitioner Guidance
What to watch for: Treat unexpected changes to core.sshCommand as a security event, not a troubleshooting preference. The value should be reviewed wherever Git runs in shared, automated, or high-trust environments, because the setting can change the command path behind ordinary repository operations.
Governance implication: Ownership should sit with the team responsible for the execution environment, not only with individual developers. In practice, that means configuration sources, workspace write access, and inherited settings need to be governed as part of the system’s trust boundary.
Practitioner takeaway: If a Git workflow depends on unattended access, protect the configuration that selects the SSH command with the same care you apply to credentials and launch scripts.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
