You can securely access a local server's web GUI from a remote machine by configuring an SSH jump host (also known as a bastion host) on Ubuntu. This method tunnels your browser traffic through the jump server, bypassing firewall restrictions and exposing only the necessary SSH port to the public internet.
Understanding the Network Topology
In this scenario, you have three distinct machines involved in the connection chain. The first is your
Local Server, which hosts the web application or graphical interface you wish to view. This machine is typically behind a NAT or firewall and does not have a public IP address, making it unreachable directly from the outside world.
The second component is the
Jump Server. This is a cloud-based or publicly accessible Ubuntu machine with a static public IP address. Its sole purpose is to act as a bridge. It has inbound SSH access enabled but does not need to run the web service itself.
The third is your
Remote Client, which is your personal laptop or desktop computer located anywhere on the internet. Your goal is to open a browser on this client that displays content served by the Local Server, as if you were sitting in front of it.
This architecture is critical for security. By restricting direct access to the Local Server, you reduce the attack surface significantly. You only need to secure the Jump Server against unauthorized SSH access, while the actual data payload travels through an encrypted tunnel between the Jump Server and the Local Server.
Configuring SSH on the Jump Server
Before establishing the tunnel, ensure your Jump Server is properly configured to accept connections. Since this server will be exposed to the internet, hardening its SSH configuration is essential.
First, verify that the OpenSSH server is installed and running:
sudo systemctl status ssh
If it is not active, start it with:
sudo systemctl enable --now ssh
Next, edit the SSH daemon configuration file to enforce key-based authentication and disable password logins. This prevents brute-force attacks using common passwords.
sudo nano /etc/ssh/sshd_config
Locate the following directives and modify them:
PubkeyAuthentication yes: Ensures only users with valid keys can connect.PasswordAuthentication no: Disables password entry entirely.PermitRootLogin prohibit-password: Allows root login only via keys, or set to no for stricter security.
After saving these changes, restart the SSH service to apply the new settings:
sudo systemctl restart ssh
It is also advisable to configure a firewall, such as UFW, to allow only SSH traffic (port 22) from specific trusted IPs if possible, though standard practice often allows SSH from any IP while relying on strong keys. For more details on general remote connectivity issues, see our guide on
Troubleshooting: Can't Connect to VM Remotely.
Establishing the SSH Tunnel
The core mechanism for accessing the web GUI is an SSH dynamic port forwarding tunnel. This creates a SOCKS proxy on your local machine that routes traffic through the Jump Server to the Local Server.
On your Remote Client machine, open a terminal and execute the following command. Replace the placeholders with your actual credentials and IP addresses.
ssh -D 1080 -C -N -l username jump-server-ip
Let us break down the flags used here:
-D 1080: Specifies a dynamic port on your local machine (localhost:1080) that acts as a SOCKS5 proxy.-C: Enables compression, which can improve performance over slower connections.-N: Tells SSH not to execute a remote command. This keeps the connection open solely for forwarding ports.-l username: Specifies the user account on the Jump Server.jump-server-ip: The public IP address of your Ubuntu jump server.
When prompted, enter your SSH key passphrase or authenticate via your key agent. Once connected, the terminal will appear to hang; this is normal behavior indicating the tunnel is active. Do not close this window, as closing it will terminate the tunnel.
To make the connection more robust, especially if you are connecting to the Local Server through the Jump Server, you might use the
-J flag (ProxyJump) if your client supports newer SSH versions. However, the dynamic forward method described above is universally compatible.
Configuring Your Browser
With the SSH tunnel active, you must configure your web browser to send traffic through the SOCKS proxy you just created. The steps vary slightly depending on the browser, but the logic remains the same.
For Firefox:
- Navigate to
Settings > Network Settings.
- Select
Manual proxy configuration.
- Set the
Socks Host to localhost and the Port to 1080.
- Check the box for
Proxy DNS when using SOCKS v5. This ensures that domain resolution happens remotely, preventing leaks.
For Chrome or Edge:
These browsers do not easily support system-wide SOCKS proxies via their UI without extensions. You may need to install a browser extension like "SwitchyOmega" or launch the browser with command-line arguments specifying the proxy:
google-chrome --proxy-server="socks5://localhost:1080"
Once configured, navigate to the internal IP address of your Local Server's web GUI (e.g.,
http://192.168.1.50:8080). The request will travel from your browser to localhost:1080, then through the SSH tunnel to the Jump Server, and finally to the Local Server. The response returns along the same encrypted path.
If you encounter connectivity issues, check if the Local Server is actually listening on the expected port. You can test this by SSHing into the Jump Server and trying to curl the Local Server's IP from within the Jump Server's network context. If the tunnel works but the page doesn't load, the issue is likely at the application layer on the Local Server rather than the SSH configuration.
Maintaining and Securing the Connection
Keeping an SSH session open indefinitely can be problematic if your internet connection drops. To manage this, consider using
autossh, a tool that monitors the SSH tunnel and restarts it automatically if the connection fails.
Install autossh on your client:
sudo apt install autossh
Then replace the manual ssh command with:
autossh -M 0 -D 1080 -C -N -l username jump-server-ip
The
-M 0 flag disables the monitoring port because we are using the same channel for data and monitoring, which simplifies setup.
Security best practices dictate that you should never expose the Local Server's web GUI to the public internet. Always rely on this tunneling method. Additionally, regularly update both the Jump Server and the Local Server to patch any vulnerabilities in the SSH daemon or the web application itself.
Frequently Asked Questions
Can I use this method to access other services besides web GUIs?
Yes, this technique works for any TCP-based service, including databases, FTP servers, or VNC desktop environments. As long as the service listens on a specific port, you can forward it through the SSH tunnel using the same dynamic SOCKS proxy or specific port forwarding flags.
What happens if my internet connection drops during the session?
If you are using a manual SSH command, the tunnel will break, and your browser will lose connection until you reconnect. Using
autossh helps mitigate this by automatically restarting the tunnel once the network stabilizes, ensuring minimal downtime for your remote access.
Is it safe to leave the SSH tunnel open for days?
While technically feasible, leaving tunnels open for extended periods increases the risk of disconnection due to network timeouts or router resets. It is safer to use a tool like
tmux or
screen on the server side, or
autossh on the client side, to handle reconnections gracefully without manual intervention.
How do I troubleshoot if the browser shows a "Connection Refused" error?
First, verify that the Local Server is running and listening on the correct port. Second, ensure that the Jump Server can reach the Local Server internally. Finally, check that your browser is correctly configured to use the SOCKS proxy on localhost port 1080 and that no other firewall rules are blocking the loopback interface.
Do I need to open any additional ports on the Jump Server?
No, you only need port 22 (SSH) open on the Jump Server. The dynamic port forwarding uses the existing SSH connection to carry all subsequent traffic. Opening additional ports would defeat the purpose of hiding the Local Server behind the jump host.