Unable to connect to VM's through Cloud Shell

[udaysrinivas]

I've been trying to connect to my VMs through Cloud Shell using the cloud command. 

But every time I try it's giving me this error:

root@cs-551720538893-default:/home/user# gcloud compute ssh --zone "us-east4-a" "hostname" --tunnel-through-iap --project "project_id"
Writing 3 keys to /root/.ssh/google_compute_known_hosts
WARNING:

To increase the performance of the tunnel, consider installing NumPy. For instructions,
please see https://cloud.google.com/iap/docs/using-tcp-forwarding#increasing_the_tcp_upload_bandwidth

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:****************************************.
Please contact your system administrator.
Add correct host key in /root/.ssh/google_compute_known_hosts to get rid of this message.
Offending RSA key in /root/.ssh/google_compute_known_hosts:3
remove with:
ssh-keygen -f "/root/.ssh/google_compute_known_hosts" -R "compute.***********"
ECDSA host key for compute.******** has changed and you have requested strict checking.
Host key verification failed.

Recommendation: To check for possible causes of SSH connectivity issues and get
recommendations, rerun the ssh command with the --troubleshoot option.

gcloud compute ssh hostname --project=projectId --zone=us-east4-a --troubleshoot

Or, to investigate an IAP tunneling issue:

gcloud compute ssh hostname --project=projectId --zone=us-east4-a --troubleshoot --tunnel-through-iap

ERROR: (gcloud.compute.ssh) [/usr/bin/ssh] exited with return code [255].
root@cs-*******-default:/home/user#

[alexmoore]

When you connect to a VM the first time, your SSH client stores the key of the host - i.e. the identity of the host - in the known_hosts file.  So that next time you connect to the same VM, if the identity changes, it could be an indication that the system has been compromised or someone is intercepting your connection and you should proceed with caution.  However, if you know why the identity has changed - for example you redeployed the VM with the same name which caused the key to change - and so you still trust that you are reaching the right system, then you can simply remove the old key from the known_hosts file - in fact it is providing you the command to do this in the error with the "ssh-keygen -f" command.  Then next time you connect it will prompt you to store the new key.

[udaysrinivas · Accepted solution]

Thanks for the reply but what helped me was, adding this flag --strict-host-key-checking=no to the gcloud command. 

[alexmoore]

While this will work, it isn't advisable.  Host key checking is a security mechanism that will alert you to a potentially compromised system or a man in the middle attacks, disabling it will solve your problem, but if you are confident that the reason for the host key change is due to your actions, you can update the host key stored with the command provided ("ssh-keygen -f ..."), so that next time it won't raise the error - and if it does, you know to investigate further (unless of course it was something you changed again to trigger it). 

You can read more about SSH host keys here: https://www.ssh.com/academy/ssh/host-key