PHP项目GitLab自动化部署：SSH私钥安全及CI/CD配置咨询

Hey Bob, let's walk through the critical SSH key security considerations and best configuration practices for your GitLab CI/CD PHP deployment workflow—this is essential to lock down your production server and avoid unauthorized access.

SSH Private Key Security Fundamentals #

First, let's make sure the private key itself is as secure as possible:

• Always use a strong passphrase for your private key: If you generated the key without one, stop and re-generate it immediately with ssh-keygen -t ed25519 -C "deployer@your-production-server". Ed25519 is more secure and efficient than the older RSA format, and the passphrase adds an extra layer—even if the key leaks, attackers can't use it without the passphrase.
• Lock down file permissions on the production server: For the deployer user, ensure:
  • .ssh directory has permissions 700 (chmod 700 /home/deployer/.ssh)
  • id_rsa private key has permissions 600 (chmod 600 /home/deployer/.ssh/id_rsa)
  • authorized_keys has permissions 600 (chmod 600 /home/deployer/.ssh/authorized_keys)
    These strict permissions prevent other users on the server from reading or modifying the key files.

GitLab Secret Variable Best Practices #

When storing the private key in GitLab's secret variables, follow these rules:

• Enable both "Protect variable" and "Mask variable":
  • Protect variable: Restricts the variable to only run on protected branches (like main or master), so it can't be accessed by untrusted feature branches.
  • Mask variable: Ensures the key's content is automatically hidden in CI/CD logs, even if your script accidentally outputs it.
• Limit access to the variable: In GitLab, only grant "Maintainer" or "Owner" roles to team members who need to manage deployment variables—don't let everyone in the team view or edit sensitive secrets.
• Never hardcode the key in .gitlab-ci.yml: Even in comments, this is a huge risk. Always reference the variable (e.g., $DEPLOY_SSH_KEY) instead.

Production Server SSH Hardening #

Lock down the SSH service on your production server to minimize attack surface:

• Restrict the deployer user's capabilities: Edit /etc/ssh/sshd_config and add this block:

  Match User deployer
      AllowTcpForwarding no
      X11Forwarding no
      PermitTunnel no
      ForceCommand /usr/local/bin/deploy-only-script.sh
  

  The ForceCommand option limits the user to running only a pre-defined deployment script (you'll need to create this script to handle tasks like git pull or file syncing), so even if the key is compromised, attackers can't get a full shell or run arbitrary commands.
• Disable password authentication: Set PasswordAuthentication no in sshd_config to force all SSH logins to use keys—this eliminates brute-force password attacks.
• Restrict SSH access to GitLab's IP: If your GitLab server has a static IP, use ufw (Ubuntu/Debian) or firewalld (CentOS/RHEL) to only allow incoming SSH connections from that IP. For example:

  ufw allow from <gitlab-server-ip> to any port 22
  ufw enable
  

  Alternatively, add AllowUsers deployer@<gitlab-server-ip> to sshd_config to limit which IPs can log in as deployer.

Secure CI/CD Script Configuration #

When using the key in your .gitlab-ci.yml, handle it safely:

• Write the key to a temporary file with strict permissions: Never pass the key directly via command line. Instead:

  deploy:
    stage: deploy
    script:
      # Write the secret key to a temp file
      - echo "$DEPLOY_SSH_KEY" > /tmp/deploy_key
      - chmod 600 /tmp/deploy_key
      # Add production server to known_hosts to avoid MITM risks
      - ssh-keyscan <production-server-ip> >> ~/.ssh/known_hosts
      # Run deployment command
      - ssh -i /tmp/deploy_key deployer@<production-server-ip> 'cd /var/www/your-project && git pull && sudo systemctl reload apache2'
      # Clean up the temp key immediately
      - rm /tmp/deploy_key
  

• Avoid StrictHostKeyChecking=no: While it's tempting to skip host key verification, it opens you up to man-in-the-middle attacks. Using ssh-keyscan to pre-populate known_hosts is the safer alternative.

Extra Security Checks #

• Rotate SSH keys regularly: Every 3-6 months, generate a new key pair, update the GitLab secret variable, and replace the old public key in deployer's authorized_keys on the production server. This limits the window of risk if a key is ever compromised.
• Monitor SSH logs: Check /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (CentOS/RHEL) regularly for unusual login attempts. You can set up alerts for failed SSH attempts to catch potential attacks early.
• Consider using Deploy Tokens instead: If your deployment only needs to pull code from GitLab, you can use a GitLab Deploy Token (with read-only permissions) over HTTPS instead of SSH. This avoids managing SSH keys entirely and limits access to just repository pulls.

内容的提问来源于stack exchange，提问作者Bob5421