Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

📖 Update managing-ssh-keys.md #1147

Merged
merged 1 commit into from
Feb 8, 2024
Merged

📖 Update managing-ssh-keys.md #1147

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
8 changes: 4 additions & 4 deletions docs/topics/managing-ssh-keys.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,13 +1,13 @@
## Managing SSH keys

### In Hetzner Cloud
In pure HCloud clusters, without bare metal servers, there is no need for SSH keys. All keys that exist in HCloud API and are specified in ```HetznerCluster``` properties, are included when provisioning machines. Therefore, they can be used to access those machines via SSH. Note that you have to upload those keys via Hetzner UI or API beforehand.
In pure HCloud clusters, without bare metal servers, there is no need for SSH keys. All keys that exist in HCloud API and are specified in ```HetznerCluster``` properties are included when provisioning machines. Therefore, they can be used to access those machines via SSH. Note that you have to upload those keys via Hetzner UI or API beforehand.

The SSH keys can be either specified cluster-wide in the specs of the ```HetznerCluster``` object, or scoped to one machine in the specs of ```HCloudMachine```.
The SSH keys can be either specified cluster-wide in the specs of the ```HetznerCluster``` object or scoped to one machine in the specs of ```HCloudMachine```.

If one SSH key is changed in the specs of the cluster, then keep in mind that the SSH key is still valid to access all servers that have been created with it. If it is a potential security vulnerability, then all of these servers should be removed and re-created with the new SSH keys.

### In Hetzner Robot
For bare metal servers, two SSH keys are required. One that is used for the rescue system, one for the actual system. The two can, under the hood, of course, be the same. These SSH keys do not have to be uploaded into Robot API, but have to be stored in two secrets (again, the same secret is also possible if the same reference is given twice). Not only the name of the SSH key, but also public and private key. The private key is necessary for provisioning the server with SSH. The SSH key for the actual system is specified in ```HetznerBareMetalMachineTemplate``` - there are no cluster-wide alternatives. The SSH key for the rescue system is defined in a cluster-wide manner in the specs of ```HetznerCluster```.
For bare metal servers, two SSH keys are required. One of them is used for the rescue system, and the other for the actual system. The two can, under the hood, of course, be the same. These SSH keys do not have to be uploaded into Robot API but have to be stored in two secrets (again, the same secret is also possible if the same reference is given twice). Not only the name of the SSH key but also the public and private key. The private key is necessary for provisioning the server with SSH. The SSH key for the actual system is specified in ```HetznerBareMetalMachineTemplate``` - there are no cluster-wide alternatives. The SSH key for the rescue system is defined in a cluster-wide manner in the specs of ```HetznerCluster```.

The secret reference to a SSH key cannot be changed - the secret data, i.e. the SSH key, can. The host that is consumed by the ```HetznerBareMetalMachine``` object reacts in different ways on a change of the secret data of the secret that is referenced in its specs, depending on its provisioning state. If the host is already provisioned, it will emit an event warning that it is not possible for provisioned hosts to change SSH keys. The corresponding machine object should instead be deleted and recreated. When the host is provisioning, then it restarts this process again if a change of the SSH key makes it necessary. This depends on whether it is the SSH key for the rescue or the actual system and the exact provisioning state.
The secret reference to an SSH key cannot be changed - the secret data, i.e., the SSH key, can. The host that is consumed by the ```HetznerBareMetalMachine``` object reacts in different ways to the change of the secret data of the secret referenced in its specs, depending on its provisioning state. If the host is already provisioned, it will emit an event warning that provisioned hosts can't change SSH keys. The corresponding machine object should instead be deleted and recreated. When the host is provisioning, it restarts this process again if a change of the SSH key makes it necessary. This depends on whether it is the SSH key for the rescue or the actual system and the exact provisioning state.