SSH from Browser not working

[vasanth107]

Hi All,

i have linux based virtual machine in my gcp-project and while i tried to take  ssh to vm from SSH from browser in console, i have received error message as identity aware proxy failed with code:1006  and while tried to connect fom IAP desktop i wasn't able to connect . 

To be noted , i have owner permission to the GCP project and i have also configured the required firewalls rules based on IAP.

As a initial troubleshooting step, i doubted connection from my local device trying to access SSH and i tied to launching  the windows virtual machine and from there i tried accessing the linux vm with SSH from browser and IAP desktop both also worked fine.

Please help with what might be blocking in my local machine to access SSH from browser and accessing IAP desktop. If we tried to take SSH to linux machine through putty connection from my local machine it is working.

For Accessing SSH connection from browser and IAP  , i am not able to do. Please guide with what might be blocking in my local machine and preventing me from accessing the IAP desktop and is there any checks need to be performed and any port or proxy to be allowed ? . 

[horaciog]

Hello,

According to the error message “Identity Aware proxy failed with code :1006” when you use browser to connect SSH, I d like to suggest to you the below:

Ensure that the Linux VM has an External IP. Please, keep in mind that a VM doesn’t contain an External IP, it’s needed to create a firewall rule specifically to connect through SSH in order to use IAP TCP forwarding. IAP TCP forwarding is the way that VM instances use in GCP to connect through SSH when there is no External IP(s).

Also ensure that the user has 'Instance Admin v1' as well as 'IAP Secure Tunnel User' permissions on the VM and that IAP API is enabled

To create the firewall rule, it will be necessary to follow the next steps:

1. In the GCP Console, open the Firewall Rules page.
2. On the Firewall Rules page, click “Create firewall rule”.
3. Configure the following settings:

Name: allow-ingress-from-iap

Direction of traffic: Ingress

Target: All instances in the network

Source filter: IP ranges

Source IP ranges: 35.235.240.0/20

Protocols and ports: Select TCP and enter 22,3389 to allow both RDP and SSH.

1. Click Create.
2. Try to connect using Browser.

When the firewall rule is created, granting user/groups permissions to use IAP for TCP forwarding on IAM & Admin will be needed. There is a recommended role to manage VM accesses: roles/iap.tunnelResourceAccessor. Please, keep in mind that users that have Owner access to a project always have permission to use IAP for TCP forwarding.

If you want to have a better understanding about IAP TCP forwarding and also have more information about how to create the firewall rule or grant permissions.

I hope you find this information helpful.

[Mr-Fred]

I have a similar issue with ssh-in browser. When i create the VM at first i could connect with no issue but after setting up Chrome remote-desktop i started getting "Code : 4003

Motif : failed to connect to backend

Please ensure that: - VM has a firewall rule that allows TCP ingress traffic from the IP range 35.235.240.0/20, port: 22 - you can make a proper https connection to the IAP for TCP hostname: https://tunnel.cloudproxy.app"

I ran the troubleshoot and everything came out ok. I also ran connectivity check which came out ok. And i have the firewall rule setup for iap tunnel.

I am able to ssh in-browser into other VMs in the same project with the network tag. I can't quite figure out where exactly the issue is. Could this be a bug? 

PS: Might worth mentioning that on chrome remote desktop page the VM shows as offline.

[kolban]

When I run into similar problems and the documentation points to firewall rules, I commonly set up a new rule that overrides the default deny all rule but this time with logging enabled.  I then re-run my test and then go and look in Cloud Logging and find a record relating to the failed connection and then have an "aha" moment.

To explain a little further, there is a default rule in the Firewall environment which is "deny all".  This rule has the lowest possible priority so any rule you add that allows something has higher precedence.  However, the deny all rule does not have logging enabled.  If you create a NEW deny all rule that has priority lower (eg. 10000) that ALSO denies all but has logging enabled ... it will be that rule that denies incoming traffic and effectively you will have exactly the same rules but this time with more diagnostics.