What are SSH keys?
As an alternative to password-based login, SSH allows authentication using what are called SSH keys (more precisely: SSH key pairs).
The advantage of using SSH keys is that they allow server connection without user interaction, such as entering a password, and thus the possibility of performing automated actions.
Moreover, key data is generated randomly and is therefore much harder for attackers to guess than a simple password. For this, a public key is created to be stored on your vServer. Additionally, a private key is kept securely on your own PC.
To use SSH keys, you need:
- an SSH client software
On Linux, macOS, and Windows with Babun, the SSH client is directly installed in the system and can be used from the terminal.
To create a new SSH key pair, enter the following command in your terminal and confirm with “Enter”:
openssh-keygen -t rsa
Additional information will then be requested, which you will need to enter. In parentheses, you will see the suggested value that you can accept by pressing “Enter”. For example, it is suggested to store the generated key data in your user directory under $HOME/.ssh/. From there, the key data will also be automatically loaded later.
Important: If you wish, you can set a password to access your private key at this stage. This is recommended if you do not want others to access your SSH.
On Windows with PuTTY, you will need to use the “puttygen” program provided with PuTTY to generate your keys. You can find a guide for example here.
After generating your SSH key pair, you can deposit the public key on your vServer. This can be done, for example, during the system reinstallation directly via our interface or after first connecting to the server via SSH with a password.
In the latter case, proceed as follows after connecting to the server:
- Ensure that the directory “$HOME/.ssh” exists
mkdir $HOME/.ssh - Create the file “$HOME/.ssh/authorized_keys” and paste your public key (starting with ssh-rsa) via ctrl+c/ctrl+v. Alternatively, you can also use the “ssh-copy-id” tool on Linux and macOS.
nano $HOME/.ssh/authorized_keys - Save the changes in the file (ctrl+o) and close it (ctrl+x)
On your next connection, your SSH key will now be used.
Planning SSH key usage for different devices and team members
Once your first SSH key is working, it is worth thinking about how you want to structure key usage in the long term. A good rule of thumb is to generate a separate key pair for each device (e.g., laptop, workstation, jump host) rather than reusing the same private key across devices. This way, if one device is lost or compromised, you only need to revoke that specific key instead of reconfiguring everything. In team environments, avoid sharing a single key between multiple people. Instead, assign one public key per user and device combination, and document which key belongs to whom. This provides a clear audit trail and lets you remove access for individual users without affecting others.
Best practices for storing, backing up, and revoking SSH keys
To keep your SSH-based access secure and manageable, it helps to follow a few concrete practices:
- Protect private keys on disk: Store private keys only in your user profile on trusted machines (for example, ~/.ssh/), and restrict file permissions so that no other local users can read them. On most systems, that means chmod 600 for the key file.
- Avoid copying private keys between devices: Generate a separate key pair per device instead of reusing the same private key everywhere. This reduces the damage if one machine is lost or compromised.
- Create secure backups of important keys: Keep an encrypted backup of essential private keys, such as on an encrypted external drive or in a password manager that supports file storage. This prevents lockouts if your primary device fails.
- Maintain an inventory of keys and their usage: Document which public key is used on which server and which user it belongs to. A simple list or table is enough to keep track of who has access where.
- Revoke keys quickly when necessary: If a device is stolen, an employee leaves, or a key is suspected to be compromised, remove the corresponding public key from authorized_keys on all affected servers immediately and, if needed, generate a new key pair.
Using SSH keys for automation and deployment workflows
SSH keys are not only valid for interactive logins but also a foundation for reliable automation. For example, deployment tools, configuration management systems, or backup scripts can use dedicated key pairs to access your cloud servers without requiring manual password entry. In these cases, it is best to generate keys specifically for automation tasks, separate from personal user keys, and to restrict the associated accounts to exactly the commands or directories they need. You can also combine key-based logins with options in the authorized_keys file to limit what a particular key can do, such as enforcing a specific command or disabling port forwarding. This separation of roles makes it easier to audit automated access and to rotate credentials when infrastructure changes.
Diagnosing common SSH key connection errors
If an SSH key suddenly stops working, or you receive a “Permission denied (publickey)” message, a few systematic checks can help locate the problem. Start by confirming that you are connecting as the correct user and to the proper server IP or hostname; a valid key for one user account will not work for another. On your local system, verify that you are using the expected private key file and that its permissions are restrictive enough for the SSH client to accept it. On the server side, ensure that your public key is still present in the appropriate account’s configuration and has not been accidentally removed during maintenance or reinstallation. Finally, check any recent changes to firewalls, SSH configuration, or login restrictions that might block key-based authentication. A structured review of these points usually reveals the root cause quickly.