The End of SSH on Nutanix Is Coming. Are Your Automations Ready?
A deep look at Nutanix’s upcoming SSH deprecation and what teams must do to secure and modernize their automation workflows.
Nutanix has officially confirmed the upcoming retirement of SSH Bash shell access across AOS, AHV, Prism Central and Files. The announcement bulletin published on October 29, 2025 marks the beginning of the End of Support Life for remote shell access, with removal planned for the upgrade family scheduled for Q2 2026.
This change affects long standing administrative habits. It also forces a shift toward API driven operations and modern automation practices that are easier to support and easier to validate.
Why SSH access is being retired
According to the official bulletin the objective is to improve security, stability and long term supportability. SSH access enabled deep interaction with the CVM operating system and allowed administrators to make adjustments that were not always visible or consistent.
Modern Nutanix environments rely on hardened control planes and API layers that provide the same capabilities in a predictable way. Removing remote shell access aligns the platform with this model.
Understanding the EOSL timeline
Two milestones are defined in the announcement.
Source: Nutanix SSH Bash Shell EOSL Bulletin
| Milestone | Description | Date |
|---|---|---|
| EOSL Announcement | Public notification of the SSH Bash retirement | October 29, 2025 |
| SSH Deprecation | Removal of SSH access in the next major upgrade family | Q2 2026 |
From that release onward CVMs will not support remote Bash shell access. Any operational workflow or automation pipeline that depends on it will need to be reworked.
How existing workflows are affected
SSH has been used for years as the quickest path to internal tools on the CVM. Typical use cases included log collection, network checks inside the CVM environment, one off provisioning scripts or recurring administrative routines.
With the SSH retirement these operations will no longer be accessible through remote shell sessions. Nutanix recommends reviewing all scripts and manual procedures that rely on this model and transitioning them to supported interfaces.
Preparing for the transition
A structured preparation prevents operational gaps during upgrades.
1. Build an inventory of SSH dependent workflows
SSH is often embedded in scheduled tasks, CI or CD pipelines, Ansible playbooks or local scripts. A complete inventory helps identify what must be replaced.
2. Map existing logic to APIs
Most operational and lifecycle tasks already exist in the v3 and v4 API layers. VM operations, image management, network configuration, metrics and alerts all have documented endpoints. Internal CVM adjustments need to be redesigned because they will no longer be accessible.
3. Centralise automation with reusable modules
Python, Go and PowerShell SDKs provide consistent ways to consume Nutanix APIs. This reduces the amount of custom shell logic that would otherwise be difficult to maintain.
4. Remove assumptions tied to the CVM environment
Shell scripts often rely on implicit state or file paths. API driven automation forces explicit parameters and reduces hidden dependencies.
What changes in day to day operations
Prism remains the central interface for administration. Most daily tasks do not require shell access and will continue unchanged. The difference is that cluster configuration, VM operations, networking and diagnostics will rely on Prism workflows, API endpoints, Terraform modules or Calm automation rather than internal CVM utilities.
Practical alternatives to SSH in Nutanix environments
Prism Central as the operational hub
Administrative workflows that historically required internal tools are now available through Prism, including metrics, insights and NCC based validation.
Nutanix APIs for programmatic operations
The v3 and v4 API layers expose VM lifecycle management, networking, images, categories, cluster configuration and logging. API driven automation provides consistency across environments.
Calm for orchestrated workflows
Calm blueprints provide a way to build repeatable operational playbooks. They offer versioning, governance and visibility that shell scripts cannot provide.
Terraform and Ansible integrations
Both tools integrate natively with Nutanix. They provide infrastructure as code workflows and replace custom provisioning scripts.
Python and Go SDKs
These SDKs are ideal for small tools such as log collectors, provisioning utilities and scheduled health scans. They replace local scripts without depending on CLI utilities inside the CVM.
NCC and Prism diagnostics
Health checks, cluster validation and log collection are already exposed through Prism and NCC. Many troubleshooting tasks can be executed without accessing the CVM.
What about advanced settings that previously depended on CVM shell access
Some administrative actions traditionally required working inside the CVM environment. These included enabling specific security features, adjusting cluster level parameters or configuring advanced virtualization attributes for nested workloads.
All these actions relied on internal utilities that required remote shell access. With the SSH retirement Nutanix is moving these capabilities into Prism and into the v3 and v4 API layers. Advanced cluster and VM settings are gradually being exposed through supported interfaces.
The goal is to eliminate low level shell workflows and replace them with predictable, auditable and supportable configuration paths. These operations will become available through:
- Prism Central under advanced configuration
- dedicated API based configuration endpoints
- Calm runbooks for multi step workflows
This ensures that advanced configuration becomes part of the official control plane instead of depending on internal tools.
Real world considerations for operations teams
Some teams have accumulated a large amount of shell based tooling over the years. The SSH retirement is an opportunity to replace this technical debt with structured automation. It also improves observability and security because API driven workflows make changes traceable and repeatable.
In hybrid and multicloud environments this results in more predictable behaviour and better alignment with modern operational models.
Conclusion
The retirement of SSH access is a significant step in the evolution of the Nutanix platform. It removes a powerful but fragile operational path and replaces it with structured, supportable interfaces.
The migration requires planning but the long term benefit is a more consistent, secure and cloud aligned operational model. Teams that embrace API driven workflows will gain reliability and governance that shell based operations could not provide.