Instead of using the ssh command, the cloud provider CLI tool may need to be used, e.g.
$ az ssh vm ...
$ gcloud compute ssh ...
$ doctl compute ssh ...
There is also the possibility that instead of executing a different command, the cloud provider's tool can be used to generate an SSH-compatible config. This would then only require the ability to support options that such files require.
The simplest approach is most likely to be:
- Storing a flag that indicates which type of provider the entry relates to
- When the flag is
ssh proceed with current processing
- When the flag is not
ssh then a full set of arguments are simply stored in a single field in JSON format and then passed directly to the CLI tool
This would then support any cloud provider tool, regardless of whether it supported generation of configs, etc
Instead of using the
sshcommand, the cloud provider CLI tool may need to be used, e.g.There is also the possibility that instead of executing a different command, the cloud provider's tool can be used to generate an SSH-compatible config. This would then only require the ability to support options that such files require.
The simplest approach is most likely to be:
sshproceed with current processingsshthen a full set of arguments are simply stored in a single field in JSON format and then passed directly to the CLI toolThis would then support any cloud provider tool, regardless of whether it supported generation of configs, etc