Permission denied (publickey,gssapi-keyex,gssapi-with-mic)

后端 未结 11 1058
有刺的猬
有刺的猬 2020-12-04 16:42

After creating the instance, I can login using gcutil or ssh. I tried copy/paste from the ssh link listed at the bottom of the instance and get the same error message.

相关标签:
11条回答
  • 2020-12-04 17:03

    I followed everything from here: https://cloud.google.com/compute/docs/instances/connecting-to-instance#generatesshkeypair

    But still there was an error and SSH keys in my instance metadata wasn't getting recognized.

    Solution: Check if your ssh key has any new-line. When I copied my public key using cat, it added into-lines into the key, thus breaking the key. Had to manually check any line-breaks and correct it.

    0 讨论(0)
  • 2020-12-04 17:05

    I had the same problem and for some reason The sshKeys was not syncing up with my user on the instance.

    I created another user by adding --ssh_user=anotheruser to gcutil command.

    The gcutil looked like this

    gcutil --service_version="v1" --project="project"  --ssh_user=anotheruser ssh  --zone="us-central1-a" "inst1"
    
    0 讨论(0)
  • 2020-12-04 17:05

    I found this error while connecting ec2 instance with ssh. and it comes if i write wrong user name.

    eg. for ubuntu I need to use ubuntu as user name and for others I need to use ec2-user.

    0 讨论(0)
  • 2020-12-04 17:06

    The permission denied error probably indicates that SSH private key authentication has failed. Assuming that you're using an image derived from the Debian or Centos images recommended by gcutil, it's likely one of the following:

    1. You don't have any ssh keys loaded into your ssh keychain, and you haven't specified a private ssh key with the -i option.
    2. None of your ssh keys match the entries in .ssh/authorized_keys for the account you're attempting to log in to.
    3. You're attempting to log into an account that doesn't exist on the machine, or attempting to log in as root. (The default images disable direct root login – most ssh brute-force attacks are against root or other well-known accounts with weak passwords.)

    How to determine what accounts and keys are on the instance:

    There's a script that runs every minute on the standard Compute Engine Centos and Debian images which fetches the 'sshKeys' metadata entry from the metadata server, and creates accounts (with sudoers access) as necessary. This script expects entries of the form "account:\n" in the sshKeys metadata, and can put several entries into authorized_keys for a single account. (or create multiple accounts if desired)

    In recent versions of the image, this script sends its output to the serial port via syslog, as well as to the local logs on the machine. You can read the last 1MB of serial port output via gcutil getserialportoutput, which can be handy when the machine isn't responding via SSH.

    How gcutil ssh works:

    gcutil ssh does the following:

    1. Looks for a key in $HOME/.ssh/google_compute_engine, and calls ssh-keygen to create one if not present.
    2. Checks the current contents of the project metadata entry for sshKeys for an entry that looks like ${USER}:$(cat $HOME/.ssh/google_compute_engine.pub)
    3. If no such entry exists, adds that entry to the project metadata, and waits for up to 5 minutes for the metadata change to propagate and for the script inside the VM to notice the new entry and create the new account.
    4. Once the new entry is in place, (or immediately, if the user:key was already present) gcutil ssh invokes ssh with a few command-line arguments to connect to the VM.

    A few ways this could break down, and what you might be able to do to fix them:

    1. If you've removed or modified the scripts that read sshKeys, the console and command line tool won't realize that modifying sshKeys doesn't work, and a lot of the automatic magic above can get broken.
    2. If you're trying to use raw ssh, it may not find your .ssh/google_compute_engine key. You can fix this by using gcutil ssh, or by copying your ssh public key (ends in .pub) and adding to the sshKeys entry for the project or instance in the console. (You'll also need to put in a username, probably the same as your local-machine account name.)
    3. If you've never used gcutil ssh, you probably don't have a .ssh/google_compute_engine.pub file. You can either use ssh-keygen to create a new SSH public/private keypair and add it to sshKeys, as above, or use gcutil ssh to create them and manage sshKeys.
    4. If you're mostly using the console, it's possible that the account name in the sshKeys entry doesn't match your local username, you may need to supply the -l argument to SSH.
    0 讨论(0)
  • 2020-12-04 17:06
    1. Add ssh public key to Google cloud
    • cat ~/.ssh/id_rsa.pub
    • go and click your VM instances
    • edit VM instances
    • add ssh public key(from id_rsa.pub) in SSH keys area
    1. ssh login from Git bash on your computer

      ssh -i ~/.ssh/id_rsa tiennt@x.y.z.120

    0 讨论(0)
  • 2020-12-04 17:12

    I just experienced a similar message [ mine was "Permission denied (publickey)"] after connecting to a compute engine VM which I just created. After reading this post, I decided to try it again.

    That time it worked. So i see 3 possible reasons for it working the second time,

    • connecting the second time resolves the problem (after the ssh key was created the first time), or
    • perhaps trying to connect to a compute engine immediately after it was created could also cause a problem which resolves itself after a while, or
    • merely reading this post resolves the problem

    I suspect the last is unlikely :)

    0 讨论(0)
提交回复
热议问题