I was having issues with internet access on a Windows Server 2012 VM, and accidentally disabled the NIC via RDP. Now I can't access the VM.
I tried editing the instance from console; I wanted to add a 2nd NIC, but couldn't do so. I saw something about having to add another "network" but couldn't figure it out.
Is there any way to re-access this VM??
You can re-enable the network interface on the Windows VM using the Serial port.
Try these steps:
Open the VM instance page from the Google Cloud Platform Console.
Click Edit on the top bar.
Enable the Enable connecting to serial ports option and click Save.
Start the VM if it isn't already running.
You will be taken back to the VM's info page and now you can select Connect to Serial port dropdown, select Port 2.
A new window will open up and you will get the Special Administration Console (SAC). Run cmd in this serial command prompt.
Open up Command prompt channel by pressing Esc + Tab.
You will have to login as admin on that instance using your admin credentials.
In the command prompt, you can enable back your network interface by running these commands:
Commands:
# List all network adapters - The name is important
netsh interface show interface
# Enable the network adapter
netsh interface set interface "MY_NETWORK_ADAPTER_NAME" admin=enable
Your instance's network adapter should now be enabled and you should have network access to your VM now.
I have observed similar problem on a windows server, where it was not able to resolve Metadata server and auto assigned an APIPA address 169.254.x.x
Performed troubleshooting steps as per Google documentation, also tried with restarting network related services, nothing worked. Finally reached to this post and tried the following and it got fixed..!
netsh interface set interface name="NAME OF INTERFACE" admin=disabled
netsh interface set interface name="NAME OF INTERFACE" admin=enabled
Not sure why windows behaves as such, Hope this helps
Related
Apologies if this is a bit basic:
I have a Google Compute Instance running Windows Server 2012 R2. It has a valid admin account and password (checked via gcloud). The external IP address can be pinged, the system has been stopped and started successfully. The gcloud commands execute successfully etc etc.
If I try to RDT in I get the unsuccessful message. If I use the RDT (Chrome) option in the Google Cloud Platform admin page I get this message:
In order to use the Chrome RDP Extension, you must configure VM
instance so that it has an external IP address, username and password.
Note: You must configure the network firewall to open TCP port 3389 to
enable RDP access.
Note that ALL of the above are correct and confirmed.
I am sort of going round in circles, I've tried to use powershell on a windows system to RDT in to no avail. Again, using the built in Bash serial access I can get to the system and, for example, retrieve the admin account and password, BUT RDT FAILS.
I have tried using the powershell command Enter-PSSEssion... and I initially got a winrm error, apparently the IP address needs to be in trustedhosts. Fixed that and now I am getting a message that I need to verify that winrm is running on the destination computer, catch 22, that's why I'm using winrm, to access the destination computer.
Any ideas what I might try next?
Thanks.....
create a rdp network tag for firewall rule, which allows tcp:3389 ingress and and then apply it to the instance in question... someone (assuming you're at work) might have removed/edited these rules trough the console or gcloud command.
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.
I accidentally disabled the network adapter on Windows virtual machine on compute engine. I tried delete-access-config and add-access-config through gcloud utility and that did not seem to make any difference. Any suggestions on how to enable the network adapter back so I can RDP back into VM or am I going to have to re-build the VM?
Thanks,
To those having this issue in 2017. I was just having same problem and spent a day trying to figure out a solution. I ended up successfully enabling network adapter using serial port connection. Here are the steps:
1) Open Google Compute VM instance from the console and click "Edit"
2) Scroll down to "Serial Port" and enable it. Save...
3) Select drop down next to "Connect to serial port" and chose "Port 2"
4) New window will open with serial command prompt. Run "cmd" command in it
5) Once executed switch to cmd channel by pressing ESC+Tab
6) Authenticate with user credentials that has admin rights on your instance
7) Now you have access to your instance command prompt. To enable your network interface run the following commands:
netsh interface show interface (this will show you all network adapter names, remember the name of the one you need to enable)
netsh interface set interface "network_adapter_name" admin=enable
(e.g netsh interface set interface "MyEthernet" admin=enable)
8) Show everyone around how happy you are to figure this one out.
At present, there's no way to enable a disabled network interface on a Windows GCE VM, therefore rendering RDP unusable. Recreating the VM anew seems like the only option.
In order not to lose data from your disabled instance, make sure "Delete boot disk when instance is deleted" is unchecked in the Developers Console configuration for this VM prior to deleting the instance. You can then attach the left-behind disk to your new instance, in order to retrieve data. Afterwards you may keep or delete the additional disk.
I've just created an instance using Google Cloud Platform's Compute Engine and tried to connect to it via SSH connection but it failed.
I'm following the quick start here.
I have generated the SSH key on my PC and have entered the pass-phrase when asked. Though I fail to succeed a log in :-(
I got the PuTTY SSH's error as below snapshots.
Then I get the PuTTY window inactive.
I have the same problem but found a workaround to connect via PuTTY manually.
In brief
Generate SSH key for the machine instance
Add SSH public key to the instance
Prepare to log in - acquiring information for IP, login name, pass phrase, private SSH key
Connect to the instance via SSH client, e.g. PuTTY in Windows
Detail steps
For me the gcloud quick start had already:
launched my instance
created my public and private RSA keys (in C:\Users\USER_NAME\.ssh\)
Public Key - C:\Users\USER_NAME\.ssh\google_compute_engine.pub
Private Key - C:\Users\USER_NAME\.ssh\google_compute_engine.ppk
Go to the Google Developers Console in your browser
Select your project and in the left hand nav bar click: Compute -> Compute Engine -> VM instances
Your running instance(s) will be linked below the CPU usage chart
Click the one you want and find the Add SSH key link and click it
Paste the entire contents of google_compute_engine.pub into the field that appears
Click Save and after a few seconds the key details will appear on the page (if you get an error you pasted from the wrong key file or didn't copy all the text)
The first word in those details is your (case sensitive) username
Find the External IP above on the page
Open PuTTY and paste the external IP into Host Name (port is the default of 22)
In the left hand nav expand: Connection -> SSH and then click Auth
Next to "Private key file for authentication" click "Browse"
Select "C:\Users\USER_NAME\.ssh\google_compute_engine.ppk" and click Open
Scroll the left hand nav back up and click the top item "Session"
Under "Saved Sessions" enter a name and click "Save"
Accept the warning message and you should be prompted to login with the username from above step
Input your passphrase
Done
Hope this helps. If someone has a solution for the gcloud issue I'd love to hear it too.
A non-discussed answer is that you should have at least the standard memory on your VM instance (3.75GB) - do NOT use Micro VM instances.
I could only log in with SSH via browser console or gcloud command line, but not with Putty or Mac terminal SSH.
I spent an hour on the phone with support and we found this to be the problem.
To get identified by ssh you need to run this command, which add gcloud ssh key in the list of ssh keys
ssh-add google_compute_engine C:\Users\USER_NAME\.ssh\
You can also connect to your VM instance using embedded in-browser SSH client, see here for how to do that. That's pretty much a couple of mouse click to do.
Not sure why, if the user already existed (eg: already SSH logged in google web console), it doesn't work when I manually added SSH keys into metadata on google web console. I have tried hundred of times from the steps below.
I found out you have to manually add your ssh key through web SSH CONSOLE -> ssh in on google web console and copy ssh pub key on your local machine (usually is in ~/.ssh/) and append (edit and paste to the end) it to ~/.ssh/authorized_keys.
1) SSh into the vm by cloud console.
2) Change the root password sudo passwd
3) set below parameters to yes by nano /etc/ssh/sshd_config
PasswordAuthentication
PermitRootLogin
PasswordAuthentication
4) restart sshd service sshd restart
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.