Cant VNC into Google Compute Engine - google-compute-engine

I have spent a couple days trying to install software on Google Compute Engine (GCE) and then remotely access it from either my windows pc or local linux machine.
I can install software, like Google Chrome, etc. but can't open the applications as I keep getting display issues (understandably because GCE is headless). So I'm trying to VNC into the GCE instance.
I have tried installing the following on the server: (Instance Name is "talend")
vnc4server: I get output saying the server is running and everything looks good. Only error I get is a Language error like the following:
steven#talend:~$ vnc4server -geometry 1440x900 :1
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:LANGUAGE = (unset),LC_ALL = (unset),LANG = "en_ZA.UTF-8"are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
A VNC server is already running as :1
and
steven#talend:~$ vnc4server -geometry 1440x900 :2
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:LANGUAGE = (unset),LC_ALL = (unset),LANG = "en_ZA.UTF-8"are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
New 'talend:2 (steven)' desktop is talend:2
Starting applications specified in /home/steven/.vnc/xstartup
Log file is /home/steven/.vnc/talend:2.log
Remote Access: Using TightVNC client via Windows
I get the following message:
No connection could be made because the target machine actively refused it.
Remote Access: Using Vinagre via Linux
Connection to host 8.34.210.67::5902 was closed.
Via Google Compute Engine Web Console:
Tried changing to static ip > No Difference
Tried adding tcp:80 with Source: 0.0.0.0/0 > No Difference
I'm sure there is a simple solution to this but I can't seem to find it. Any help will be appreciated and then will post a link to the final solution.
Thanks.

You will need to configure three settings to all agree on the same port:
The port vnc4server is listening on.
A Compute Engine firewall rule to allow traffic on that port.
The port TightVNC is attempting to connect to.
From the error message "Connection to host 8.34.210.67::5902 was closed.", it looks like TightVNC is trying to connect to 5902. Assuming that vnc4server is also listening on that port, you should add a Compute Engine firewall rule to allow that port.
Visit the Console at https://cloud.google.com/console, click on your project, then Compute Engine, then Networks. Click the "Create new" next to "Firewalls" and add a new rule with tcp:5902 set in the Ports/Protocols field.
If you're running on Centos, there is an additional step to disable the local firewall as well: CentOS Firewall Issues on GCE

Another option is to use Guacamole and Tomcat to access your desktop via a browser or VNC client.
Use Aptitude or apt-get to install guacamole-tomcat. I have the VNC port in firewall settings (via tags) as well as http and https. I've set up a "guacamole" tag to use with the firewall as well. Your GCE instance will need these tags assigned. There are some configs to do via /etc/guacamole/ for user/login etc, but essentially it goes like this...
Once installed, the default ports are 8080. So browse to http://:8080/guacamole/ and you will get a Guacamole login screen. When you login, you will have links to click that start your desktop in a browser window.
You can also VNC directly (no browser) via :5901 - or whatever port you configured Guacamole with. It's best of course to have set up a st

Try:
$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
if it is not similar flush:
sudo iptables -F

Related

How to keep persistent SQL Proxy Unix Socket with Google Compute Engine

I have a GCE instance that uses older mysql connection type and in order to connect to a Google Cloud SQL instance, I open an SSH connection through the browser on the GCE instance and run the following:
> cd /
> ./cloud_sql_proxy -dir=/cloudsql -instances=my-gce-instance-name:us-east1:my-sql-instance-name &./cloud_sql_proxy -dir=/cloudsql -
And then it is open for connections. The problem is, when I close the browser window (or even sign into Google with a different user), the connection is lost. Is there any way to persistently run this Unix socket with Google Cloud Engine?
Generally, you can run a command in the background by appending a & to the end of the command. This will start a background process for the proxy. You can stop the proxy with killall cloud_sql_proxy.
Another solution would be to run the proxy as a service. How to do this wildly varies by distro and version. Ubuntu 16 is typically bundled with systemd.

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.

Nitrous.io desktop fails to sync

Nitrous Desktop fails to sync with "Error: connection failed". Even after restart, delete and generate new SSH keys. I moved everything at ~/workspace but it stills says the same. Any ideas?
If you are using Windows then you will want to ensure that the nitrous-ssh app is not being blocked by your Windows firewall. You should have been prompted about this when first enabling File Sync, but if you did not check these boxes when first connecting then you will want to locate it within your firewall settings and allow it on all networks.
You may also want to check that the port which Nitrous Desktop uses is not being blocked by your network. The port can be found within the SSH URI field on the boxes page:
https://www.nitrous.io/app#/boxes
The port # is at the end of the SSH URI.

CentOS Firewall Issues on GCE

I am trying out a "Hello World" exercise for GCE. First, I went with CentOS Image, added the instance, installed Apache, added the Firewall. All looks good as far as configuration is concerned. When I try to access the web page from outside, it cannot reach the page.
The Local Apache Server is running, from the local instance I can do a curl and all is well.
On the other hand, if I try out the same exact steps with the Debian distribution, everything works smoothly.
I saw another post that mentioned about additional firewall settings but I have not tried that out and I am not sure why it should be done either.
Can anyone explain if the CentOS setup does need additional Firewall settings and what those are?
CentOS defaults to a restrictive operating system level firewall (using iptables), while debian defaults to a permissive one. You can relax the firewall rules on CentOS as well. When running on Compute Engine, the service level firewall will only allow connections from the internet via configured ports.
To relax the CentOS firewall:
$ sudo iptables -D INPUT -j REJECT --reject-with icmp-host-prohibited
Then test that your connections work as expected. To save this configuration across system reboots:
$ /sbin/service iptables save
See the IPTables HowTo on the CentOS wiki for more information about working with iptables on CentOS.
You need free the ports in the cloud console.
Watch this video that explain the proccess.
Google Compute Engine Test Drive

When trying to connect through a proxy server TortoiseHg for Windows says "SSL error: unknown protocol"

The scenario:
You're behind a proxy server on Windows. You've configured TortoiseHg to use a proxy server; that is you've entered a server name/IP and port number. You are able to connect to the internet using Internet Explorer. But when you try to pull or push and it produces the error message "SSL error: unknown protocol".
(I plan to answer this myself.)
The cause is that Internet Explorer is using an automatic proxy configuration script and TortoiseHg is using a particular proxy server. IE is not using the same proxy server because the automatic script picked a different proxy server.
The solution is to enter the proxy server used by TortoiseHg in IE's connection settings, or figure out which proxy server you're using at the moment and tell TortoiseHg to use that one. You may need to browse an external web site before TortoiseHg can connect.
You can figure out which proxy server you're using by browsing with IE and then running the DOS command:
netstat
and you'll see some connections in the Foreign Address column on port 80 or 8080 (common proxy server ports).
In addition to your excellent tip, I offer one more...
If your company is using an automatic proxy script, then the proxy used for web browsing may not be the one you need for Mercurial. Thus if you try the proxy you find via netstat, and you get "getaddrinfo failed" errors in tortoise, then try this...
Get the proxy script address: IE->config->Internet Options->Connection->LAN ?Settings. Copy the url from the "Address" box.
Browse to that address and save the file to disk.
Open that file in notepad and scroll to the end, it probably ends with something like-- return "PROXY ipaddresshere:port" that's the IP and port you need.
Plug that IP and port into tortoise: right-click the repo, click settings, click proxy, put the ip and port into the Host field. I generally don't need user and password so try without it first.