From ffda036058f4ba8a0738e3e414e0cc1b7e684105 Mon Sep 17 00:00:00 2001 From: Dickson Date: Sun, 15 Mar 2026 23:09:40 -0400 Subject: [PATCH 01/20] Add SSH client and key management hardening guide --- docs/pages/guides/endpoint-security/index.mdx | 1 + ...sh-client-and-key-management-hardening.mdx | 280 ++++++++++++++++++ vocs.config.tsx | 1 + 3 files changed, 282 insertions(+) create mode 100644 docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx diff --git a/docs/pages/guides/endpoint-security/index.mdx b/docs/pages/guides/endpoint-security/index.mdx index f9f5eae7..03455e07 100644 --- a/docs/pages/guides/endpoint-security/index.mdx +++ b/docs/pages/guides/endpoint-security/index.mdx @@ -11,4 +11,5 @@ title: "Endpoint Security" ## Pages +- [SSH Client and Key Management Hardening](/guides/endpoint-security/ssh-client-and-key-management-hardening) - [Zoom Hardening Guide](/guides/endpoint-security/zoom-hardening) diff --git a/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx b/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx new file mode 100644 index 00000000..9b6305b2 --- /dev/null +++ b/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx @@ -0,0 +1,280 @@ +--- +title: "SSH Client and Key Management Hardening | Security Alliance" +description: "Harden SSH usage with modern key choices, passphrases, careful agent use, strict host verification, and clear revocation and rotation practices for Web3 teams." +tags: + - Engineer/Developer + - Security Specialist +contributors: + - role: wrote + users: [dickson] +--- + +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' + + + + +# SSH Client and Key Management Hardening + + + + +## Summary + +> 🔑 **Key Takeaway for SSH Client and Key Management Hardening:** Use dedicated SSH keys for distinct purposes, +> prefer Ed25519 for new software keys, use hardware-backed `*-sk` keys for higher-risk access where practical, +> protect keys with passphrases, keep agent forwarding off by default, and maintain a simple revoke-and-reissue plan +> for lost devices or role changes. + +SSH is often the path from a developer laptop into source control, CI/CD, bastions, deploy hosts, and production +infrastructure. In Web3 teams, the same workstation may be used to reach code hosting, cloud infrastructure, deploy +systems, incident-response paths, validators, or other sensitive environments, so SSH key handling should be treated +as a privileged access control rather than a convenience feature. + +This page focuses on **client-side SSH hardening** for local human use first, with a short section on automation and +team operations. It does not attempt to cover full `sshd` server hardening. + +--- + +## For Individuals + +These steps apply to developers, operators, admins, and contributors who use SSH from a local workstation. + +### Setup Checklist + +- [ ] Use **Ed25519** for new software keys by default +- [ ] Add a **strong passphrase** to every human-held software key +- [ ] For higher-risk access, prefer a **hardware-backed security-key SSH credential** such as `ed25519-sk` +- [ ] Keep separate keys for: + Git hosting, staging/internal infrastructure, production/bastion access, and automation +- [ ] Keep `ForwardAgent no` unless there is a specific and reviewed operational need +- [ ] Use explicit per-host entries in `~/.ssh/config` with `IdentityFile` and `IdentitiesOnly yes` +- [ ] Keep `StrictHostKeyChecking` enabled: + `accept-new` for normal low-risk hosts, `yes` for bastions and production systems where host verification + should be explicit +- [ ] Keep `UpdateHostKeys yes` enabled where you manage planned key rotation +- [ ] Keep `~/.ssh` and private key files accessible only to you +- [ ] Review and remove stale keys after device loss, role changes, or offboarding + +### Key Choice and Generation + +For new software keys, the practical default is **Ed25519**. It is the current modern baseline for general SSH use and +is widely supported by Git hosting providers and modern OpenSSH clients. + +If you need stronger protection for privileged access, use a hardware-backed security-key credential such as +`ed25519-sk` when your environment supports it. That keeps the private key material inside the authenticator and adds +user presence checks such as a touch. Treat this as a strong recommendation for production bastions, deploy access, +incident-response access, and other high-impact administrative paths. + +If a legacy service still requires RSA, use it only for compatibility and prefer modern SHA-2 signatures rather than +legacy RSA/SHA-1 behavior. + +Examples: + +```bash +# Default software key for normal human SSH use +ssh-keygen -t ed25519 -a 64 -C "name@org" + +# Hardware-backed key for higher-risk access when supported +ssh-keygen -t ed25519-sk -O verify-required -C "name@org prod" +``` + +### Passphrases and Local Protection + +A local private key should be treated as a password-equivalent credential. + +- Use a passphrase on every human-held software key +- Avoid leaving sensitive keys loaded into an agent indefinitely +- Prefer confirmation or time-limited agent loading for sensitive keys +- Do not store private keys in cloud notes, chat, or shared drives +- Avoid copying the same private key between multiple laptops or admin workstations + +If you use `ssh-agent`, tighter defaults are better than "load once and forget about it." Example: + +```bash +ssh-add -c -t 8h ~/.ssh/id_ed25519 +``` + +That pattern is safer than leaving a privileged key loaded without confirmation for an unlimited period. + +### `~/.ssh/config` Hygiene + +Keep `~/.ssh/config` explicit and purpose-specific so your SSH client offers only the intended key to each service. + +```text +Host github.com + HostName github.com + User git + IdentityFile ~/.ssh/id_ed25519_github + IdentitiesOnly yes + ForwardAgent no + StrictHostKeyChecking accept-new + UpdateHostKeys yes + +Host bastion-prod + HostName bastion.prod.example.org + User alice + IdentityFile ~/.ssh/id_ed25519_prod + IdentitiesOnly yes + ForwardAgent no + StrictHostKeyChecking yes + UpdateHostKeys yes +``` + +This approach reduces key sprawl, avoids offering the wrong identity to the wrong host, and makes it easier to reason +about which key is used for which environment. + +### Agent Forwarding and Remote Risk + +Treat agent forwarding as an exception, not a default workflow. + +- Keep `ForwardAgent no` by default +- Never use `Host *` with `ForwardAgent yes` +- Prefer `ProxyJump`, a bastion pattern, or a purpose-specific key on the intermediary host instead + +Agent forwarding can let a remote system use your loaded identities for as long as the session is live. That means it +is a poor default for attacker-controlled or weakly trusted systems. + +### Host Verification and `known_hosts` + +Do not normalize `StrictHostKeyChecking no` or "just click through" behavior for host key changes. + +- Verify important host fingerprints from official documentation when available +- Use `accept-new` only where trust-on-first-use is acceptable for the environment +- Use `yes` for bastions, production systems, and other high-sensitivity hosts where key verification should be pinned +- Preseed `known_hosts` for CI and automation from a trusted source instead of discovering keys live in the job +- Investigate unexpected host key changes instead of bypassing the warning + +Useful commands: + +```bash +# Find an existing host entry +ssh-keygen -F github.com + +# Remove an outdated host key entry +ssh-keygen -R github.com + +# Hash known_hosts entries for some additional privacy +ssh-keygen -H -f ~/.ssh/known_hosts +``` + +### File Permissions and Device Hygiene + +On Unix-like systems: + +- Keep `~/.ssh` owner-only +- Keep private keys readable only by the account owner +- Keep `~/.ssh/config` not writable by other users + +On Windows, the operating system enforces protection through the Windows security model and ACLs rather than Unix +`chmod` conventions, but the principle is the same: private keys are sensitive credentials and should not be broadly +accessible. + +If a laptop is lost, stolen, or suspected compromised, assume the SSH material on it may also need to be revoked and +reissued. + +--- + +## For Team Members + +These guidelines apply to people using SSH for work-owned repositories, infrastructure, and production systems. + +Team members should: + +- Use separate keys for code hosting and infrastructure access instead of reusing one key everywhere +- Label keys clearly so review and revocation are straightforward +- Avoid using personal unmanaged devices for privileged SSH access unless there is explicit approval +- Report unexpected host key changes, access prompts, or pressure to enable agent forwarding +- Reissue keys promptly after laptop replacement, loss, compromise, or major role change +- Keep Git hosting keys separate from production admin keys + +--- + +## For Admins + +These practices apply to administrators responsible for issuing, reviewing, rotating, and revoking SSH access across a +team. + +### Program Checklist + +- [ ] Maintain an inventory for each SSH credential: + owner, device, purpose, target systems, creation date, and revoke trigger +- [ ] Require one key per person, device, and purpose instead of shared identities +- [ ] Prefer hardware-backed SSH credentials for privileged production access where practical +- [ ] Review account SSH keys, deploy keys, and automation keys on a regular cadence +- [ ] Remove unknown, stale, or unapproved keys during access reviews +- [ ] Revoke keys immediately after offboarding, device loss, or suspected compromise +- [ ] Keep human access and automation access logically separate +- [ ] Document a simple recovery and reissue process for lost devices and security keys + +### Git Hosting, CI/CD, and Automation + +Git hosting access should not be treated the same way as production administration. + +- Human users should have account-level SSH keys with clear labels +- CI/CD and deployment systems should use dedicated automation credentials, not a developer's personal laptop key +- Review deploy keys carefully because they are often long-lived and narrowly scoped but easy to forget +- Where the platform supports it, evaluate stronger centralized patterns such as GitHub Apps instead of relying on + long-lived deploy keys for Git-only automation + +For Web3 teams, this matters because SSH credentials often become a control point into deployment pipelines, validator +operations, RPC infrastructure, or incident-response systems. + +### Team Lifecycle and Revocation + +Make revocation and reissue routine, not just theoretical. + +When a device is lost, stolen, or potentially compromised: + +1. Revoke the affected Git hosting SSH keys. +2. Remove or disable server-side access for the affected key. +3. Replace any deploy or automation key that may have been exposed. +4. Reissue fresh credentials from a clean device. +5. Review bastion, repository, and infrastructure access logs for suspicious use. + +### Optional Advanced Model: SSH Certificates + +Larger teams may want a more centralized lifecycle than manually distributing raw public keys to each host. + +OpenSSH user certificates can improve issuance and revocation by letting systems trust a central SSH certificate +authority instead of many individual static keys. This is most useful for larger fleets or short-lived privileged +access, but it adds operational overhead and should only be adopted if the team is prepared to run the lifecycle well. + +--- + +## Web3-Specific Operational Rules + +Use these rules consistently: + +1. Do not use the same SSH key for Git hosting, deploy systems, and production administration. +2. Treat bastion, production, and incident-response SSH access as privileged and higher assurance. +3. Keep agent forwarding off unless there is a reviewed exception. +4. Investigate host key changes before reconnecting to important systems. +5. Revoke and replace SSH keys immediately after device loss or admin-role changes. +6. Keep automation credentials separate from human workstation credentials. + +--- + +## Related Guides + +- [GitHub Security](/guides/account-management/github) +- [Lessons Learned](/incident-management/lessons-learned) +- [Understanding Threat Vectors](/awareness/understanding-threat-vectors) + +## Further Reading + +- [NIST IR 7966: Security of Interactive and Automated Access Management Using Secure Shell (SSH)](https://csrc.nist.gov/pubs/ir/7966/final) +- [OpenBSD `ssh_config(5)`](https://man.openbsd.org/ssh_config) +- [OpenBSD `ssh-keygen(1)`](https://man.openbsd.org/ssh-keygen.1) +- [OpenBSD `ssh-add(1)`](https://man.openbsd.org/ssh-add.1) +- [GitHub: Generating a New SSH Key and Adding It to the SSH Agent](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent) +- [GitHub: Reviewing Your SSH Keys](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/reviewing-your-ssh-keys) +- [GitHub: GitHub's SSH Key Fingerprints](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/githubs-ssh-key-fingerprints) +- [GitLab: SSH Keys](https://docs.gitlab.com/user/ssh/) +- [GitLab: Using SSH Keys with GitLab CI/CD](https://docs.gitlab.com/ci/jobs/ssh_keys/) +- [Microsoft Learn: OpenSSH Key Management on Windows](https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_keymanagement) + +--- + + + diff --git a/vocs.config.tsx b/vocs.config.tsx index 0a0ec17f..a11a42fa 100644 --- a/vocs.config.tsx +++ b/vocs.config.tsx @@ -493,6 +493,7 @@ const config = { text: 'Endpoint Security', collapsed: true, items: [ + { text: 'SSH Client and Key Management Hardening', link: '/guides/endpoint-security/ssh-client-and-key-management-hardening' }, { text: 'Zoom Hardening', link: '/guides/endpoint-security/zoom-hardening' }, ] }, From 6258a37d1223e3fb9b32ec20ab9bc03bf4c34b62 Mon Sep 17 00:00:00 2001 From: Dickson Date: Fri, 20 Mar 2026 23:10:45 -0400 Subject: [PATCH 02/20] Remove decorative separators from SSH hardening guide --- .../ssh-client-and-key-management-hardening.mdx | 15 --------------- 1 file changed, 15 deletions(-) diff --git a/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx b/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx index 9b6305b2..e9cbe316 100644 --- a/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx +++ b/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx @@ -33,9 +33,6 @@ as a privileged access control rather than a convenience feature. This page focuses on **client-side SSH hardening** for local human use first, with a short section on automation and team operations. It does not attempt to cover full `sshd` server hardening. - ---- - ## For Individuals These steps apply to developers, operators, admins, and contributors who use SSH from a local workstation. @@ -187,9 +184,6 @@ Team members should: - Report unexpected host key changes, access prompts, or pressure to enable agent forwarding - Reissue keys promptly after laptop replacement, loss, compromise, or major role change - Keep Git hosting keys separate from production admin keys - ---- - ## For Admins These practices apply to administrators responsible for issuing, reviewing, rotating, and revoking SSH access across a @@ -239,9 +233,6 @@ Larger teams may want a more centralized lifecycle than manually distributing ra OpenSSH user certificates can improve issuance and revocation by letting systems trust a central SSH certificate authority instead of many individual static keys. This is most useful for larger fleets or short-lived privileged access, but it adds operational overhead and should only be adopted if the team is prepared to run the lifecycle well. - ---- - ## Web3-Specific Operational Rules Use these rules consistently: @@ -252,9 +243,6 @@ Use these rules consistently: 4. Investigate host key changes before reconnecting to important systems. 5. Revoke and replace SSH keys immediately after device loss or admin-role changes. 6. Keep automation credentials separate from human workstation credentials. - ---- - ## Related Guides - [GitHub Security](/guides/account-management/github) @@ -273,8 +261,5 @@ Use these rules consistently: - [GitLab: SSH Keys](https://docs.gitlab.com/user/ssh/) - [GitLab: Using SSH Keys with GitLab CI/CD](https://docs.gitlab.com/ci/jobs/ssh_keys/) - [Microsoft Learn: OpenSSH Key Management on Windows](https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_keymanagement) - ---- - From d59a605da62af4b282cded8dd31fea0b7a3d131a Mon Sep 17 00:00:00 2001 From: Dickson Date: Fri, 20 Mar 2026 23:25:50 -0400 Subject: [PATCH 03/20] Fix markdownlint spacing in SSH hardening guide --- .../ssh-client-and-key-management-hardening.mdx | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx b/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx index e9cbe316..d7ff8737 100644 --- a/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx +++ b/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx @@ -33,6 +33,7 @@ as a privileged access control rather than a convenience feature. This page focuses on **client-side SSH hardening** for local human use first, with a short section on automation and team operations. It does not attempt to cover full `sshd` server hardening. + ## For Individuals These steps apply to developers, operators, admins, and contributors who use SSH from a local workstation. @@ -184,6 +185,7 @@ Team members should: - Report unexpected host key changes, access prompts, or pressure to enable agent forwarding - Reissue keys promptly after laptop replacement, loss, compromise, or major role change - Keep Git hosting keys separate from production admin keys + ## For Admins These practices apply to administrators responsible for issuing, reviewing, rotating, and revoking SSH access across a @@ -233,6 +235,7 @@ Larger teams may want a more centralized lifecycle than manually distributing ra OpenSSH user certificates can improve issuance and revocation by letting systems trust a central SSH certificate authority instead of many individual static keys. This is most useful for larger fleets or short-lived privileged access, but it adds operational overhead and should only be adopted if the team is prepared to run the lifecycle well. + ## Web3-Specific Operational Rules Use these rules consistently: @@ -243,6 +246,7 @@ Use these rules consistently: 4. Investigate host key changes before reconnecting to important systems. 5. Revoke and replace SSH keys immediately after device loss or admin-role changes. 6. Keep automation credentials separate from human workstation credentials. + ## Related Guides - [GitHub Security](/guides/account-management/github) @@ -261,5 +265,6 @@ Use these rules consistently: - [GitLab: SSH Keys](https://docs.gitlab.com/user/ssh/) - [GitLab: Using SSH Keys with GitLab CI/CD](https://docs.gitlab.com/ci/jobs/ssh_keys/) - [Microsoft Learn: OpenSSH Key Management on Windows](https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_keymanagement) + From e55cdc32b02d5971dd43d09a3b035f388166a0b3 Mon Sep 17 00:00:00 2001 From: Dickson Date: Fri, 20 Mar 2026 23:56:30 -0400 Subject: [PATCH 04/20] Tighten SSH hardening guide --- ...sh-client-and-key-management-hardening.mdx | 24 ------------------- 1 file changed, 24 deletions(-) diff --git a/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx b/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx index d7ff8737..73bf9e24 100644 --- a/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx +++ b/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx @@ -31,9 +31,6 @@ infrastructure. In Web3 teams, the same workstation may be used to reach code ho systems, incident-response paths, validators, or other sensitive environments, so SSH key handling should be treated as a privileged access control rather than a convenience feature. -This page focuses on **client-side SSH hardening** for local human use first, with a short section on automation and -team operations. It does not attempt to cover full `sshd` server hardening. - ## For Individuals These steps apply to developers, operators, admins, and contributors who use SSH from a local workstation. @@ -171,21 +168,6 @@ accessible. If a laptop is lost, stolen, or suspected compromised, assume the SSH material on it may also need to be revoked and reissued. ---- - -## For Team Members - -These guidelines apply to people using SSH for work-owned repositories, infrastructure, and production systems. - -Team members should: - -- Use separate keys for code hosting and infrastructure access instead of reusing one key everywhere -- Label keys clearly so review and revocation are straightforward -- Avoid using personal unmanaged devices for privileged SSH access unless there is explicit approval -- Report unexpected host key changes, access prompts, or pressure to enable agent forwarding -- Reissue keys promptly after laptop replacement, loss, compromise, or major role change -- Keep Git hosting keys separate from production admin keys - ## For Admins These practices apply to administrators responsible for issuing, reviewing, rotating, and revoking SSH access across a @@ -247,12 +229,6 @@ Use these rules consistently: 5. Revoke and replace SSH keys immediately after device loss or admin-role changes. 6. Keep automation credentials separate from human workstation credentials. -## Related Guides - -- [GitHub Security](/guides/account-management/github) -- [Lessons Learned](/incident-management/lessons-learned) -- [Understanding Threat Vectors](/awareness/understanding-threat-vectors) - ## Further Reading - [NIST IR 7966: Security of Interactive and Automated Access Management Using Secure Shell (SSH)](https://csrc.nist.gov/pubs/ir/7966/final) From 932c78dbe825f1fa47b39eddb06dbce4b2e79a29 Mon Sep 17 00:00:00 2001 From: Dickson Date: Sat, 21 Mar 2026 00:28:24 -0400 Subject: [PATCH 05/20] Shorten SSH hardening guide --- ...sh-client-and-key-management-hardening.mdx | 121 ++---------------- 1 file changed, 14 insertions(+), 107 deletions(-) diff --git a/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx b/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx index 73bf9e24..674d2fdf 100644 --- a/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx +++ b/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx @@ -1,6 +1,6 @@ --- title: "SSH Client and Key Management Hardening | Security Alliance" -description: "Harden SSH usage with modern key choices, passphrases, careful agent use, strict host verification, and clear revocation and rotation practices for Web3 teams." +description: "Harden SSH client usage with better key handling, agent discipline, host verification, and rotation." tags: - Engineer/Developer - Security Specialist @@ -26,10 +26,8 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr > protect keys with passphrases, keep agent forwarding off by default, and maintain a simple revoke-and-reissue plan > for lost devices or role changes. -SSH is often the path from a developer laptop into source control, CI/CD, bastions, deploy hosts, and production -infrastructure. In Web3 teams, the same workstation may be used to reach code hosting, cloud infrastructure, deploy -systems, incident-response paths, validators, or other sensitive environments, so SSH key handling should be treated -as a privileged access control rather than a convenience feature. +SSH is often the path from a developer laptop into code hosting, CI/CD, bastions, and production infrastructure. Treat +SSH keys as privileged access, not just as a convenience feature. ## For Individuals @@ -53,71 +51,25 @@ These steps apply to developers, operators, admins, and contributors who use SSH ### Key Choice and Generation -For new software keys, the practical default is **Ed25519**. It is the current modern baseline for general SSH use and -is widely supported by Git hosting providers and modern OpenSSH clients. - -If you need stronger protection for privileged access, use a hardware-backed security-key credential such as -`ed25519-sk` when your environment supports it. That keeps the private key material inside the authenticator and adds -user presence checks such as a touch. Treat this as a strong recommendation for production bastions, deploy access, -incident-response access, and other high-impact administrative paths. - -If a legacy service still requires RSA, use it only for compatibility and prefer modern SHA-2 signatures rather than -legacy RSA/SHA-1 behavior. - -Examples: - -```bash -# Default software key for normal human SSH use -ssh-keygen -t ed25519 -a 64 -C "name@org" - -# Hardware-backed key for higher-risk access when supported -ssh-keygen -t ed25519-sk -O verify-required -C "name@org prod" -``` +- Use **Ed25519** for new software keys by default +- Use hardware-backed credentials such as `ed25519-sk` for higher-risk access when your environment supports them +- If a legacy service still requires RSA, treat it as compatibility-only and prefer modern SHA-2 signatures ### Passphrases and Local Protection -A local private key should be treated as a password-equivalent credential. - - Use a passphrase on every human-held software key - Avoid leaving sensitive keys loaded into an agent indefinitely - Prefer confirmation or time-limited agent loading for sensitive keys - Do not store private keys in cloud notes, chat, or shared drives - Avoid copying the same private key between multiple laptops or admin workstations -If you use `ssh-agent`, tighter defaults are better than "load once and forget about it." Example: - -```bash -ssh-add -c -t 8h ~/.ssh/id_ed25519 -``` - -That pattern is safer than leaving a privileged key loaded without confirmation for an unlimited period. - ### `~/.ssh/config` Hygiene Keep `~/.ssh/config` explicit and purpose-specific so your SSH client offers only the intended key to each service. -```text -Host github.com - HostName github.com - User git - IdentityFile ~/.ssh/id_ed25519_github - IdentitiesOnly yes - ForwardAgent no - StrictHostKeyChecking accept-new - UpdateHostKeys yes - -Host bastion-prod - HostName bastion.prod.example.org - User alice - IdentityFile ~/.ssh/id_ed25519_prod - IdentitiesOnly yes - ForwardAgent no - StrictHostKeyChecking yes - UpdateHostKeys yes -``` - -This approach reduces key sprawl, avoids offering the wrong identity to the wrong host, and makes it easier to reason -about which key is used for which environment. +- Use per-host entries with `IdentityFile` and `IdentitiesOnly yes` +- Keep `ForwardAgent no` unless there is a reviewed exception +- Use stricter host verification for bastions and production hosts than for low-risk systems ### Agent Forwarding and Remote Risk @@ -127,8 +79,8 @@ Treat agent forwarding as an exception, not a default workflow. - Never use `Host *` with `ForwardAgent yes` - Prefer `ProxyJump`, a bastion pattern, or a purpose-specific key on the intermediary host instead -Agent forwarding can let a remote system use your loaded identities for as long as the session is live. That means it -is a poor default for attacker-controlled or weakly trusted systems. +Agent forwarding lets a remote system use your loaded identities for as long as the session is live, so it is a poor +default for weakly trusted systems. ### Host Verification and `known_hosts` @@ -136,35 +88,16 @@ Do not normalize `StrictHostKeyChecking no` or "just click through" behavior for - Verify important host fingerprints from official documentation when available - Use `accept-new` only where trust-on-first-use is acceptable for the environment -- Use `yes` for bastions, production systems, and other high-sensitivity hosts where key verification should be pinned +- Use `yes` for bastions, production systems, and other high-sensitivity hosts - Preseed `known_hosts` for CI and automation from a trusted source instead of discovering keys live in the job - Investigate unexpected host key changes instead of bypassing the warning -Useful commands: - -```bash -# Find an existing host entry -ssh-keygen -F github.com - -# Remove an outdated host key entry -ssh-keygen -R github.com - -# Hash known_hosts entries for some additional privacy -ssh-keygen -H -f ~/.ssh/known_hosts -``` - ### File Permissions and Device Hygiene -On Unix-like systems: - - Keep `~/.ssh` owner-only - Keep private keys readable only by the account owner - Keep `~/.ssh/config` not writable by other users -On Windows, the operating system enforces protection through the Windows security model and ACLs rather than Unix -`chmod` conventions, but the principle is the same: private keys are sensitive credentials and should not be broadly -accessible. - If a laptop is lost, stolen, or suspected compromised, assume the SSH material on it may also need to be revoked and reissued. @@ -187,36 +120,10 @@ team. ### Git Hosting, CI/CD, and Automation -Git hosting access should not be treated the same way as production administration. - - Human users should have account-level SSH keys with clear labels - CI/CD and deployment systems should use dedicated automation credentials, not a developer's personal laptop key -- Review deploy keys carefully because they are often long-lived and narrowly scoped but easy to forget -- Where the platform supports it, evaluate stronger centralized patterns such as GitHub Apps instead of relying on - long-lived deploy keys for Git-only automation - -For Web3 teams, this matters because SSH credentials often become a control point into deployment pipelines, validator -operations, RPC infrastructure, or incident-response systems. - -### Team Lifecycle and Revocation - -Make revocation and reissue routine, not just theoretical. - -When a device is lost, stolen, or potentially compromised: - -1. Revoke the affected Git hosting SSH keys. -2. Remove or disable server-side access for the affected key. -3. Replace any deploy or automation key that may have been exposed. -4. Reissue fresh credentials from a clean device. -5. Review bastion, repository, and infrastructure access logs for suspicious use. - -### Optional Advanced Model: SSH Certificates - -Larger teams may want a more centralized lifecycle than manually distributing raw public keys to each host. - -OpenSSH user certificates can improve issuance and revocation by letting systems trust a central SSH certificate -authority instead of many individual static keys. This is most useful for larger fleets or short-lived privileged -access, but it adds operational overhead and should only be adopted if the team is prepared to run the lifecycle well. +- Review deploy keys carefully because they are often long-lived and easy to forget +- Revoke and reissue keys promptly after device loss, offboarding, or suspected compromise ## Web3-Specific Operational Rules From 7b153ee3b7246ffb2c66df85ea4107f12ff8107a Mon Sep 17 00:00:00 2001 From: Dickson Date: Sat, 21 Mar 2026 17:25:24 -0400 Subject: [PATCH 06/20] Clarify SSH hardening guidance --- .../ssh-client-and-key-management-hardening.mdx | 14 ++++---------- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx b/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx index 674d2fdf..ec23b59d 100644 --- a/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx +++ b/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx @@ -27,7 +27,7 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr > for lost devices or role changes. SSH is often the path from a developer laptop into code hosting, CI/CD, bastions, and production infrastructure. Treat -SSH keys as privileged access, not just as a convenience feature. +SSH keys as privileged access. ## For Individuals @@ -49,12 +49,6 @@ These steps apply to developers, operators, admins, and contributors who use SSH - [ ] Keep `~/.ssh` and private key files accessible only to you - [ ] Review and remove stale keys after device loss, role changes, or offboarding -### Key Choice and Generation - -- Use **Ed25519** for new software keys by default -- Use hardware-backed credentials such as `ed25519-sk` for higher-risk access when your environment supports them -- If a legacy service still requires RSA, treat it as compatibility-only and prefer modern SHA-2 signatures - ### Passphrases and Local Protection - Use a passphrase on every human-held software key @@ -94,9 +88,9 @@ Do not normalize `StrictHostKeyChecking no` or "just click through" behavior for ### File Permissions and Device Hygiene -- Keep `~/.ssh` owner-only -- Keep private keys readable only by the account owner -- Keep `~/.ssh/config` not writable by other users +- On Unix-like systems, use `chmod 700 ~/.ssh` +- Use `chmod 600` for private keys and for `~/.ssh/config` +- On Windows, keep private keys readable only by your user account and administrators If a laptop is lost, stolen, or suspected compromised, assume the SSH material on it may also need to be revoked and reissued. From 102ec36df1367768129e986c62d9907cb0cd58d2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mat=C3=ADas=20Aereal=20Ae=C3=B3n?= <388605+mattaereal@users.noreply.github.com> Date: Mon, 23 Mar 2026 17:52:41 -0300 Subject: [PATCH 07/20] Introduce SSH certificates for better key management Added a section on using SSH certificates for improved access management. --- .../ssh-client-and-key-management-hardening.mdx | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx b/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx index ec23b59d..c6bea544 100644 --- a/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx +++ b/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx @@ -119,6 +119,22 @@ team. - Review deploy keys carefully because they are often long-lived and easy to forget - Revoke and reissue keys promptly after device loss, offboarding, or suspected compromise +### Higher-Maturity Option: SSH Certificates + +For larger teams or higher-sensitivity environments, consider using SSH certificates instead of managing long-lived +authorized keys on each target system. + +With SSH certificates, a trusted internal certificate authority (CA) signs user or host keys for a limited period +of time. This can make access management easier by allowing teams to: + +- Issue short-lived SSH access without distributing permanent keys to every host +- Centralize approval, expiration, and revocation workflows +- Reduce the operational burden of updating `authorized_keys` across many systems +- Tie SSH access more closely to role, device, or incident-response requirements + +SSH certificates introduce their own operational complexity and should be implemented carefully, but they are worth +evaluating for organizations that need stronger central control over SSH access. + ## Web3-Specific Operational Rules Use these rules consistently: From a93f2db492511c0e66c1a0e9ef0c9a6a230ed9a7 Mon Sep 17 00:00:00 2001 From: Dickson Date: Mon, 23 Mar 2026 23:38:14 -0400 Subject: [PATCH 08/20] Clarify SSH host verification guidance --- .../ssh-client-and-key-management-hardening.mdx | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx b/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx index c6bea544..551bf90f 100644 --- a/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx +++ b/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx @@ -43,9 +43,10 @@ These steps apply to developers, operators, admins, and contributors who use SSH - [ ] Keep `ForwardAgent no` unless there is a specific and reviewed operational need - [ ] Use explicit per-host entries in `~/.ssh/config` with `IdentityFile` and `IdentitiesOnly yes` - [ ] Keep `StrictHostKeyChecking` enabled: - `accept-new` for normal low-risk hosts, `yes` for bastions and production systems where host verification - should be explicit -- [ ] Keep `UpdateHostKeys yes` enabled where you manage planned key rotation + use `accept-new` only for lower-risk hosts where trust-on-first-use is acceptable, and use `yes` for bastions + and production systems where host verification should be explicit +- [ ] Use `UpdateHostKeys yes` only for hosts you already trust and manage, especially where you expect planned key + rotation - [ ] Keep `~/.ssh` and private key files accessible only to you - [ ] Review and remove stale keys after device loss, role changes, or offboarding @@ -83,6 +84,7 @@ Do not normalize `StrictHostKeyChecking no` or "just click through" behavior for - Verify important host fingerprints from official documentation when available - Use `accept-new` only where trust-on-first-use is acceptable for the environment - Use `yes` for bastions, production systems, and other high-sensitivity hosts +- Do not rely on `accept-new` for first contact with high-sensitivity systems - Preseed `known_hosts` for CI and automation from a trusted source instead of discovering keys live in the job - Investigate unexpected host key changes instead of bypassing the warning From e0ef51daca353b63905a9631f15f7269bbba309f Mon Sep 17 00:00:00 2001 From: Dickson Date: Mon, 23 Mar 2026 23:44:24 -0400 Subject: [PATCH 09/20] Fix SSH guide markdown formatting --- .../ssh-client-and-key-management-hardening.mdx | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx b/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx index 551bf90f..2c6dd8b9 100644 --- a/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx +++ b/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx @@ -123,10 +123,10 @@ team. ### Higher-Maturity Option: SSH Certificates -For larger teams or higher-sensitivity environments, consider using SSH certificates instead of managing long-lived +For larger teams or higher-sensitivity environments, consider using SSH certificates instead of managing long-lived authorized keys on each target system. -With SSH certificates, a trusted internal certificate authority (CA) signs user or host keys for a limited period +With SSH certificates, a trusted internal certificate authority (CA) signs user or host keys for a limited period of time. This can make access management easier by allowing teams to: - Issue short-lived SSH access without distributing permanent keys to every host @@ -134,7 +134,7 @@ of time. This can make access management easier by allowing teams to: - Reduce the operational burden of updating `authorized_keys` across many systems - Tie SSH access more closely to role, device, or incident-response requirements -SSH certificates introduce their own operational complexity and should be implemented carefully, but they are worth +SSH certificates introduce their own operational complexity and should be implemented carefully, but they are worth evaluating for organizations that need stronger central control over SSH access. ## Web3-Specific Operational Rules From b02f98ef1ffcb8b5d31b0bd332e988d660e8219f Mon Sep 17 00:00:00 2001 From: Dickson Date: Mon, 23 Mar 2026 23:45:22 -0400 Subject: [PATCH 10/20] Finish SSH guide review fixes --- wordlist.txt | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/wordlist.txt b/wordlist.txt index 88e7f2d6..5cadf5bd 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -307,3 +307,9 @@ reauthentication CAIP unbonding unbond +GitHub +GitLab +GoDaddy +godaddy +NCSC +Opsek From 13355b09f0324a618ea42cc2b730c044568a30c7 Mon Sep 17 00:00:00 2001 From: Dickson Date: Sun, 15 Mar 2026 23:09:40 -0400 Subject: [PATCH 11/20] Add SSH client and key management hardening guide --- docs/pages/guides/endpoint-security/index.mdx | 1 + ...sh-client-and-key-management-hardening.mdx | 280 ++++++++++++++++++ vocs.config.tsx | 1 + 3 files changed, 282 insertions(+) create mode 100644 docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx diff --git a/docs/pages/guides/endpoint-security/index.mdx b/docs/pages/guides/endpoint-security/index.mdx index f9f5eae7..03455e07 100644 --- a/docs/pages/guides/endpoint-security/index.mdx +++ b/docs/pages/guides/endpoint-security/index.mdx @@ -11,4 +11,5 @@ title: "Endpoint Security" ## Pages +- [SSH Client and Key Management Hardening](/guides/endpoint-security/ssh-client-and-key-management-hardening) - [Zoom Hardening Guide](/guides/endpoint-security/zoom-hardening) diff --git a/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx b/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx new file mode 100644 index 00000000..9b6305b2 --- /dev/null +++ b/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx @@ -0,0 +1,280 @@ +--- +title: "SSH Client and Key Management Hardening | Security Alliance" +description: "Harden SSH usage with modern key choices, passphrases, careful agent use, strict host verification, and clear revocation and rotation practices for Web3 teams." +tags: + - Engineer/Developer + - Security Specialist +contributors: + - role: wrote + users: [dickson] +--- + +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' + + + + +# SSH Client and Key Management Hardening + + + + +## Summary + +> 🔑 **Key Takeaway for SSH Client and Key Management Hardening:** Use dedicated SSH keys for distinct purposes, +> prefer Ed25519 for new software keys, use hardware-backed `*-sk` keys for higher-risk access where practical, +> protect keys with passphrases, keep agent forwarding off by default, and maintain a simple revoke-and-reissue plan +> for lost devices or role changes. + +SSH is often the path from a developer laptop into source control, CI/CD, bastions, deploy hosts, and production +infrastructure. In Web3 teams, the same workstation may be used to reach code hosting, cloud infrastructure, deploy +systems, incident-response paths, validators, or other sensitive environments, so SSH key handling should be treated +as a privileged access control rather than a convenience feature. + +This page focuses on **client-side SSH hardening** for local human use first, with a short section on automation and +team operations. It does not attempt to cover full `sshd` server hardening. + +--- + +## For Individuals + +These steps apply to developers, operators, admins, and contributors who use SSH from a local workstation. + +### Setup Checklist + +- [ ] Use **Ed25519** for new software keys by default +- [ ] Add a **strong passphrase** to every human-held software key +- [ ] For higher-risk access, prefer a **hardware-backed security-key SSH credential** such as `ed25519-sk` +- [ ] Keep separate keys for: + Git hosting, staging/internal infrastructure, production/bastion access, and automation +- [ ] Keep `ForwardAgent no` unless there is a specific and reviewed operational need +- [ ] Use explicit per-host entries in `~/.ssh/config` with `IdentityFile` and `IdentitiesOnly yes` +- [ ] Keep `StrictHostKeyChecking` enabled: + `accept-new` for normal low-risk hosts, `yes` for bastions and production systems where host verification + should be explicit +- [ ] Keep `UpdateHostKeys yes` enabled where you manage planned key rotation +- [ ] Keep `~/.ssh` and private key files accessible only to you +- [ ] Review and remove stale keys after device loss, role changes, or offboarding + +### Key Choice and Generation + +For new software keys, the practical default is **Ed25519**. It is the current modern baseline for general SSH use and +is widely supported by Git hosting providers and modern OpenSSH clients. + +If you need stronger protection for privileged access, use a hardware-backed security-key credential such as +`ed25519-sk` when your environment supports it. That keeps the private key material inside the authenticator and adds +user presence checks such as a touch. Treat this as a strong recommendation for production bastions, deploy access, +incident-response access, and other high-impact administrative paths. + +If a legacy service still requires RSA, use it only for compatibility and prefer modern SHA-2 signatures rather than +legacy RSA/SHA-1 behavior. + +Examples: + +```bash +# Default software key for normal human SSH use +ssh-keygen -t ed25519 -a 64 -C "name@org" + +# Hardware-backed key for higher-risk access when supported +ssh-keygen -t ed25519-sk -O verify-required -C "name@org prod" +``` + +### Passphrases and Local Protection + +A local private key should be treated as a password-equivalent credential. + +- Use a passphrase on every human-held software key +- Avoid leaving sensitive keys loaded into an agent indefinitely +- Prefer confirmation or time-limited agent loading for sensitive keys +- Do not store private keys in cloud notes, chat, or shared drives +- Avoid copying the same private key between multiple laptops or admin workstations + +If you use `ssh-agent`, tighter defaults are better than "load once and forget about it." Example: + +```bash +ssh-add -c -t 8h ~/.ssh/id_ed25519 +``` + +That pattern is safer than leaving a privileged key loaded without confirmation for an unlimited period. + +### `~/.ssh/config` Hygiene + +Keep `~/.ssh/config` explicit and purpose-specific so your SSH client offers only the intended key to each service. + +```text +Host github.com + HostName github.com + User git + IdentityFile ~/.ssh/id_ed25519_github + IdentitiesOnly yes + ForwardAgent no + StrictHostKeyChecking accept-new + UpdateHostKeys yes + +Host bastion-prod + HostName bastion.prod.example.org + User alice + IdentityFile ~/.ssh/id_ed25519_prod + IdentitiesOnly yes + ForwardAgent no + StrictHostKeyChecking yes + UpdateHostKeys yes +``` + +This approach reduces key sprawl, avoids offering the wrong identity to the wrong host, and makes it easier to reason +about which key is used for which environment. + +### Agent Forwarding and Remote Risk + +Treat agent forwarding as an exception, not a default workflow. + +- Keep `ForwardAgent no` by default +- Never use `Host *` with `ForwardAgent yes` +- Prefer `ProxyJump`, a bastion pattern, or a purpose-specific key on the intermediary host instead + +Agent forwarding can let a remote system use your loaded identities for as long as the session is live. That means it +is a poor default for attacker-controlled or weakly trusted systems. + +### Host Verification and `known_hosts` + +Do not normalize `StrictHostKeyChecking no` or "just click through" behavior for host key changes. + +- Verify important host fingerprints from official documentation when available +- Use `accept-new` only where trust-on-first-use is acceptable for the environment +- Use `yes` for bastions, production systems, and other high-sensitivity hosts where key verification should be pinned +- Preseed `known_hosts` for CI and automation from a trusted source instead of discovering keys live in the job +- Investigate unexpected host key changes instead of bypassing the warning + +Useful commands: + +```bash +# Find an existing host entry +ssh-keygen -F github.com + +# Remove an outdated host key entry +ssh-keygen -R github.com + +# Hash known_hosts entries for some additional privacy +ssh-keygen -H -f ~/.ssh/known_hosts +``` + +### File Permissions and Device Hygiene + +On Unix-like systems: + +- Keep `~/.ssh` owner-only +- Keep private keys readable only by the account owner +- Keep `~/.ssh/config` not writable by other users + +On Windows, the operating system enforces protection through the Windows security model and ACLs rather than Unix +`chmod` conventions, but the principle is the same: private keys are sensitive credentials and should not be broadly +accessible. + +If a laptop is lost, stolen, or suspected compromised, assume the SSH material on it may also need to be revoked and +reissued. + +--- + +## For Team Members + +These guidelines apply to people using SSH for work-owned repositories, infrastructure, and production systems. + +Team members should: + +- Use separate keys for code hosting and infrastructure access instead of reusing one key everywhere +- Label keys clearly so review and revocation are straightforward +- Avoid using personal unmanaged devices for privileged SSH access unless there is explicit approval +- Report unexpected host key changes, access prompts, or pressure to enable agent forwarding +- Reissue keys promptly after laptop replacement, loss, compromise, or major role change +- Keep Git hosting keys separate from production admin keys + +--- + +## For Admins + +These practices apply to administrators responsible for issuing, reviewing, rotating, and revoking SSH access across a +team. + +### Program Checklist + +- [ ] Maintain an inventory for each SSH credential: + owner, device, purpose, target systems, creation date, and revoke trigger +- [ ] Require one key per person, device, and purpose instead of shared identities +- [ ] Prefer hardware-backed SSH credentials for privileged production access where practical +- [ ] Review account SSH keys, deploy keys, and automation keys on a regular cadence +- [ ] Remove unknown, stale, or unapproved keys during access reviews +- [ ] Revoke keys immediately after offboarding, device loss, or suspected compromise +- [ ] Keep human access and automation access logically separate +- [ ] Document a simple recovery and reissue process for lost devices and security keys + +### Git Hosting, CI/CD, and Automation + +Git hosting access should not be treated the same way as production administration. + +- Human users should have account-level SSH keys with clear labels +- CI/CD and deployment systems should use dedicated automation credentials, not a developer's personal laptop key +- Review deploy keys carefully because they are often long-lived and narrowly scoped but easy to forget +- Where the platform supports it, evaluate stronger centralized patterns such as GitHub Apps instead of relying on + long-lived deploy keys for Git-only automation + +For Web3 teams, this matters because SSH credentials often become a control point into deployment pipelines, validator +operations, RPC infrastructure, or incident-response systems. + +### Team Lifecycle and Revocation + +Make revocation and reissue routine, not just theoretical. + +When a device is lost, stolen, or potentially compromised: + +1. Revoke the affected Git hosting SSH keys. +2. Remove or disable server-side access for the affected key. +3. Replace any deploy or automation key that may have been exposed. +4. Reissue fresh credentials from a clean device. +5. Review bastion, repository, and infrastructure access logs for suspicious use. + +### Optional Advanced Model: SSH Certificates + +Larger teams may want a more centralized lifecycle than manually distributing raw public keys to each host. + +OpenSSH user certificates can improve issuance and revocation by letting systems trust a central SSH certificate +authority instead of many individual static keys. This is most useful for larger fleets or short-lived privileged +access, but it adds operational overhead and should only be adopted if the team is prepared to run the lifecycle well. + +--- + +## Web3-Specific Operational Rules + +Use these rules consistently: + +1. Do not use the same SSH key for Git hosting, deploy systems, and production administration. +2. Treat bastion, production, and incident-response SSH access as privileged and higher assurance. +3. Keep agent forwarding off unless there is a reviewed exception. +4. Investigate host key changes before reconnecting to important systems. +5. Revoke and replace SSH keys immediately after device loss or admin-role changes. +6. Keep automation credentials separate from human workstation credentials. + +--- + +## Related Guides + +- [GitHub Security](/guides/account-management/github) +- [Lessons Learned](/incident-management/lessons-learned) +- [Understanding Threat Vectors](/awareness/understanding-threat-vectors) + +## Further Reading + +- [NIST IR 7966: Security of Interactive and Automated Access Management Using Secure Shell (SSH)](https://csrc.nist.gov/pubs/ir/7966/final) +- [OpenBSD `ssh_config(5)`](https://man.openbsd.org/ssh_config) +- [OpenBSD `ssh-keygen(1)`](https://man.openbsd.org/ssh-keygen.1) +- [OpenBSD `ssh-add(1)`](https://man.openbsd.org/ssh-add.1) +- [GitHub: Generating a New SSH Key and Adding It to the SSH Agent](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent) +- [GitHub: Reviewing Your SSH Keys](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/reviewing-your-ssh-keys) +- [GitHub: GitHub's SSH Key Fingerprints](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/githubs-ssh-key-fingerprints) +- [GitLab: SSH Keys](https://docs.gitlab.com/user/ssh/) +- [GitLab: Using SSH Keys with GitLab CI/CD](https://docs.gitlab.com/ci/jobs/ssh_keys/) +- [Microsoft Learn: OpenSSH Key Management on Windows](https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_keymanagement) + +--- + + + diff --git a/vocs.config.tsx b/vocs.config.tsx index 8f50b117..b36d0b03 100644 --- a/vocs.config.tsx +++ b/vocs.config.tsx @@ -551,6 +551,7 @@ const config = { text: 'Endpoint Security', collapsed: true, items: [ + { text: 'SSH Client and Key Management Hardening', link: '/guides/endpoint-security/ssh-client-and-key-management-hardening' }, { text: 'Zoom Hardening', link: '/guides/endpoint-security/zoom-hardening' }, ] }, From 4423e89db1ece1e1ef47857c85f10af6add1e342 Mon Sep 17 00:00:00 2001 From: Dickson Date: Fri, 20 Mar 2026 23:10:45 -0400 Subject: [PATCH 12/20] Remove decorative separators from SSH hardening guide --- .../ssh-client-and-key-management-hardening.mdx | 15 --------------- 1 file changed, 15 deletions(-) diff --git a/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx b/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx index 9b6305b2..e9cbe316 100644 --- a/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx +++ b/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx @@ -33,9 +33,6 @@ as a privileged access control rather than a convenience feature. This page focuses on **client-side SSH hardening** for local human use first, with a short section on automation and team operations. It does not attempt to cover full `sshd` server hardening. - ---- - ## For Individuals These steps apply to developers, operators, admins, and contributors who use SSH from a local workstation. @@ -187,9 +184,6 @@ Team members should: - Report unexpected host key changes, access prompts, or pressure to enable agent forwarding - Reissue keys promptly after laptop replacement, loss, compromise, or major role change - Keep Git hosting keys separate from production admin keys - ---- - ## For Admins These practices apply to administrators responsible for issuing, reviewing, rotating, and revoking SSH access across a @@ -239,9 +233,6 @@ Larger teams may want a more centralized lifecycle than manually distributing ra OpenSSH user certificates can improve issuance and revocation by letting systems trust a central SSH certificate authority instead of many individual static keys. This is most useful for larger fleets or short-lived privileged access, but it adds operational overhead and should only be adopted if the team is prepared to run the lifecycle well. - ---- - ## Web3-Specific Operational Rules Use these rules consistently: @@ -252,9 +243,6 @@ Use these rules consistently: 4. Investigate host key changes before reconnecting to important systems. 5. Revoke and replace SSH keys immediately after device loss or admin-role changes. 6. Keep automation credentials separate from human workstation credentials. - ---- - ## Related Guides - [GitHub Security](/guides/account-management/github) @@ -273,8 +261,5 @@ Use these rules consistently: - [GitLab: SSH Keys](https://docs.gitlab.com/user/ssh/) - [GitLab: Using SSH Keys with GitLab CI/CD](https://docs.gitlab.com/ci/jobs/ssh_keys/) - [Microsoft Learn: OpenSSH Key Management on Windows](https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_keymanagement) - ---- - From 211d4c0b3373d37b243ad4a39788b79a1c0f4b48 Mon Sep 17 00:00:00 2001 From: Dickson Date: Fri, 20 Mar 2026 23:25:50 -0400 Subject: [PATCH 13/20] Fix markdownlint spacing in SSH hardening guide --- .../ssh-client-and-key-management-hardening.mdx | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx b/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx index e9cbe316..d7ff8737 100644 --- a/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx +++ b/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx @@ -33,6 +33,7 @@ as a privileged access control rather than a convenience feature. This page focuses on **client-side SSH hardening** for local human use first, with a short section on automation and team operations. It does not attempt to cover full `sshd` server hardening. + ## For Individuals These steps apply to developers, operators, admins, and contributors who use SSH from a local workstation. @@ -184,6 +185,7 @@ Team members should: - Report unexpected host key changes, access prompts, or pressure to enable agent forwarding - Reissue keys promptly after laptop replacement, loss, compromise, or major role change - Keep Git hosting keys separate from production admin keys + ## For Admins These practices apply to administrators responsible for issuing, reviewing, rotating, and revoking SSH access across a @@ -233,6 +235,7 @@ Larger teams may want a more centralized lifecycle than manually distributing ra OpenSSH user certificates can improve issuance and revocation by letting systems trust a central SSH certificate authority instead of many individual static keys. This is most useful for larger fleets or short-lived privileged access, but it adds operational overhead and should only be adopted if the team is prepared to run the lifecycle well. + ## Web3-Specific Operational Rules Use these rules consistently: @@ -243,6 +246,7 @@ Use these rules consistently: 4. Investigate host key changes before reconnecting to important systems. 5. Revoke and replace SSH keys immediately after device loss or admin-role changes. 6. Keep automation credentials separate from human workstation credentials. + ## Related Guides - [GitHub Security](/guides/account-management/github) @@ -261,5 +265,6 @@ Use these rules consistently: - [GitLab: SSH Keys](https://docs.gitlab.com/user/ssh/) - [GitLab: Using SSH Keys with GitLab CI/CD](https://docs.gitlab.com/ci/jobs/ssh_keys/) - [Microsoft Learn: OpenSSH Key Management on Windows](https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_keymanagement) + From 727d78fc5a3b1035d0573a48af8e38a33e04ae07 Mon Sep 17 00:00:00 2001 From: Dickson Date: Fri, 20 Mar 2026 23:56:30 -0400 Subject: [PATCH 14/20] Tighten SSH hardening guide --- ...sh-client-and-key-management-hardening.mdx | 24 ------------------- 1 file changed, 24 deletions(-) diff --git a/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx b/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx index d7ff8737..73bf9e24 100644 --- a/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx +++ b/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx @@ -31,9 +31,6 @@ infrastructure. In Web3 teams, the same workstation may be used to reach code ho systems, incident-response paths, validators, or other sensitive environments, so SSH key handling should be treated as a privileged access control rather than a convenience feature. -This page focuses on **client-side SSH hardening** for local human use first, with a short section on automation and -team operations. It does not attempt to cover full `sshd` server hardening. - ## For Individuals These steps apply to developers, operators, admins, and contributors who use SSH from a local workstation. @@ -171,21 +168,6 @@ accessible. If a laptop is lost, stolen, or suspected compromised, assume the SSH material on it may also need to be revoked and reissued. ---- - -## For Team Members - -These guidelines apply to people using SSH for work-owned repositories, infrastructure, and production systems. - -Team members should: - -- Use separate keys for code hosting and infrastructure access instead of reusing one key everywhere -- Label keys clearly so review and revocation are straightforward -- Avoid using personal unmanaged devices for privileged SSH access unless there is explicit approval -- Report unexpected host key changes, access prompts, or pressure to enable agent forwarding -- Reissue keys promptly after laptop replacement, loss, compromise, or major role change -- Keep Git hosting keys separate from production admin keys - ## For Admins These practices apply to administrators responsible for issuing, reviewing, rotating, and revoking SSH access across a @@ -247,12 +229,6 @@ Use these rules consistently: 5. Revoke and replace SSH keys immediately after device loss or admin-role changes. 6. Keep automation credentials separate from human workstation credentials. -## Related Guides - -- [GitHub Security](/guides/account-management/github) -- [Lessons Learned](/incident-management/lessons-learned) -- [Understanding Threat Vectors](/awareness/understanding-threat-vectors) - ## Further Reading - [NIST IR 7966: Security of Interactive and Automated Access Management Using Secure Shell (SSH)](https://csrc.nist.gov/pubs/ir/7966/final) From d21bf24804a8bff27809f4db048559a492f63b42 Mon Sep 17 00:00:00 2001 From: Dickson Date: Sat, 21 Mar 2026 00:28:24 -0400 Subject: [PATCH 15/20] Shorten SSH hardening guide --- ...sh-client-and-key-management-hardening.mdx | 121 ++---------------- 1 file changed, 14 insertions(+), 107 deletions(-) diff --git a/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx b/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx index 73bf9e24..674d2fdf 100644 --- a/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx +++ b/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx @@ -1,6 +1,6 @@ --- title: "SSH Client and Key Management Hardening | Security Alliance" -description: "Harden SSH usage with modern key choices, passphrases, careful agent use, strict host verification, and clear revocation and rotation practices for Web3 teams." +description: "Harden SSH client usage with better key handling, agent discipline, host verification, and rotation." tags: - Engineer/Developer - Security Specialist @@ -26,10 +26,8 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr > protect keys with passphrases, keep agent forwarding off by default, and maintain a simple revoke-and-reissue plan > for lost devices or role changes. -SSH is often the path from a developer laptop into source control, CI/CD, bastions, deploy hosts, and production -infrastructure. In Web3 teams, the same workstation may be used to reach code hosting, cloud infrastructure, deploy -systems, incident-response paths, validators, or other sensitive environments, so SSH key handling should be treated -as a privileged access control rather than a convenience feature. +SSH is often the path from a developer laptop into code hosting, CI/CD, bastions, and production infrastructure. Treat +SSH keys as privileged access, not just as a convenience feature. ## For Individuals @@ -53,71 +51,25 @@ These steps apply to developers, operators, admins, and contributors who use SSH ### Key Choice and Generation -For new software keys, the practical default is **Ed25519**. It is the current modern baseline for general SSH use and -is widely supported by Git hosting providers and modern OpenSSH clients. - -If you need stronger protection for privileged access, use a hardware-backed security-key credential such as -`ed25519-sk` when your environment supports it. That keeps the private key material inside the authenticator and adds -user presence checks such as a touch. Treat this as a strong recommendation for production bastions, deploy access, -incident-response access, and other high-impact administrative paths. - -If a legacy service still requires RSA, use it only for compatibility and prefer modern SHA-2 signatures rather than -legacy RSA/SHA-1 behavior. - -Examples: - -```bash -# Default software key for normal human SSH use -ssh-keygen -t ed25519 -a 64 -C "name@org" - -# Hardware-backed key for higher-risk access when supported -ssh-keygen -t ed25519-sk -O verify-required -C "name@org prod" -``` +- Use **Ed25519** for new software keys by default +- Use hardware-backed credentials such as `ed25519-sk` for higher-risk access when your environment supports them +- If a legacy service still requires RSA, treat it as compatibility-only and prefer modern SHA-2 signatures ### Passphrases and Local Protection -A local private key should be treated as a password-equivalent credential. - - Use a passphrase on every human-held software key - Avoid leaving sensitive keys loaded into an agent indefinitely - Prefer confirmation or time-limited agent loading for sensitive keys - Do not store private keys in cloud notes, chat, or shared drives - Avoid copying the same private key between multiple laptops or admin workstations -If you use `ssh-agent`, tighter defaults are better than "load once and forget about it." Example: - -```bash -ssh-add -c -t 8h ~/.ssh/id_ed25519 -``` - -That pattern is safer than leaving a privileged key loaded without confirmation for an unlimited period. - ### `~/.ssh/config` Hygiene Keep `~/.ssh/config` explicit and purpose-specific so your SSH client offers only the intended key to each service. -```text -Host github.com - HostName github.com - User git - IdentityFile ~/.ssh/id_ed25519_github - IdentitiesOnly yes - ForwardAgent no - StrictHostKeyChecking accept-new - UpdateHostKeys yes - -Host bastion-prod - HostName bastion.prod.example.org - User alice - IdentityFile ~/.ssh/id_ed25519_prod - IdentitiesOnly yes - ForwardAgent no - StrictHostKeyChecking yes - UpdateHostKeys yes -``` - -This approach reduces key sprawl, avoids offering the wrong identity to the wrong host, and makes it easier to reason -about which key is used for which environment. +- Use per-host entries with `IdentityFile` and `IdentitiesOnly yes` +- Keep `ForwardAgent no` unless there is a reviewed exception +- Use stricter host verification for bastions and production hosts than for low-risk systems ### Agent Forwarding and Remote Risk @@ -127,8 +79,8 @@ Treat agent forwarding as an exception, not a default workflow. - Never use `Host *` with `ForwardAgent yes` - Prefer `ProxyJump`, a bastion pattern, or a purpose-specific key on the intermediary host instead -Agent forwarding can let a remote system use your loaded identities for as long as the session is live. That means it -is a poor default for attacker-controlled or weakly trusted systems. +Agent forwarding lets a remote system use your loaded identities for as long as the session is live, so it is a poor +default for weakly trusted systems. ### Host Verification and `known_hosts` @@ -136,35 +88,16 @@ Do not normalize `StrictHostKeyChecking no` or "just click through" behavior for - Verify important host fingerprints from official documentation when available - Use `accept-new` only where trust-on-first-use is acceptable for the environment -- Use `yes` for bastions, production systems, and other high-sensitivity hosts where key verification should be pinned +- Use `yes` for bastions, production systems, and other high-sensitivity hosts - Preseed `known_hosts` for CI and automation from a trusted source instead of discovering keys live in the job - Investigate unexpected host key changes instead of bypassing the warning -Useful commands: - -```bash -# Find an existing host entry -ssh-keygen -F github.com - -# Remove an outdated host key entry -ssh-keygen -R github.com - -# Hash known_hosts entries for some additional privacy -ssh-keygen -H -f ~/.ssh/known_hosts -``` - ### File Permissions and Device Hygiene -On Unix-like systems: - - Keep `~/.ssh` owner-only - Keep private keys readable only by the account owner - Keep `~/.ssh/config` not writable by other users -On Windows, the operating system enforces protection through the Windows security model and ACLs rather than Unix -`chmod` conventions, but the principle is the same: private keys are sensitive credentials and should not be broadly -accessible. - If a laptop is lost, stolen, or suspected compromised, assume the SSH material on it may also need to be revoked and reissued. @@ -187,36 +120,10 @@ team. ### Git Hosting, CI/CD, and Automation -Git hosting access should not be treated the same way as production administration. - - Human users should have account-level SSH keys with clear labels - CI/CD and deployment systems should use dedicated automation credentials, not a developer's personal laptop key -- Review deploy keys carefully because they are often long-lived and narrowly scoped but easy to forget -- Where the platform supports it, evaluate stronger centralized patterns such as GitHub Apps instead of relying on - long-lived deploy keys for Git-only automation - -For Web3 teams, this matters because SSH credentials often become a control point into deployment pipelines, validator -operations, RPC infrastructure, or incident-response systems. - -### Team Lifecycle and Revocation - -Make revocation and reissue routine, not just theoretical. - -When a device is lost, stolen, or potentially compromised: - -1. Revoke the affected Git hosting SSH keys. -2. Remove or disable server-side access for the affected key. -3. Replace any deploy or automation key that may have been exposed. -4. Reissue fresh credentials from a clean device. -5. Review bastion, repository, and infrastructure access logs for suspicious use. - -### Optional Advanced Model: SSH Certificates - -Larger teams may want a more centralized lifecycle than manually distributing raw public keys to each host. - -OpenSSH user certificates can improve issuance and revocation by letting systems trust a central SSH certificate -authority instead of many individual static keys. This is most useful for larger fleets or short-lived privileged -access, but it adds operational overhead and should only be adopted if the team is prepared to run the lifecycle well. +- Review deploy keys carefully because they are often long-lived and easy to forget +- Revoke and reissue keys promptly after device loss, offboarding, or suspected compromise ## Web3-Specific Operational Rules From fa8cac9162189d8ca54f95c29ec5c533ebd269b7 Mon Sep 17 00:00:00 2001 From: Dickson Date: Sat, 21 Mar 2026 17:25:24 -0400 Subject: [PATCH 16/20] Clarify SSH hardening guidance --- .../ssh-client-and-key-management-hardening.mdx | 14 ++++---------- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx b/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx index 674d2fdf..ec23b59d 100644 --- a/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx +++ b/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx @@ -27,7 +27,7 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr > for lost devices or role changes. SSH is often the path from a developer laptop into code hosting, CI/CD, bastions, and production infrastructure. Treat -SSH keys as privileged access, not just as a convenience feature. +SSH keys as privileged access. ## For Individuals @@ -49,12 +49,6 @@ These steps apply to developers, operators, admins, and contributors who use SSH - [ ] Keep `~/.ssh` and private key files accessible only to you - [ ] Review and remove stale keys after device loss, role changes, or offboarding -### Key Choice and Generation - -- Use **Ed25519** for new software keys by default -- Use hardware-backed credentials such as `ed25519-sk` for higher-risk access when your environment supports them -- If a legacy service still requires RSA, treat it as compatibility-only and prefer modern SHA-2 signatures - ### Passphrases and Local Protection - Use a passphrase on every human-held software key @@ -94,9 +88,9 @@ Do not normalize `StrictHostKeyChecking no` or "just click through" behavior for ### File Permissions and Device Hygiene -- Keep `~/.ssh` owner-only -- Keep private keys readable only by the account owner -- Keep `~/.ssh/config` not writable by other users +- On Unix-like systems, use `chmod 700 ~/.ssh` +- Use `chmod 600` for private keys and for `~/.ssh/config` +- On Windows, keep private keys readable only by your user account and administrators If a laptop is lost, stolen, or suspected compromised, assume the SSH material on it may also need to be revoked and reissued. From 7ad4dc8a5a3730d2b37d56e462b64a08d534bb40 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mat=C3=ADas=20Aereal=20Ae=C3=B3n?= <388605+mattaereal@users.noreply.github.com> Date: Mon, 23 Mar 2026 17:52:41 -0300 Subject: [PATCH 17/20] Introduce SSH certificates for better key management Added a section on using SSH certificates for improved access management. --- .../ssh-client-and-key-management-hardening.mdx | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx b/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx index ec23b59d..c6bea544 100644 --- a/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx +++ b/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx @@ -119,6 +119,22 @@ team. - Review deploy keys carefully because they are often long-lived and easy to forget - Revoke and reissue keys promptly after device loss, offboarding, or suspected compromise +### Higher-Maturity Option: SSH Certificates + +For larger teams or higher-sensitivity environments, consider using SSH certificates instead of managing long-lived +authorized keys on each target system. + +With SSH certificates, a trusted internal certificate authority (CA) signs user or host keys for a limited period +of time. This can make access management easier by allowing teams to: + +- Issue short-lived SSH access without distributing permanent keys to every host +- Centralize approval, expiration, and revocation workflows +- Reduce the operational burden of updating `authorized_keys` across many systems +- Tie SSH access more closely to role, device, or incident-response requirements + +SSH certificates introduce their own operational complexity and should be implemented carefully, but they are worth +evaluating for organizations that need stronger central control over SSH access. + ## Web3-Specific Operational Rules Use these rules consistently: From 65a1ae23602c14eb30fb915c649f4b9e860aaeae Mon Sep 17 00:00:00 2001 From: Dickson Date: Mon, 23 Mar 2026 23:38:14 -0400 Subject: [PATCH 18/20] Clarify SSH host verification guidance --- .../ssh-client-and-key-management-hardening.mdx | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx b/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx index c6bea544..551bf90f 100644 --- a/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx +++ b/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx @@ -43,9 +43,10 @@ These steps apply to developers, operators, admins, and contributors who use SSH - [ ] Keep `ForwardAgent no` unless there is a specific and reviewed operational need - [ ] Use explicit per-host entries in `~/.ssh/config` with `IdentityFile` and `IdentitiesOnly yes` - [ ] Keep `StrictHostKeyChecking` enabled: - `accept-new` for normal low-risk hosts, `yes` for bastions and production systems where host verification - should be explicit -- [ ] Keep `UpdateHostKeys yes` enabled where you manage planned key rotation + use `accept-new` only for lower-risk hosts where trust-on-first-use is acceptable, and use `yes` for bastions + and production systems where host verification should be explicit +- [ ] Use `UpdateHostKeys yes` only for hosts you already trust and manage, especially where you expect planned key + rotation - [ ] Keep `~/.ssh` and private key files accessible only to you - [ ] Review and remove stale keys after device loss, role changes, or offboarding @@ -83,6 +84,7 @@ Do not normalize `StrictHostKeyChecking no` or "just click through" behavior for - Verify important host fingerprints from official documentation when available - Use `accept-new` only where trust-on-first-use is acceptable for the environment - Use `yes` for bastions, production systems, and other high-sensitivity hosts +- Do not rely on `accept-new` for first contact with high-sensitivity systems - Preseed `known_hosts` for CI and automation from a trusted source instead of discovering keys live in the job - Investigate unexpected host key changes instead of bypassing the warning From 570d500f7ffede11104dbccd7c85a6bf687e56c2 Mon Sep 17 00:00:00 2001 From: Dickson Date: Mon, 23 Mar 2026 23:44:24 -0400 Subject: [PATCH 19/20] Fix SSH guide markdown formatting --- .../ssh-client-and-key-management-hardening.mdx | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx b/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx index 551bf90f..2c6dd8b9 100644 --- a/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx +++ b/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx @@ -123,10 +123,10 @@ team. ### Higher-Maturity Option: SSH Certificates -For larger teams or higher-sensitivity environments, consider using SSH certificates instead of managing long-lived +For larger teams or higher-sensitivity environments, consider using SSH certificates instead of managing long-lived authorized keys on each target system. -With SSH certificates, a trusted internal certificate authority (CA) signs user or host keys for a limited period +With SSH certificates, a trusted internal certificate authority (CA) signs user or host keys for a limited period of time. This can make access management easier by allowing teams to: - Issue short-lived SSH access without distributing permanent keys to every host @@ -134,7 +134,7 @@ of time. This can make access management easier by allowing teams to: - Reduce the operational burden of updating `authorized_keys` across many systems - Tie SSH access more closely to role, device, or incident-response requirements -SSH certificates introduce their own operational complexity and should be implemented carefully, but they are worth +SSH certificates introduce their own operational complexity and should be implemented carefully, but they are worth evaluating for organizations that need stronger central control over SSH access. ## Web3-Specific Operational Rules From dc7ec9ca115cec2c9e8e342caa286514cb46e2aa Mon Sep 17 00:00:00 2001 From: Dickson Date: Mon, 23 Mar 2026 23:45:22 -0400 Subject: [PATCH 20/20] Finish SSH guide review fixes --- wordlist.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/wordlist.txt b/wordlist.txt index be285213..c9fd0766 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -337,3 +337,6 @@ rootfs GitHub GitLab GoDaddy +godaddy +NCSC +Opsek