SSH to Google Compute Engine Instance Failing - google-compute-engine

I created a simple f1 micro instance (Ubuntu 16.10) on Google Compute Engine. I had created a VPC (Networking) and allowed http/https. I explicitly created a Firewall rule to allow SSH (tcp:22). But I am not able to login to the VM instance.
I keep getting this error:
Here is my Firewall Rule:
How to fix this?

I was able to finally ssh into an instance by Choosing "Automatic" while creating a new VPC network instead of Custom and also chose allow ssh. This added default Firewall rules which were more accurate.

For anyone that runs into this problem I reached out to Google support by email (who responded!!) and they instructed me to run the following commands from terminal (where I have gcloud installed):
If you haven't yet authenticated / or to set the correct project
gcloud auth login
gcloud config set project PROJECT_ID
This is the meat of it - setting the firewall rules.
gcloud beta compute firewall-rules create default-allow-ssh --allow tcp:22 --priority=65534
Also - use chrome - the interface seems to occasionally throw a fit whenever you use any other browser.

Related

gcloud compute vpn-tunnels describe [NAME] doesn't all details of a vpn-tunnel

Once you have a vpn tunnel up and running there does not appear to be a method to view all the details of the tunnel from either the Google Cloud Console or the gcloud command line. Specifically the route policies that were configured when the tunnel was initially setup are missing from the describe.
Is there a method to see this information?
This a known behavior. The Developers Console doesn't set the remoteTrafficSelector when creating the tunnels through it.
The Developers Console creates the necessary routes and shows the "Remote ranges" based on them.
The workaround is to create the VPN tunnels using the Compute API or Cloud SDK with the following command:
gcloud compute vpn-tunnels create NAME --region=REGION --peer-address=PEER_ADDRESS --shared-secret=SHARED_SECRET --target-vpn-gateway=TARGET_VPN_GATEWAY --local-traffic-selector=CIDR --remote-traffic-selector=CIDR
You can click on the star icon in the Public Issue Tracker to get updates when there is any progress on it.
Note: This doesn't have any impact on the VPN tunnel functionality.

reset windows firewall without deleting instance

I accidentally messed up Windows Firewall of my VPS and now I can't connect using RDP anymore.
Is there a way to reset the firewall rules without deleting and creating a new instance? Already checked the FAQs and found nothing about it, same goes for the cloud shell. The firewall rules that I can see on the web manager seems different of my Operational System firewall.
The best way is to use Google Cloud console.
Go to the Windows Instance
Edit the Instance and add the following key/value pair to Custom Metadata section
key is: windows-startup-script-cmd
value: netsh advfirewall set allprofiles state off
This resets the firewall to Off when booting and you can get back in with the RDP client as before.
Please open Cloud Shell on Google Cloud Platform web console.
Type: gcloud compute firewall-rules create openrdp --allow=tcp:3389
Try to connect your machine again.

Block offending IP from Google Compute Instance

Is there a network-level IP address blocking/blacklist capability to a Google Compute Engine instance? For example, a site is hosted on a GCE instance to allow public users access. However, a malicious script runs several times/second which is not legitimate traffic. Ideally, the IP of the offending user could be placed on a block list so traffic would not be routed to the instance, rather than just server side only mechanism (apache modules, IPtables, etc) which still requires CPU/RAM/disk resources.
You can setup an HTTP load balancer for your instances, and allow traffic only from the LB IP address to your instances. More information can be found in this Help Center article.
GCP does not provide WAF natively. You can use marketplace WAF (like Brocade WAF) to block IPs.
https://cloud.google.com/launcher/solution/brocade-public-1063/stm-csub-1000-h-saf?q=brocade
This is absolutely not the recommended way to manage your firewall blacklist.
However...
In the compute GUI, you can create a firewall rule set action on match to "deny" and protocols and port to "deny all". Then set source IPs.
compute GUI
You could then run a cron job to update your firewall through gcloud compute firewall-rules update to update source IPs should your list change.
Note (from Google - https://cloud.google.com/vpc/docs/using-firewalls):
gcloud compute firewall-rules update is used to update firewall rules that allow/deny incoming/outgoing traffic. The firewall rule will only be updated for arguments that are specifically passed. Other attributes will remain unaffected. The action flag (whether to allow or deny matching traffic) cannot be defined when updating a firewall rule
Yes you can block it using Gcloud Firewall.
Try creating the firewall rule from the command line or by logging into Google Cloud.
Example:
gcloud compute firewall-rules create tcp-deny --network example-network --source-ranges 10.0.0.0/8 --allow !tcp:80
Above Rule will block the range 10.0.0.0/8 to port 80 (tcp).
Same can be done to block other IP Ranges over tcp and udp.
For more info check this: glcoud network config

How do I enable http traffic for GCE instance templates?

When creating an instance template in Google Compute Engine, how do I enable http traffic for instances created from the template?
I was thinking that providing an http tag would work, but it doesn't seem to do so.
The default network in the project comes with default firewall rules "default-allow-http" and "default-allow-https" to allow traffic on port 80 and 443. These rules have a target tag setup as "http-server". When setting up the instance template you can check the box "Allow HTTP traffic" and "Allow HTTPS traffic" from your developer console, by doing that the default firewall rules will be applied to the new instances created through this instance template.
The following should work in theory, but in practice, it didn't work.
One potential solution is to enable http traffic for all of your instances in that project. To do so, from within GCE command line tools, run:
gcloud compute firewall-rules create FIREWALL_RULE --allow tcp:80
It's not clear to me that setting the rule for a particular instance template is possible, but hopefully someone will correct me if it is.
One potential solution is to enable http traffic for all of your instances >in that project. To do so, from within GCE command line tools, run:
gcloud compute firewall-rules create FIREWALL_RULE --allow tcp:80
I try your command but it doesn't work because the command want the name of the instance:
google130505_student#qwiklabs-gcp-286ef104ac93631b:~$ gcloud compute firewall-rules create FIREWALL_RULE --allow tcp:80
Creating firewall...failed.
ERROR: (gcloud.compute.firewall-rules.create) Could not fetch resource:
- Invalid value for field 'resource.name': 'FIREWALL_RULE'. Must be a match of regex '(?:[a-z](?:[-a-z0-9]{0,61}[a-z0-9])?)'
google130505_student#qwiklabs-gcp-286ef104ac93631b:~$ gcloud compute firewall-rules create gclab2 --allow tcp:80
Creating firewall.../Created [https://www.googleapis.com/compute/v1/projects/qwiklabs-gcp-286ef104ac93631b/global/firewalls/gclab2].
Creating firewall...done.
NAME NETWORK DIRECTION PRIORITY ALLOW DENY
gclab2 default INGRESS 1000 tcp:80
so the correct command is:
gcloud compute firewall-rules create NAME_OF_YOUR_INSTANCE --allow tcp:80
gcloud compute firewall-rules create FIREWALL_RULE --allow tcp:80,tcp:443
This command should do it
If the query is allowing this vm as http or https server then I just used successfully:
cloud compute instances add-tags myvm1 --tags=http-server

Using GUI for VM instance created in Google Compute Engine

I am a very basic user in Google Cloud Platform.
Is it possible to use a GUI of my VM instance ? I am currently using Centos7 VM.
You can use VNC to connect to VMs on Google Compute Engine. Here's a detailed tutorial for how to set this up.
For added security:
use a long, complex password (though note that VNC limits passwords to 8 characters)
instead of opening up port 5901 to the Internet, consider using an SSH tunnel. This is more complex, and depending on your Internet connection, may slow down your graphics refresh rate, but will be more secure.
To use the alternative approach with an SSH tunnel, here are the differences from the tutorial you need to follow:
don't open port 5901 in the Google Compute Engine firewall
create an SSH tunnel from your desktop/laptop to GCE VM via:
gcloud compute ssh \
${VM_INSTANCE} \
--project $PROJECT \
--zone $ZONE \
--ssh-arg "-L ${LOCAL_PORT}:localhost:5901"
where you need to provide the right parameters for ${VM_INSTANCE}, $PROJECT, and $ZONE that match your configuration. You can choose ${LOCAL_PORT} to be 5901 if you wish, but if you decide to VNC into several different GCE VM instances, you'll have to choose unique ports for your local machine.
You need to keep this connection open to use VNC. If this connection is closed, you will lose VNC access as well.
Instead of connecting to your VM using its external IP, connect via localhost:${LOCAL_PORT} with ${LOCAL_PORT} same as selected earlier in step #2
My need was to connect a Windows TightVNC client to Google Compute Engine Cloud Instance of Debian 10 (Buster). The various tutorials I have worked through omitted one important step: make sure the vnc server is not restricted to localhost.
The essential steps for Google Cloud are summarized as
confirm you have a running VM instance and that you have ssh access.
I explicitly disabled enable-oslogin (how to disable oslogin)
and loaded my own Puttygen-created SSH certificate.
in VPC Networks > Network Interface Details > Firewall and routes > Rules add a rule to allow ingress for ip range 0.0.0.0/0 (or a
known limited range), for tcp:5900-5920 (this allows for up to 20
VNC instances)
set up the VNC server (tutorials here and for debian 9
here and for debian 10 here and more complete and recent
here for debian 10
after doing this, I could not get past "Connection refused."
Missing step: make sure -localhost no is included as argument when starting the vncserver:
vncserver -localhost no
Once all these conditions were satisfied, I had desktop access.