You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: allow using existing SSH key instead of creating a new one
Add existing_ssh_key_name config option to networking.ssh that lets
users specify the name of an existing SSH key in the Hetzner project.
When set, the key is validated (exists in Hetzner, fingerprint matches
local public key) and used instead of creating a new one. The key is
also not deleted on cluster deletion. Bump version to 2.5.0.
Copy file name to clipboardExpand all lines: docs/Creating_a_cluster.md
+2-1Lines changed: 2 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -22,6 +22,7 @@ networking:
22
22
use_private_ip: false # set to true to connect to nodes via their private IPs
23
23
public_key_path: "~/.ssh/id_ed25519.pub"
24
24
private_key_path: "~/.ssh/id_ed25519"
25
+
# existing_ssh_key_name: "my-existing-key" # optional: use an existing SSH key in Hetzner instead of creating a new one
25
26
allowed_networks:
26
27
ssh:
27
28
- 0.0.0.0/0
@@ -369,7 +370,7 @@ The `create` command can be run multiple times with the same configuration witho
369
370
- The `networking`.`allowed_networks`.`api` setting specifies which networks can access the Kubernetes API. This works with both single-master and multi-master clusters, but only when `create_load_balancer_for_the_kubernetes_api` is disabled. If the API load balancer is enabled, Hetzner's firewalls do not yet support load balancers, so the API would be exposed to the public internet regardless of the allowed networks configuration.
370
371
- If you enable autoscaling for a nodepool, avoid changing this setting later, as it can cause issues with the autoscaler.
371
372
- Autoscaling is only supported with Ubuntu or other default images, not snapshots.
372
-
- If you already have SSH keys in your Hetzner project, it's best to use a different key for your cluster—unless there's already a key with the same name and fingerprint as the one in your config file. Hetzner doesn't allow two keys with the same fingerprint in one project. So if you've already added the key from your config but under a different name, Hetzner won't let you add it again. In that case, hetzner-k3s will skip creating the key and won't inject any SSH key into the cluster nodes. Without an SSH key, Hetzner sets up the nodes with password login instead. That means you'll get an email for each node with its root password. Managing several nodes this way can get tricky. To avoid this, just use a new keypair for your cluster—unless the project already has a key that matches both the name and fingerprint in your config.
373
+
- If you already have SSH keys in your Hetzner project, it's best to use a different key for your cluster—unless there's already a key with the same name and fingerprint as the one in your config file. Hetzner doesn't allow two keys with the same fingerprint in one project. So if you've already added the key from your config but under a different name, Hetzner won't let you add it again. In that case, hetzner-k3s will skip creating the key and won't inject any SSH key into the cluster nodes. Without an SSH key, Hetzner sets up the nodes with password login instead. That means you'll get an email for each node with its root password. Managing several nodes this way can get tricky. To avoid this, you can either use a new keypair for your cluster, or set `existing_ssh_key_name` in the SSH config to reference the existing key by name. When using `existing_ssh_key_name`, hetzner-k3s will use the specified key instead of creating a new one, and it won't delete the key when you delete the cluster.
373
374
- SSH keys with passphrases can only be used if you set `networking`.`ssh`.`use_ssh_agent` to `true` and use an SSH agent to access your key. For example, on macOS, you can start an agent like this:
errors <<"Cluster autoscaler requires an SSH key named '#{settings.cluster_name}' in Hetzner. A key with the same fingerprint exists as '#{existing_ssh_key.name}', so hetzner-k3s will not create '#{settings.cluster_name}'. Autoscaled nodes will be created without SSH keys. Rename or delete the existing key, or change cluster_name."
28
+
errors <<"Cluster autoscaler requires an SSH key named '#{ssh_key_name}' in Hetzner. A key with the same fingerprint exists as '#{existing_ssh_key.name}', so hetzner-k3s will not create '#{ssh_key_name}'. Autoscaled nodes will be created without SSH keys. Rename or delete the existing key, or use the existing_ssh_key_name setting to reference it."
errors <<"SSH key mismatch: the key '#{ssh.existing_ssh_key_name}' was not found by name in Hetzner. A key with the same fingerprint exists as '#{existing_ssh_key.name}', but existing_ssh_key_name must match the key name exactly."
if existing_ssh_key.fingerprint != config_fingerprint
70
+
errors <<"SSH key fingerprint mismatch: the existing key '#{ssh.existing_ssh_key_name}' in Hetzner has a different fingerprint than the local public key at '#{ssh.public_key_path}'. Please ensure the public_key_path points to the corresponding public key."
0 commit comments