Can't connect to GCP VM Permission denied (publickey) error

Viewed 2864

I'm creating a new VM instance. I've clean all the meta data. Then I'm running the following command in the cloud shell:

gcloud beta compute ssh --zone "europe-west2-c" "vmname"  --project "myprojectname"

then I've been asking to enter a passphrase (which I don't know). I press enter until I get the following error Permission denied (publickey) error

I've delete and recreated my instance multiple time but I always have the same error. What should I do?

4 Answers

Troubleshooting Steps:

  1. Logon using UI ssh. This creates an ephemeral ssh key, Google Agent also executes the codepath to refresh .ssh/authorized_keys and address any invalid dir/file permissions for both .ssh/ and .ssh/authorized_keys. This approach will address common gcloud compute ssh issues that relates to corrupted keys, missing dir/file or invalid dir/file permission. Try the gcloud again after performing the UI ssh.
  2. Make sure that account has authenticated to gcloud as an IAM user with the compute instance admin role; for example, run gcloud auth revoke --all, gcloud auth login [IAM-USER] then try gcloud compute ssh again.
  3. Verify that persistent SSH Keys metadata for gcloud is set for either the project or instance. Look in Compute Engine > Metadata, then click SSH Keys. Persistent keys do not have the expireOn attribute.
  4. It's possible the account has lost the private key, mismatched a keypair, etc. You can force gcloud to generate a new SSH keypair by doing the following:
    Move ~/.ssh/google_compute_engine and ~/.ssh/google_compute_engine.pub if present.
    For example:
    mv ~/.ssh/google_compute_engine.pub ~/.ssh/google_compute_engine.pub.old
    mv ~/.ssh/google_compute_engine ~/.ssh/google_compute_engine.old
    Try gcloud compute ssh [INSTANCE-NAME] again. A new keypair will be created and the public key will be added to the SSH keys metadata.
  5. Verify that the Linux Google Agent scripts are installed, up-to-date, and running. See Determining Google Agent Status. If the Linux Google Agent is not installed, re-install it. See guest-environment.
  6. Verify account home owner/permission is correct. Make sure that account home directory has the correct ownership and is not globally writable. If not using os-login (which is default), your's .ssh folder must have mode 0700, .ssh/authorized_keys file must have mode 0600. Review /var/log/auth.log for any errors.
    Commands:
    sudo chmod 700 /home/[user-id]/.ssh
    sudo chmod 600 /home/[user-id]/.ssh/authorized_keys
  7. If os-login is enabled and the Virtual Machine instance is using a service account (default). Add the following roles to the account.
    roles/compute.osLogin
    roles/iam.serviceAccountUser

For more information troubleshooting SSH.

The possible causes for a Permission denied (publickey) error are:

  • Your key expired and Compute Engine deleted your ~/.ssh/authorized_keys file.
  • You used an SSH key stored in metadata to connect to a VM that has OS Login enabled.
  • You used an SSH key stored in an OS Login profile to connect to a VM that doesn't have OS Login enabled.
  • You connected using a third-party tool and your SSH command is misconfigured.
  • The sshd daemon isn't running or isn't configured properly.

You can find more information on how to troubleshoot SSH key errors in this link

I have the same issue sometimes . Cause and solution according to GCP troubleshooting link is:

Your key expired and Compute Engine deleted your ~/.ssh/authorized_keys file. If you manually added SSH keys to your VM and then connected to your VM using the Google Cloud Console, Compute Engine created a new key pair for your connection. After the new key pair expired, Compute Engine deleted your ~/.ssh/authorized_keys file in the VM, which included your manually added SSH key.

To resolve this issue, try one of the following:

Connect to your VM using the Google Cloud Console or the gcloud command-line tool. Re-add your SSH key to metadata. For more information, see Add SSH keys to VMs that use metadata-based SSH keys.

I use terraform so in this case I instructed the workflow to destroy the VM and rebuild it.

To fix this issue when you cannot start ssh:

  1. Edit VM and enable Serial port
  2. Start serial console
  3. Edit ~/.ssh/authorized_keys
  4. On your desktop/client,
    • edit /Users/[yourdesktopuser]/.ssh/id_rsa.pub
    • copy contents to clipboard
    • Paste this content to the end of authorized_keys file in the VM serial console
    • Save and close

This will then recognize the public key from your desktop

Related