SSM vs SSH: 2026 Default for Server Access

SSH still works but is harder to audit. SSM Session Manager replaces SSH for most use cases.

Why SSM wins

The choice between AWS Systems Manager (SSM) Session Manager and traditional SSH is one of the highest-leverage security improvements available for AWS environments. Both provide remote access to EC2 instances; SSM provides it without the network exposure, key management, and audit gaps that SSH brings. For AWS workloads, SSM is almost always the right choice.

What SSM provides:

• No exposed SSH ports.: SSM does not require port 22 to be open. Instances can have no inbound network access whatsoever; SSM still works because the SSM agent makes outbound connections to AWS. The attack surface from network exposure is eliminated.
• No bastions.: Traditional SSH requires bastion hosts to broker access from the operator's network to the private fleet. Bastions add complexity, cost, and another attack surface. SSM eliminates the need for bastions entirely.
• No SSH key management.: SSH keys must be distributed, rotated, and revoked. The key management is operationally significant; mistakes in key management produce incidents. SSM uses IAM authentication; the key management is replaced by IAM policy.
• Per-session audit log.: Every SSM session is logged. The audit captures who connected, when, to which instance, what duration. CloudTrail records the events; the audit trail is comprehensive.
• Recording optional.: Sessions can be recorded to S3 or CloudWatch Logs. The recording captures every command and every output. The recording is optional but available for high-stakes systems.

SSM's value comes from what it eliminates: open ports, bastions, key management, audit gaps. The simplicity is a security improvement.

Where SSH still wins

SSM is AWS-specific. For workloads that span clouds or run outside cloud providers, SSH is the only option. Some specific tooling also requires SSH; the migration plan accommodates these cases.

• Workloads outside AWS.: On-premises servers, edge devices, instances in other clouds need SSH (or equivalent). SSM is AWS-specific; it does not extend to non-AWS infrastructure.
• Hybrid environments.: Hybrid environments often have AWS workloads using SSM and on-prem workloads using SSH. The team operates both; the discipline is to use SSM where possible and SSH where required.
• SSH is portable.: SSH works across operating systems, clouds, and physical hardware. The portability is its enduring strength; standardizing on SSH means one tool covers everything.
• SSM is AWS-specific.: The trade-off for SSM's value is its AWS lock-in. Teams considering multi-cloud or eventual cloud migration should weigh this against the security benefits.
• Specific tooling that requires SSH.: Some operational tooling (Ansible, Capistrano, certain orchestration tools) requires SSH connectivity. The tools' compatibility with SSM is variable; legacy tooling sometimes requires SSH for the foreseeable future.

SSH is not obsolete. For AWS-only workloads with modern tooling, SSM is preferred; for everything else, SSH remains the lingua franca.

Migration

Migrating from SSH to SSM is mostly mechanical. The SSM agent runs on each instance; the IAM permissions allow connections; SSH is disabled. The discipline is doing this systematically across the fleet without breaking operations.

• Install SSM agent on existing fleet.: The SSM agent must be running on each instance for SSM to connect. Most modern AMIs (Amazon Linux, recent Ubuntu, Windows Server) include the agent by default. Older AMIs need explicit installation.
• Most AMIs have it.: The agent is widespread enough that the migration usually does not require AMI rebuilds. Existing instances typically have the agent; verifying its presence is the first step.
• Disable SSH access on a sample.: A subset of instances is migrated first. SSH access is removed; SSM access is verified. Operational paths that previously used SSH are tested with SSM; gaps surface for resolution.
• Verify SSM works.: The team confirms SSM provides the operational paths the team needs: interactive shell, file transfer (via SSM Session Manager port forwarding), command execution. Each path has SSM equivalents; the verification confirms they work for the team's specific use cases.
• Expand.: Once the sample succeeds, the migration expands. Subsequent waves of instances are migrated; SSH is disabled fleet-wide. The expansion is methodical; each wave is verified before the next.

SSM vs SSH decision is one of the persistently rewarded AWS security improvements. Nova AI Ops integrates with SSM and CloudTrail data, surfaces remaining SSH access, and produces the migration-tracking report that drives the team toward SSM-only access.