VaultPress SSH Access to Site Behind AWS Load Balancer
Published: 2019-03-21 13:32:35

---
title: VaultPress SSH Access to Site Behind AWS Load Balancer
published: true
description: 
canonical_url: https://deeb.me/20190318/vaultpress-ssh-sftp-access-for-wordpress-site-behind-aws-load-balancer
---

I recently worked on migrating a large WordPress site from a dedicated server to AWS following the reference architecture as outlined in https://github.com/aws-samples/aws-refarch-wordpress

One of the upsides of this architecture is that the site is entirely behind the load balancer and the instances running the web server are never accessible from the internet (not even via ssh or http). So any updates to the site need to be deployed using Systems Manager. I will post about that later … However due to this restriction, VaultPress is only able to access the site (for backups) over https, which causes extra load on the web instances.

To fix that, we need to allow VaultPress SSH access directly to the web instances (at least to 1 of them). And the only way in via SSH is through a bastion instance.

On this bastion instance, I installed Nginx with the following configuration in /etc/nginx/nginx.conf

```
stream {
        server {
                listen 1234;
                proxy_pass 10.0.1.12:22;
        }
}
```

where `10.0.1.12` is the internal IP of one web instances behind the load balancer.

At this stage (after reloading Nginx), I added the `vaultpress` user to the web instances and set their SSH public key in the `.ssh/authorized_keys` for that user.

To test manually, I added my own public key and connected to: 

```
ssh -l vaultpress -p 1234 bastion.mydomain.com 
```

After that works, I tested from VaultPress dashboard. No surprises: testing the connection works (SSH/SFTP), all green! Great, both the SSH and the SFTP setups should work properly. 

<shrug>One issue I faced here was that after a few hours/the next day, VaultPress somehow forgot the setup and I had to re-add the connection information. Why? No idea! Just make sure to check on it the next day to make sure it's still there! </shrug>

Since the IPs may change in case there’s an auto scaling event, I added a cron job that runs every 5 minutes on the bastion and updates the nginx configuration to point to one of the web instances internal IPs. A simplistic version looks like this:

```
#!/bin/bash
IP="$(list-ips.sh | awk '{ print $1 }')"
sed -i -E "s/proxy_pass (.+):22/proxy_pass ${IP}:22/" /etc/nginx/nginx.conf
nginx -t && service nginx reload
```
 
You can also use CloudWatch Events to add a rule, that runs when AutoScaling happens. Pointing that to a Lambda function that calls Systems Manager to change the IP in Nginx. Here’s a reference for that https://docs.aws.amazon.com/autoscaling/ec2/userguide/cloud-watch-events.html#create-lambda-function

Oh, and don’t forget to lock down the bastion instance. In my case, I set the Security group in the EC2 console to allow only the following:

```
Type: Custom TCP Rule
Protocol: TCP
Port Range: 1234
Source: 192.0.64.0/18
Description: VaultPress SSH Access
```

Hope it helps!
If you have any thoughts on improving the setup, I'm open for discussions.