This mini-guide is in response to https://feedback.equinixmetal.com/instances/p/support-ssh-for-windows
The idea is based on my understanding of the Equinix Metal platform, backed by supporting documentation. The PowerShell script and guided steps in windows-ssh-keys.md
were initially ChatGPT 3.5 generated using this understanding as the prompt. This should be considered a starting point. I've not run this, but it does look to line up with my understanding.
OpenSSH Server support is now available in Windows:
- https://learn.microsoft.com/en-us/windows/terminal/tutorials/ssh
- https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_keymanagement?source=recommendations#deploying-the-public-key
Powershell scripts can be provided as Equinix Metal userdata when provisioning: https://deploy.equinix.com/developers/docs/metal/operating-systems/licensed/#using-user-data-with-windows.
It is possible to create a startup script that fetches the SSH Keys assigned to the instance from the available project collaborator and project SSH keys (https://deploy.equinix.com/developers/docs/metal/accounts/ssh-keys/). These keys are stored as metadata: https://deploy.equinix.com/developers/docs/metal/server-metadata/metadata/.
Assuming the instance has Layer3 connectivity enabled (default), the following PowerShell userdata script could fetch and authorize the Equinix Metal configured SSH Keys.
This script is an example only and may need to be modified to place the keys in a specific user's SSH directory.
Next steps would be to use the PowerShell userdata to enable SSH by default (potentially installing OpenSSH first for older Windows versions) and ensure that the instance userdata is executed on each boot, or periodically. Doing so would ensure the SSH keys are refreshed to eventually match what is configure in the Equinix Metal console and API.
- Equinix Metal SSH Keys may already be preconfigured for Windows (or may be in the future)
- Cloud-Init executions of Powershell userdata may run with additional gotchas
- which user is it run as
- at what stage of provisioning
- is it executed on subsequent boots