When to Use SSH Tunnel Proxy
Perfect for these scenarios:- Private/Internal Applications: Test staging environments or internal tools not exposed to the internet
- Firewall-Protected Apps: Access applications behind corporate firewalls or VPNs
- Security Compliance: Maintain secure connections when testing sensitive applications
- Development Environments: Access local development servers or containerized applications
How It Works
- SSH Connection: QA.tech establishes a secure SSH connection to your designated server
- SOCKS5 Proxy: Creates a local proxy that forwards all traffic through the SSH tunnel
- Browser Configuration: Automatically configures the test browser to route traffic through the tunnel
- Automatic Cleanup: Cleanly closes the tunnel when your test session ends
Setup Instructions
1
Enable SSH Tunnel Proxy
Navigate to Settings → Network and find the SSH Tunnel Proxy section. Toggle the switch to Enable.
2
Configure Connection Details
Enter your SSH server details:
- SSH Host: The hostname or IP address of your SSH server (e.g.,
jump-server.company.com
) - SSH User: The username for SSH authentication (e.g.,
ubuntu
,deploy
) - SSH Port: Custom SSH port (optional, default: 22)
3
Generate SSH Keys
Click Generate SSH Key to create a secure key pair. Copy the generated public key and add it to your server’s
~/.ssh/authorized_keys
file:The
restrict,port-forwarding,command="/bin/false"
prefix is highly recommended for security. This prevents QA.tech from getting shell access to your server while still allowing the necessary port forwarding for testing.4
Test and Save
Click Test Connection to verify everything is working, then Save Configuration to store your settings securely.
Server Requirements
Your SSH server needs to support:- SSH Protocol 2 (standard on modern systems)
- Public key authentication
- Dynamic port forwarding (SOCKS proxy support)
Recommended Architecture
SSH Jump Server Setup
Best Practice Architecture:- SSH Jump Server: Deploy a dedicated server with a public IP outside your private network
- IP Whitelist: Configure firewall rules to only allow SSH connections from QA.tech IPs
- Internal Access: Allow the jump server to access only the specific web applications needed for testing
- Network Segmentation: Keep your applications in a private network, accessible only via the jump server
- ✅ Minimal Attack Surface: Only SSH port exposed to internet
- ✅ Controlled Access: Jump server only accesses specific applications
- ✅ Audit Trail: All connections flow through a single, monitored entry point
Architecture Diagram
Key Architecture Points:- Isolated Workers: Each browser session runs on a dedicated, isolated worker
- Per-Session Tunnels: Fresh SSH connection created for every test
- Customer Separation: Workers never handle multiple customers simultaneously
- Encrypted Transport: All traffic flows through encrypted SSH tunnels
- Parallel Testing: Up to 10+ concurrent browser workers can connect simultaneously
Whitelist QA.tech IPs for SSH access
Get the current QA.tech IP addresses from Settings → Network → IP
Whitelist
in your project dashboard.
Security Features
SSH Key Security
Recommended SSH Key Restrictions: When adding the QA.tech public key to your~/.ssh/authorized_keys
file, always include these security restrictions:
restrict
- Disables all forwarding and other features by defaultport-forwarding
- Explicitly allows only port forwarding (required for SOCKS proxy)command="/bin/false"
- Prevents shell access, immediately exits if someone tries to get a shell
Additional Security Layers
- Encrypted Key Storage: Private keys are encrypted and stored securely
- Isolated Workers: Each browser session runs on a dedicated worker
- Per-Session SSH Connections: A fresh SSH tunnel is created for each browser session
- No Cross-Customer Data: Worker isolation prevents any data leakage between customers
- Automatic Cleanup: SSH connections and workers are terminated after each test session
- Limited Scope: SSH keys only allow port forwarding, no shell or file access
Parallel Testing Configuration
If you plan to run multiple tests simultaneously, configure your SSH server to handle concurrent connections:Troubleshooting
Connection Failed
- Check SSH server is running:
sudo systemctl status sshd
- Verify firewall rules allow SSH connections
- Test manual connection:
ssh user@host
from your local machine
Authentication Failed
- Verify public key was added to
~/.ssh/authorized_keys
- Check file permissions:
chmod 600 ~/.ssh/authorized_keys
- Try regenerating keys in the QA.tech interface
Connection Timeout
- Ensure the SSH host is reachable from QA.tech servers
- Verify QA.tech IPs are whitelisted in your firewall
- Check if SSH daemon allows connections from external IPs
The “Test Connection” button currently does not use our whitelisted IPs, so
you may see timeout errors when testing if you have configured IP
whitelisting. This is a known bug - your actual tests will work correctly
using the whitelisted IPs.
Parallel Connection Issues
- Check your server’s SSH configuration for
MaxSessions
andMaxStartups
- Monitor server resources (CPU, memory, network) during parallel tests
- Start with fewer parallel connections and scale gradually
Technical Details
- Protocol: SSH-2 with SOCKS5 dynamic port forwarding
- Encryption: RSA 2048-bit or Ed25519 key pairs (automatically generated)
- Timeout: 30-second connection timeout for reliability
- Keep-Alive: Automatic connection maintenance during test sessions
The SSH Tunnel Proxy feature is currently in Beta. If you encounter any issues
or have feature requests, please contact our support team.