How to enable SSH on DSM Appliance when deployed via VCFA 9.1.1
In my initial post introducing VMware Data Services Manager (DSM) 9.1.1 features, I mentioned that DSM can now be deployed directly from VCF Automation. As part of a concerted effort to make Data Services (and the VCF platform) highly secure, SSH access is not automatically enabled on the DSM 9.1.1 appliance. In this post, I will show you how to enable it should you need SSH access to the DSM appliance.
The first step is to gain SSH Access to the vCenter server. The steps are outlined in this Knowledge Base article on troubleshooting. Once you’ve managed to get a shell open on your vCenter server, the following commands can be used to retrieve the root password to gain access to the Supervisor.
Command> shell Shell access is granted to root root@sfo-w01-vc01 [ ~ ]# cd /usr/lib/vmware-wcp/ root@sfo-w01-vc01 [ /usr/lib/vmware-wcp ]# ./decryptK8Pwd.py Read key from file Connected to PSQL Cluster: domain-c9:09ddf26c-f7e2-4333-b023-aa4a36024b79 IP: 192.168.1.200 PWD: AbCdEfGhIj ------------------------------------------------------------ root@sfo-w01-vc01 [ /usr/lib/vmware-wcp ]# sshpass -p 'AbCdEfGhIj' ssh -o \ stricthostkeychecking=no root@192.168.1.200 Last login: Fri Sep 18 10:45:31 2026 from 192.168.1.130 =============================================================================== EXERCISE EXTREME CAUTION when accessing a vSphere Supervisor control plane VM. When running commands on a Supervisor control plane VM, you are acting with elevated permissions that BYPASS PROTECTIONS. You may cause DATA LOSS, disrupt running workloads, or PERMANENTLY DAMAGE the Supervisor, Supervisor Services including the vSphere Kubernetes Service (VKS), or VKS Clusters. Graceful recovery from changes made with these elevated permissions may not be possible; it may be necessary to REDEPLOY THE ENTIRE SUPERVISOR, recreate all VKS clusters, and redeploy all workloads. =============================================================================== 08:09:45 up 12 days, 22:03, 0 users, load average: 7.72, 6.12, 5.87 tdnf update info not available yet! root@423789b3f055e8e9961d56e456f323d6 [ ~ ]#
Once successfully logged onto the Supervisor, query the Data Service Manager deployment. In VCFA 9.1.1, the DSM is deploying using the VM Service feature. The follow commands can be used to check the name of the appliance and the opened ports on it. Note that on the Control Plane VM (Supervisor), the kubectl command is aliased to a simple ‘k’.
root@423789b3f055e8e9961d56e456f323d6 [ ~ ]# k get vm -A | grep dsm svc-dsm-provider-operator-r77bq dsm-appliance PoweredOn 10d root@423789b3f055e8e9961d56e456f323d6 [ ~ ]# k get vmservice -n svc-dsm-provider-operator-r77bq NAME TYPE AGE dsm-appliance-internal ClusterIP 10d dsm-appliance-lb LoadBalancer 10d root@423789b3f055e8e9961d56e456f323d6 [ ~ ]# k get vmservice -n svc-dsm-provider-operator-r77bq \ dsm-appliance-lb -o yaml apiVersion: vmoperator.vmware.com/v1alpha5 kind: VirtualMachineService metadata: creationTimestamp: "2026-09-10T13:25:35Z" finalizers: - vmoperator.vmware.com/virtualmachineservice generation: 1 name: dsm-appliance-lb namespace: svc-dsm-provider-operator-r77bq ownerReferences: - apiVersion: provider.dataservices.vmware.com/v1alpha1 blockOwnerDeletion: true controller: true kind: DSMAppliance name: dsm-appliance uid: 14347c54-628d-4a35-ad8d-802d02ea23bc resourceVersion: "2065849" uid: a25607df-b720-4e58-bb86-cee6525ea006 spec: ports: - name: https port: 443 protocol: TCP targetPort: 443 selector: dsm.vmware.com/appliance-name: dsm-appliance type: LoadBalancer status: loadBalancer: ingress: - ip: 192.168.41.72
By default, the DSM appliance is only servicing the https port, 443. This allows administrator to connect to the DSM UI via a browser using the loadBalancer IP address, but no other ports are accessible via that address. To allow SSH access (port 22), create a new YAML manifest similar to the above for an additional VM Service on the DSM Appliance. A sample manifest will look something similar to the following:
apiVersion: vmoperator.vmware.com/v1alpha5 kind: VirtualMachineService metadata: name: dsm-appliance-lb-additional namespace: svc-dsm-provider-operator-r77bq spec: ports: - name: ssh port: 22 protocol: TCP targetPort: 22 selector: dsm.vmware.com/appliance-name: dsm-appliance type: LoadBalancer
Apply the manifest. This creates a new VM Service. Note that the SSH port 22 is opened on a different IP address compared to the IP address associated with the https port above. However both redirect to the same DSM appliance:
root@423789b3f055e8e9961d56e456f323d6 [ ~ ]# k apply -f dsm-ssh.yaml virtualmachineservice.vmoperator.vmware.com/dsm-appliance-lb-additional created root@423789b3f055e8e9961d56e456f323d6 [ ~ ]# k get vmservice -n svc-dsm-provider-operator-r77bq NAME TYPE AGE dsm-appliance-internal ClusterIP 10d dsm-appliance-lb LoadBalancer 10d dsm-appliance-lb-additional LoadBalancer 14s root@423789b3f055e8e9961d56e456f323d6 [ ~ ]# k get vmservice -n svc-dsm-provider-operator-r77bq dsm-appliance-lb-additional -o yaml apiVersion: vmoperator.vmware.com/v1alpha5 kind: VirtualMachineService metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"vmoperator.vmware.com/v1alpha5","kind":"VirtualMachineService","metadata":{"annotations":{},"name":"dsm-appliance-lb-additional","namespace":"svc-dsm-provider-operator-r77bq"},"spec":{"ports":[{"name":"ssh","port":22,"protocol":"TCP","targetPort":22}],"selector":{"dsm.vmware.com/appliance-name":"dsm-appliance"},"type":"LoadBalancer"}} creationTimestamp: "2026-09-21T08:27:34Z" finalizers: - vmoperator.vmware.com/virtualmachineservice generation: 1 name: dsm-appliance-lb-additional namespace: svc-dsm-provider-operator-r77bq resourceVersion: "16164207" uid: ae4a417c-bedc-4d08-bd6b-b11264b47751 spec: ports: - name: ssh port: 22 protocol: TCP targetPort: 22 selector: dsm.vmware.com/appliance-name: dsm-appliance type: LoadBalancer status: loadBalancer: ingress: - ip: 192.168.41.73
At this point, SSH is opened to the DSM appliance via a new loadBalancer IP address. This means that we should be able to SSH to it. However, in order to be able to login as the root user, the root password must also be retrieved. This is help in a secret called dsm-appliance-root-cred in the same namespace. Here is just one example of how to retrieve it.
root@423789b3f055e8e9961d56e456f323d6 [ ~ ]# k get secrets -n svc-dsm-provider-operator-r77bq NAME TYPE DATA AGE dsm-appliance-root-cred Opaque 1 10d dsm-po-values Opaque 1 10d dsm-provider-operator-pull-regcred kubernetes.io/dockerconfigjson 1 10d root@423789b3f055e8e9961d56e456f323d6 [ ~ ]# k get secrets -n svc-dsm-provider-operator-r77bq \ dsm-appliance-root-cred --template='{{.data.root_password}}' | base64 -d; echo 9L0b^9Lu%V@8mXl root@423789b3f055e8e9961d56e456f323d6 [ ~ ]#
Now we have SSH opened, we have the IP address to reach the DSM appliance and we have the root password. Let’s see if we can successfully access it.
root@423789b3f055e8e9961d56e456f323d6 [ ~ ]# ssh root@192.168.41.73 Welcome to Photon 5.0 (\m) - Kernel \r (\l) (root@192.168.41.73) Password: 9L0b^9Lu%V@8mXl root@photon-6ca473c9efbb [ ~ ]# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES dc797efaaa57 dsm-tsql-provisioner:9.1.1.0.25641961 "/provisioner --conf…" 5 days ago Up 5 days dsm-tsql-provisioner-service 77121de7aacd vc-session-manager:9.1.1.0.25641961 "/vc-session-manager…" 10 days ago Up 10 days vc-session-manager-service e155538f05d9 telegraf:v1.38.4_vmware.1 "/bin/sh -c 'telegra…" 10 days ago Up 10 days dsm-telegraf-service c50cdede22b4 provider-update-service:9.1.1.0.25641960 "/bin/sh -c '/usr/ja…" 10 days ago Up 10 days provider-update-service 8ecc8312b858 provider-monitoring-service:9.1.1.0.25641960 "/bin/sh -c '/usr/ja…" 10 days ago Up 10 days monitoring-service 2ddc5884de06 registry:3 "/entrypoint.sh /etc…" 10 days ago Up 10 days docker-registry 1297b75df54e simplified-gateway:9.1.1.0.25641961 "/gateway --v=5 --ds…" 10 days ago Up 10 days 127.0.0.1:5443->6443/tcp sgw-service 554efa07f087 dsm/cluster-api-controller:1.13.2_vmware.2 "/manager --leader-e…" 10 days ago Up 10 days kubernetes-service-capi-1 aee34cb51ecf dsm/kubeadm-bootstrap-controller:1.13.2_vmware.2 "/manager --leader-e…" 10 days ago Up 10 days kubernetes-service-kadm-1 234b8a29a113 dsm/cluster-api-ipam-provider-in-cluster:1.1.0 "/manager --leader-e…" 10 days ago Up 10 days kubernetes-service-caip-1 3d0d49c989fe dsm/kubeadm-control-plane-controller:1.13.2_vmware.2 "/manager --leader-e…" 10 days ago Up 10 days kubernetes-service-kcp-1 1718cea3e5e0 dsm/cluster-api-vsphere-controller:1.16.1_vmware.2 "/manager --leader-e…" 10 days ago Up 10 days kubernetes-service-capv-1 cf767b7526af kubernetes-service:9.1.1.0.25641963 "/opt/moneta/kuberne…" 10 days ago Up 10 days 0.0.0.0:6443->6443/tcp kubernetes-service a2b5b3972550 provider-service:9.1.1.0.25641960 "/usr/bin/bash -c 'v…" 10 days ago Up 10 days provider-service 3f4d4399ee9d bitnami-influxdb:1.12.4-photon-5 "/bin/sh -c 'influxd…" 10 days ago Up 10 days influxdb-service 85df57a66487 provider-ui:9.1.1.0.25641967 "/bin/sh -c '/usr/sb…" 10 days ago Up 10 days 0.0.0.0:443->8443/tcp provider-ui root@photon-6ca473c9efbb [ ~ ]# kg get postgresclusters -A NAMESPACE NAME STATUS STORAGE VERSION AGE 7b6916-tenant-03-ns-g8krt tenant-03-pg-db-01 Ready 20Gi 18.4+vmware.v9.1.1.0 10d
Everything looks to be working as expected. Remember that once you are finished with your troubleshooting on the DSM appliance, remove the VM Service that was created earlier. This will ensure that SSH access to the DSM appliance is once again removed. Retain the YAML manifest though, as you can re-apply it when you need to open SSH access once again.
