As SSH is the most widely used way to access remote machines, CloudStack provides users with the ability to specify an SSH Key to be added to the list of authorized keys of a virtual machine either during or post-deployment. Users can either generate these SSH Keys via the CloudStack UI or register existing public keys. While passing SSH Keys to virtual machines is an essential feature, currently, users are limited to providing only a single SSH Key to access a virtual machine.
Due to this limitation, anyone who requires SSH access to the VM must have access to the same, single private key. This can be inconvenient at times as well as pose potential security issues. For example – there could be a group of people working on a single project who require access to the VM. In such a scenario, with the current limitation of providing only a single SSH key, every team member must possess the public key, creating an obvious security issue. Additionally, if there is any update or change to the key, everyone in the team must be aware of it and acquire the new key.
As of CloudStack 4.17 LTS, virtual machines will support multiple SSH Keys, meaning CloudStack will be able to configure more than one SSH key to provide access to VMs. This benefits users by allowing them to add their own personal public SSH key to CloudStack and subsequently to the list of authorized keys of a VM. It also frees them of the inconvenient and insecure process of changing and managing the shared key when there is an update. Additionally, it avoids the hassle of managing multiple shared keys for different VMs, across projects and domains.
It could also simplify monitoring as well as automation from a central server to the VMs in the infrastructure. The server’s keys can be added to the list of authorized keys while deploying the virtual machine itself, eliminating the need for additional steps to configure a specific key per VM or group of VMs on the centralized server.
Support for Multiple SSH Keys is introduced in the CloudStack 4.17 LTS release and can be specified either while creating the VM (via the `deployVirtualMachine` API) or can be reset via the ‘resetSSHKeyForVirtualMachine’ API.