How GCP Browser Based SSH Works
If you are using GCP platform and lazy to setup VPN or bastion host, then you may familiar with using SSH connection via a browser. Yeah, its just one click to login to the Linux VM. Here are some questions for you.
- How many of you think how this actually works in the backend?
- Can we access the VM (via browser SSH) without whitelist our Public IP address in the firewall rule?
- Why the VM is not accessible via Browser SSH even though we whitelisted our Public IP?
I had a situation to dig deeper into understanding this concept.
My Problematic situation:
I was launching a new VM in GCP and tagged with
allow-office-ssh. Then created a Firewall rule which allows
Port 22 from the IP address
X.X.X.X(my office IP address) to the target tag
allow-office-ssh. Once the VM came to an active state, I tried to telnet on port 22. It was working fine.
But I don’t any username and password to login, So I thought to access the VM via browser then create the user. But unfortunately Im not able to access the VM via Browser. This made me go deep into this functionality.
How Browser SSH Works:
Here is an illustration that I have in my mind how this actually works.
- There is no need to allow your IP Address in the firewall rule.
- The communication is happening between the VM and Google’s SSH Proxy(i don’t know the right term, so Im using the term proxy).
- Your browser is just talking to the Proxy layer.
- The Proxy layer is actually talking to the VM.
- Its more or less a port forwarding or SSH tunneling.
How GCP’s proxy can access the VM?
As per GCP’s security policy, no one can access the VM without allowing their IP address. Then how this proxy is accessing it?
There is no way to proxy to access the VM. But Google has some static IP ranges which are assigned to its proxy layer. By whitelisting that IP range, they can talk to your VM.
From the GCP doc:
Source IP addresses for browser-based SSH sessions are dynamically allocated by GCP Console and can vary from session to session. For the feature to work, you must allow connections either from any IP address or from Google’s IP address range which you can retrieve using public SPF records.
If you run the below commands, you can get the IP address range for proxy layer.
nslookup -q=TXT _netblocks.google.com 18.104.22.168 nslookup -q=TXT _netblocks2.google.com 22.214.171.124 nslookup -q=TXT _netblocks3.google.com 126.96.36.199
nslookup -q=TXT _netblocks.google.com 188.8.131.52 Server: 184.108.40.206 Address: 220.127.116.11#53 Non-authoritative answer: _netblocks.google.com text = "v=spf1 ip4:18.104.22.168/24 ip4:22.214.171.124/19 ip4:126.96.36.199/20 ip4:188.8.131.52/20 ip4:184.108.40.206/18 ip4:220.127.116.11/16 ip4:18.104.22.168/21 ip4:22.214.171.124/16 ip4:126.96.36.199/17 ip4:188.8.131.52/19 ip4:184.108.40.206/19 ~all" Authoritative answers can be found from:
You can see a bunch of Public IP address. Right now we have the following IP ranges for accessing the VM via the browser.
220.127.116.11/24 18.104.22.168/19 22.214.171.124/20 126.96.36.199/20 188.8.131.52/18 184.108.40.206/16 220.127.116.11/21 18.104.22.168/16 22.214.171.124/17 126.96.36.199/19 188.8.131.52/19 184.108.40.206/19 220.127.116.11/20 18.104.22.168/19 22.214.171.124/20 126.96.36.199/19 188.8.131.52/19 184.108.40.206/16 220.127.116.11/22
Once you create a firewall rule which allows Port 22 from the above IP addresses, then we can access the VM via browser. Hope you learned something new today.
My Personal Suggestion:
But I always recommend that do not use this for production. Because I had some nightmares because of this. The VM goes offline due to the
live host migration. After that, the services are not started. I tried to access it via browser. Unfortunately, that time GCP’s some services also down which establish the connection between the browser and the VM. So use VPN or bastion host for this.
Happy SSH !!!