SSH Access Proxy VPC Private Subnet Proxy Deployment

Managing secure access to resources in private VPC subnets often presents a challenge. Direct SSH access is risky, and exposing resources publicly is not an option for most organizations. A better, more secure alternative is using an SSH access proxy to bridge the gap. This blog will guide you through deploying an SSH access proxy for VPC private subnets, ensuring a streamlined and secure connection to your resources.

What is an SSH Access Proxy for Private Subnets?

An SSH access proxy allows teams to connect securely to servers within private VPC subnets without opening unnecessary ports or exposing instances to the public internet. Instead of directly allowing inbound SSH traffic, a proxy can act as an intermediary, tightly controlling access while maintaining robust security policies.

By leveraging an SSH proxy solution, you achieve:

• Secure access to private network resources.
• Fine-grained access control for team members.
• Reduced attack surface by eliminating public endpoint exposure.

Let's break down the steps to set this up effectively.

Step-by-Step Guide to Deploying an SSH Access Proxy in a VPC Private Subnet

1. Create a Bastion Host

A bastion host serves as the entry point for the SSH proxy. It resides in a public subnet and is configured to forward traffic to private subnets.

Steps:

1. Allocate a small EC2 instance in your public-facing subnet. Use a hardened AMI (such as an Ubuntu LTS image with security patches applied).
2. Assign an Elastic IP to the instance for consistent public access.
3. Limit access through your security group to administrators and DevOps users who require SSH access.

Why? The public subnet bastion host is a secure bridge to private resources without exposing them to the open internet.

2. Configure ProxyJump for SSH

To forward SSH connections through the bastion, configure ProxyJump (specific to OpenSSH). This eliminates the need for users to manually SSH into the bastion host before accessing private resources.

Steps:

1. Modify the SSH client configuration file (~/.ssh/config) for all users requiring access:

Host private-server
 HostName <Private Instance IP>
 ProxyJump bastion
 User <private-server-username>
Host bastion
 HostName <Public Bastion IP>
 User <bastion-username>

1. Test the connection by running:

ssh private-server

Why? ProxyJump simplifies secure access workflows while enforcing use of the bastion host.

3. Harden the Bastion Host

Security should be your primary focus for the bastion host, as it is the gateway to your private resources.

Steps:

• Disable password authentication; only use SSH keys.
• Ensure that only the required IPs and CIDR ranges have SSH access via the security group.
• Enable logging by configuring auditd or CloudWatch logging for all SSH login attempts.
• Regularly rotate bastion host keys to minimize risk from compromised key material.

Why? A hardened bastion minimizes the risk of unauthorized access to your network.

4. Configuring Network Access Control

Instance-level access is further secured by configuring proper network rules. Ensure that private instances only permit SSH traffic from the bastion host, not external IPs.

Steps:

1. Update the private subnet instance's security group. Add a rule that:

• Allows inbound SSH (port 22).
• Restricts the source to the bastion host’s private IP range.

1. Ensure no other inbound rules expose sensitive ports.

Why? This ensures that any SSH traffic is funneled exclusively through the bastion host.

5. Automate Deployment with IAC

Manually configuring your SSH proxy deployment is error-prone and cumbersome. Using Infrastructure-as-Code (IAC) tools like Terraform or AWS CloudFormation can help with consistency and scalability.

Terraform Example:
A simple module, automating the bastion host and proxy access, looks like:

resource "aws_instance""bastion"{
 ami = "ami-xxxxxxxx"
 instance_type = "t2.micro"
 key_name = var.ssh_key_name

 network_interface {
 subnet_id = var.public_subnet_id
 security_groups = [aws_security_group.bastion.id]
 }
}

Why? Automation ensures configuration consistency and makes it easy to replicate across environments.

Why an SSH Access Proxy is Better for Security

By adopting an SSH proxy solution, you eliminate gaps in security while improving the overall developer experience:

1. Minimized Attack Surface: The bastion consolidates access points.
2. Centralized Access Control: Proxy access ensures all connections are routed through a secure intermediary.
3. Auditing and Monitoring: Enable logging to monitor all access activity.
4. Scalability: Proxies can dynamically fit multi-region or large-scale deployments.

Test it Live with hoop.dev

Deploying and maintaining an SSH access proxy for private subnets can feel overwhelming, even with guides and automation. With hoop.dev, you can set up secure SSH proxy access to your private VPC resources in minutes. No custom scripts or manual configurations — just seamless access control with built-in logging and security best practices. Try it today and simplify your deployment workflows.