Moving WordPress Access from SSH to AWS Systems Manager

While running my personal WordPress blog, I reconsidered whether I needed to keep SSH open. I was the only operator, and the server was hosted on AWS EC2, so I removed port 22 from the security group and switched operational access to AWS Systems Manager Session Manager. This article documents the changes to IAM, security groups, file permissions, and operating procedures, rather than just a different connection command.

What the SSH setup required me to manage

  • The source IP ranges allowed to reach port 22
  • Storage and rotation of private key files
  • Security group changes when my local network changed
  • Cleanup of accounts and keys that had not been used for a long time

This does not mean SSH is inherently insecure. I already used the AWS control plane and IAM in this environment, and SSM access without a separate inbound port was a better fit for my operating model.

Setting up SSM access

  1. Create a dedicated IAM role and instance profile for EC2
  2. Attach AmazonSSMManagedInstanceCore as the only policy
  3. Check the SSM Agent on Amazon Linux 2023
  4. Confirm that the managed node is shown as Online
  5. Test an actual Session Manager connection
  6. Remove the SSH inbound rule from the security group as the final step
aws ssm start-session 
  --region ap-northeast-2 
  --target i-xxxxxxxxxxxxxxxxx

The command above is line-wrapped for readability. Run the command and both options on a single line in your shell.

Why the sequence matters

Removing the SSH rule before confirming SSM registration can leave you without a way to access the server. Confirm the role attachment, agent, network connectivity, and session startup before closing SSH access. After the switch, I also checked from another network that port 22 was blocked.

Updating operational procedures for SSM

I keep the WordPress core, themes, and plugins read-only for the web server process so that it cannot perform updates directly. When an update is needed, I connect through SSM and run a dedicated maintenance script. The script takes file and database snapshots before making changes, then checks the WordPress bootstrap and public URLs after the update.

Other server security changes

  • Remove the unused FTP server and plaintext FTP configuration
  • Disable Apache directory listings and CGI
  • Block PHP execution in the uploads directory
  • Apply Secure, HttpOnly, and SameSite attributes to PHP session cookies
  • Keep SELinux in Enforcing mode and enable only the necessary booleans
  • wp-config.php permissions restricted to root and the Apache group

Remaining operational work

Session Manager does not remove the need to manage IAM accounts and permissions. Limit who can start sessions, and record sessions in CloudWatch Logs or S3 when needed. For this blog, I left centralized session log storage as a separate task because of cost and the scope of a personal site.

Conclusion

The main benefit of switching to SSM was more than eliminating SSH keys: it brought server access under IAM and an AWS-managed channel while removing one inbound port. In an environment with clearly defined operators, such as a personal blog, updating the operating procedures at the same time can reduce both administrative effort and the attack surface.

Related articles

Leave a Comment

Your email address will not be published. Required fields are marked *