Why can't AzureRmAks find SSH key when deploying new Kubernetes cluster?

9/2/2020

Last night I used PowerShell to deploy a Kubernetes cluster on AKS with something like this:

New-AzureRmAks -ResourceGroupName "my-rg" -Name "my-aks-cluster" -KubernetesVersion "1.16.13" -NodeCount 2 -NodeVmSize "Standard_DS2_V2" -Verbose

This worked fine. Today, however, I tried this same thing in a different subscription, but keep getting the following error:

VERBOSE: Cluster does not exist.
VERBOSE: Cluster is new.
VERBOSE: Performing the operation "Creating a managed Kubernetes cluster." on target "my-aks-cluster in my-rg".
VERBOSE: Preparing for deployment of your managed Kubernetes cluster.
VERBOSE: Using location eastus from the resource group my-rg.
VERBOSE: Using DNS name prefix my-aks-cluster-my-rg-dcdf2a.
VERBOSE: Fetching SSH public key from file C:\Users\myuser\.ssh\id_rsa.pub
New-AzureRmAks : The given key was not present in the dictionary.
At line:1 char:1
+ New-AzureRmAks -ResourceGroupName "my-reg" -Name "my-aks-cluster" -Kube ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : CloseError: (:) [New-AzureRmAks], KeyNotFoundException
    + FullyQualifiedErrorId : Microsoft.Azure.Commands.Aks.NewAzureRmAks

I'm confused because: 1. This same command worked earlier 2. I have same admin rights to new subscription as to the one previously used 3. The path to the key is valid 4. The key, id_rsa.pub, is at the path listed

Anyone have an idea what is going on here? Any tips are appreciated.

-- Zeke MC
azure
azure-aks
kubernetes
powershell
ssh

1 Answer

9/3/2020

I can reproduce this issue with the same user account when only changing to a new subscription in another directory.

To fix it, you can delete all files but leave TokenCache.dat file in the .Azure folder of the path

C:\Users\myuser\.Azure

enter image description here

Then re-connect the subscription.

enter image description here

Edit

In this case, deleting the file acsServicePrincipal under the local .azure directory is to fix this issue.

-- Nancy Xiong
Source: StackOverflow