<p>I was also encountering the error message when running <code>helm version</code> or <code>helm list</code></p>

<pre><code>kubectl port-forward -n kube-system tiller-deploy-xxxxxxxxxxxxxxx 44134
error: error upgrading connection: error dialing backend: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user "gke-xxxxxxxxxxx"?
</code></pre>

<p>The root issue appears to be related to the GKE port-forwarding. is the ssh key configurable anywhere? I can see this key being added to my metadata, but it is not part of the metadata for the GKE nodes. </p>

turnupthechill
<ul>
<li><a href="https://github.com/helm/helm/issues/4286#issuecomment-401427287" rel="nofollow noreferrer">Under the hood</a> helm is initiating a short-lived <code>kubectl port-forward</code> to tiller.</li>
</ul>

<p>If it's not working, your issue is with that, not tiller:</p>

<ul>
<li><p>Kubectl port-forward rely on the cluster's <strong>master being able to talk to the nodes</strong> in the cluster. However, because the master isn't in the same Compute Engine network as your cluster's nodes, we rely on <strong>SSH tunnels</strong> to enable secure communication.</p></li>
<li><p>GKE saves an SSH public key file in your Compute Engine project metadata. All Compute Engine VMs using Google-provided images regularly check their project's common metadata and their instance's metadata for SSH keys to add to the VM's list of authorized users. GKE also adds a firewall rule to your Compute Engine network allowing SSH access from the master's IP address to each node in the cluster.</p></li>
</ul>

<p>If any of the above  <code>kubectl</code>  commands don't run, it's likely that the master is unable to open SSH tunnels with the nodes. Check for these potential causes:</p>

<ol>
<li><strong>The cluster doesn't have any nodes:</strong><br>
If you've scaled down the number of nodes in your cluster to zero, SSH tunnels won't work.    </li>
</ol>

<p>To fix it,  <a href="https://cloud.google.com/kubernetes-engine/docs/how-to/resizing-a-container-cluster" rel="nofollow noreferrer">resize your cluster</a>  to have at least one node.</p>

<ol start="2">
<li><strong>Pods in the cluster have gotten stuck in a terminating state</strong> and have prevented nodes that no longer exist from being removed from the cluster:<br>
This is an issue that should only affect Kubernetes version 1.1, but could be caused by repeated resizing of the cluster.</li>
</ol>

<p>To fix it,  <a href="https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#delete/" rel="nofollow noreferrer">delete the Pods</a>  that have been in a terminating state for more than a few minutes. The old nodes are then removed from the master's API and replaced by the new nodes.</p>

<ol start="3">
<li><p>Your network's firewall rules don't allow for SSH access to the master.</p>

<p>All Compute Engine networks are created with a firewall rule called "default-allow-ssh" that allows SSH access from all IP addresses (requiring a valid private key, of course). GKE also inserts an SSH rule for each cluster of the form  <code>gke-cluster-name-random-characters-ssh</code>  that allows SSH access specifically from the cluster's master IP to the cluster's nodes. If neither of these rules exists, then the master will be unable to open SSH tunnels.</p></li>
</ol>

<p>To fix it,  <a href="https://cloud.google.com/compute/docs/vpc/using-firewalls" rel="nofollow noreferrer">re-add a firewall rule</a>  allowing access to VMs with the tag that's on all the cluster's nodes from the master's IP address.</p>

<ol start="4">
<li><p>Your project's common metadata entry for "ssh-keys" is full.</p>

<p>If the project's metadata entry named "ssh-keys" is close to the 32KiB size limit, then GKE isn't able to add its own SSH key to enable it to open SSH tunnels. You can see your project's metadata by running the following command:</p>

<pre><code>gcloud compute project-info describe [--project=PROJECT]
</code></pre>

<p>And then check the length of the list of ssh-keys.</p></li>
</ol>

<p>To fix it,  <a href="https://cloud.google.com/compute/docs/instances/adding-removing-ssh-keys#project-wide" rel="nofollow noreferrer">delete some of the SSH keys</a>  that are no longer needed.</p>

<ol start="5">
<li><p>You have set a metadata field with the key "ssh-keys" on the VMs in the cluster.</p>

<p>The node agent on VMs prefers per-instance ssh-keys to project-wide SSH keys, so if you've set any SSH keys specifically on the cluster's nodes, then the master's SSH key in the project metadata won't be respected by the nodes. To check, run  <code>gcloud compute instances describe &lt;VM-name&gt;</code>  and look for an "ssh-keys" field in the metadata.</p></li>
</ol>

<p>To fix it,  <a href="https://cloud.google.com/compute/docs/instances/adding-removing-ssh-keys#instance-only" rel="nofollow noreferrer">delete the per-instance SSH keys</a>  from the instance metadata.</p>

<p>You can also find this troubleshooting steps at <a href="https://cloud.google.com/kubernetes-engine/docs/troubleshooting" rel="nofollow noreferrer">GCP Kubernetes Engine Troubleshooting kubectl</a></p>

<hr>

<p><strong>Note:</strong> As a side note I also suggest trying <a href="https://helm.sh/docs/intro/install/" rel="nofollow noreferrer">Helm 3</a>:</p>

<p>It does not need Tiller Installation anymore, has a lot of new features and is supported on GKE.</p>
