SSH Key Rotation and Security Configuration: Safeguarding Your Servers

In the process of frequently logging into remote servers every day, have you encountered dilemmas such as "key leakage" or "forgetting server addresses"? This article will guide you step-by-step in establishing a complete system for SSH key rotation and security configuration, making remote collaboration both secure and efficient.

Why Perform Key Rotation?

**Risk Scenarios**:

- Employees leave but their SSH keys are not disabled in time

- Laptops are stolen, and keys are not protected with encryption

- Keys are leaked through multiple channels (public GitHub repositories, IM tool transfers)

**Rotation Frequency Recommendation**: Rotate every 90 days; if team membership changes frequently, shorten the interval to 30 days.

Complete Operational Workflow

Step 1: Generate New Keys (Ed25519 Recommended)

# Generate Ed25519 key (more secure and smaller)
ssh-keygen -t ed25519 -C "your-email@example.com"

# Set a strong passphrase to protect the private key
# Recommendation: 12+ characters, including uppercase, lowercase, numbers, and symbols

**Key Point**: Ed25519 is more secure and offers better performance than RSA. Although the key length is only 256 bits, its security strength is equivalent to 3072-bit RSA.

Step 2: Deploy Public Key to Server

# Automatic deployment (recommended)
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server

# Manual method (backup)
cat ~/.ssh/id_ed25519.pub | ssh user@server "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Step 3: Configure .ssh/config File

# Add to ~/.ssh/config
Host production
    HostName 192.168.1.100
    User deploy
    IdentityFile ~/.ssh/id_ed25519_prod
    IdentityFile ~/.ssh/id_ed25519_personal

Host staging
    HostName 10.0.0.50
    User deploy
    IdentityFile ~/.ssh/id_ed25519_staging
    ForwardAgent yes  # Note: Recommended to disable in production environments

**Checklist**:

- [ ] Use independent key pairs for each server

- [ ] Disable ForwardAgent in production environments

- [ ] Set appropriate file permissions (600 for private keys, 644 for public keys)

When Should You Not Use This Method?

1. **Temporary Test Environments**: Use temporary keys; no persistent configuration is needed

2. **Public Services**: For platforms like GitHub or cloud provider consoles, use OAuth or cloud-specific keys instead of SSH

3. **No Server Access Permissions**: Use API keys or browser-based credentials instead

Rotation Checklist

Execute the following steps during each rotation:

| Step | Command |

|------|------|

| Generate new key | `ssh-keygen -t ed25519 -C "rotated-$(date +%Y%m%d)"` |

| Verify new key login | `ssh -i ~/.ssh/id_ed25519_new user@server "echo ok"` |

| Deploy new public key | `ssh-copy-id -i ~/.ssh/id_ed25519_new user@server` |

| Disable old key | Remove the old public key from `authorized_keys` |

| Update local config | Update `.ssh/config` to point to the new key |

| Log rotation details | Save the rotation date and server list |

Common Pitfalls

- **Forgetting to disable old keys**: After rotation, old keys can still be used to log in from old devices; they must be explicitly removed

- **Overly permissive key permissions**: Private key permissions must be set to 600, otherwise SSH will refuse to use them

- **Mixing RSA and Ed25519**: It is recommended to standardize the technology stack to avoid compatibility issues

- **Abuse of ForwardAgent**: Remote servers can use this to access other hosts; ensure it is disabled in production environments

---

**Summary**: Establish a closed-loop process of "Generate → Deploy → Verify → Rotate" to make SSH security not just a passive defense, but an active standard in daily operations.