Score:1

Permission denied (publickey) - in setting up Kubernetes cluster with Kubespray

ru flag

This issue is from the following documentation How to deploy Kubernetes using Kubespray. I followed their documentation word by word and reached at this point:

ansible -i inventory.ini -m ping all

Here is the above command in the documentation

The documentation outlines all the necessary steps on deploying Kubernetes to UpCloud using Kubespray and Terraform. As mentioned earlier, I could execute all the commands until hitting the command: ansible -i inventory.ini -m ping all

Enter passphrase for key '/home/summer/.ssh/id_rsa':
kubespray-worker-2 | UNREACHABLE! => {
    "changed": false,
    "msg": "Failed to connect to the host via ssh: Warning: Permanently added '<IP address>' (ECDSA) to the list of known hosts.\r\nubuntu@<IP address>: Permission denied (publickey).",
    "unreachable": true
}

Enter passphrase for key '/home/summer/.ssh/id_rsa':
kubespray-worker-0 | UNREACHABLE! => {
    "changed": false,
    "msg": "Failed to connect to the host via ssh: Warning: Permanently added '<IP address>' (ECDSA) to the list of known hosts.\r\nConnection closed by <IP address> port 22",
    "unreachable": true
}

Enter passphrase for key '/home/summer/.ssh/id_rsa':
kubespray-worker-1 | UNREACHABLE! => {
    "changed": false,
    "msg": "Failed to connect to the host via ssh: Warning: Permanently added '<IP address>' (ECDSA) to the list of known hosts.\r\nubuntu@<IP address>: Permission denied (publickey).",
    "unreachable": true
}
kubespray-master-0 | UNREACHABLE! => {
    "changed": false,
    "msg": "Failed to connect to the host via ssh: Warning: Permanently added '<IP address>' (ECDSA) to the list of known hosts.\r\nubuntu@<IP address>: Permission denied (publickey).",
    "unreachable": true
}

the above error in image form for further reference

Please note: The region hidden in white inks are the Public IP addresses assigned to each node in the image above.

I am able to remotely access the Ubuntu server by hitting: ssh <username>@<ip_address>. Here is a snapshot of cluster-settings.tfvars to see if I have messed-up something:

zone     = "fe-fxfx"
username = "ubuntu"

# Prefix to use for all resources to separate them from other resources
prefix = "kubespray"

inventory_file = "inventory.ini"

#  Set the operating system using UUID or exact name
template_name = "Ubuntu Server 20.04 LTS (Focal Fossa)"

ssh_public_keys = [
  # Put your public SSH key here
  "removed the Public Key for security reasons",
]

Also, the image from cluster-settings,tfvars file for reference: cluster-settings.tfvars

The result from pinging the nodes are also irregular, in a sense, if master-0 is successfully pinged at one instance, in the other, none of them gets pinged [when tried again]. While, sometimes worker-2 is pinged and rest are not.

Romeo Ninov avatar
in flag
Replace the images with text
Score:0
ru flag

I found the answer to this issue after consulting a senior mate. First off, the SSH key pair needs to be generated without a passphrase or if you're using one with a passphrase on, just pass this command to disable it:

Run ssh-keygyen with -p option.

ssh-keygen -p

I suggest you to do this inside the directory where your SSH key-pair is located or specify it with -f ~/<username>/.ssh/id_rsa

If you did the above step correctly, then you'll be prompted to enter the existing passphrase:

Enter old passphrase:

After that, enter the new passphrase [basically leave it blank] and confirm it:

Enter new passphrase (empty for no passphrase):
Enter same passphrase again:

If successful, you will get the following prompt:

Your identification has been saved with the new passphrase.

Note: These steps can be used to remove or change the passphrase.

Next Inside the cluster-settings.tfvars file, there are two places with "enter your SSH key here" option to enter your public keys. It is not mandatory to enter in both. In my case, I used only one of the public keys and also made sure the key pair was available in SSH agent.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.