You see the following alarm from DSM
In /var/log/tdm/provider/containers/dsm-tsql-provisioner-service.log You see an alarm similar to the following.
{"level":"error","timestamp":"2026-02-18T14:35:31.910Z","C":"vcenterbinding/vcenterbinding_controller.go:229","message":"registerVCPluginIfNotRegistered","controller":"vcenterbinding","controllerGroup":"system.dataservices.vmware.com","controllerKind":"VCenterBinding","VCenterBinding":{"name":"vcenter"},"namespace":"","name":"vcenter","reconcileID":"8ba3c9c9-50ee-493d-8c08-############","objName":"vcenter","objType":"############.VCenterBinding","Status":"error checking plugin registration: error fetching plugin server host: failed to connect to SSH server: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain","error":"error checking plugin registration: error fetching plugin server host: failed to connect to SSH server: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain","S":
DSM 2.2
SSH keys have been removed form the ~root/.ssh/authorized_keys Breaking the DSMs workflow. This can happen with various activity's such as a adding/replacing a custom SSH key for root access.
Cat the the ~root/.ssh/authorized_keys and validate that there is more then just the single custom SSH key.
If the authorized_keys File only has the custom entry then use the following command to append the file with the default SSH configuration.
cat /opt/vmware/tdm-provider/cert/ssh_key.pub >> ~/.ssh/authorized_keys
This should correct the issue and allow the plugin to register. DSM will start to process any pending tasks after the correcting is made.