Mastering Secure SSH Access to AWS Instances Using Modern Authentication Methods

Static SSH key management scales poorly. In AWS environments with ephemeral EC2 instances, auditing and rotating long-lived keys introduces unnecessary operational and security risk. More critically: AWS has evolved—if you still distribute keys by hand, you’re leaving attack surfaces wide open.

Below: three real-world workflows for robust, scalable SSH access—no static keys required. IAM integration, SSM tunneling, and instance-level ephemeral public keys form the toolkit.

Stop Distributing Static SSH Keys

The operational nightmare looks like this: dozens of team members, personal laptops with outdated private keys, and ad-hoc scripts patching authorized_keys across a cluster fleet. Users move teams or leave, keys remain—even after you think you’ve revoked them.

Common pain points:

• Key proliferation: No central oversight, hard to track.
• Ghost access: Departed users remain on instances.
• Revocation lag: Delayed response to compromised or lost keys.

Root question: Why not bind access to your existing AWS identity ecosystem, and automate key expiry?

EC2 Instance Connect: Ephemeral SSH with IAM Control

For most cases running Amazon Linux 2 or Ubuntu on EC2, EC2 Instance Connect brings IAM-backed, short-lived public key authorization. No need to bake keys into AMIs or manage authorized_keys separately.

What Actually Happens

1. User authenticates to AWS (typically via SSO, MFA enforced).
2. Instance Connect API temporarily injects a user’s SSH public key into the instance’s authorized_keys.
3. OS user logs in… within seconds, the ephemeral key expires—no lingering access.

Infrastructure Requirements

• Supported OS: Amazon Linux 2 (2.0.20190618+) or Ubuntu 20.04+.
• On instance: ec2-instance-connect package.
• Outbound connectivity: instance must reach EC2 API endpoints.
• IAM policy permission: ec2-instance-connect:SendSSHPublicKey.

Verification

On the target instance:

rpm -q ec2-instance-connect     # Amazon Linux 2
dpkg -l | grep ec2-instance-connect  # Ubuntu/Debian

Note: If ec2-instance-connect isn't installed, recent AMIs are usually compliant, but custom builds often aren’t. For Amazon Linux 2:

sudo yum install -y ec2-instance-connect
sudo systemctl enable --now ec2-instance-connect.service

Example: Grant Least-Privilege IAM Policy

Attach to AWS users or federated roles:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2-instance-connect:SendSSHPublicKey",
      "Resource": "arn:aws:ec2:us-east-1:123456789012:instance/i-0123456789abcdef0"
    }
  ]
}

Typical Connection Flow

Suppose you’re targeting i-0123456789abcdef0 in us-east-1a as ec2-user:

aws ec2-instance-connect send-ssh-public-key \
  --instance-id i-0123456789abcdef0 \
  --availability-zone us-east-1a \
  --instance-os-user ec2-user \
  --ssh-public-key file://~/.ssh/id_ed25519.pub

Then:

ssh -i ~/.ssh/id_ed25519 ec2-user@<instance-ip>

Gotcha: If you get EC2InstanceLimitExceeded or “public key is not valid,” check instance metadata role, CIDR egress, and file permission on ~/.ssh/.

AWS CLI Shortcut (Requires v2.9.0+)

Direct SSH (with automatic ephemeral key injection):

aws ssh --region us-east-1 ec2-user@i-0123456789abcdef0

aws ssh is still in preview as of Q2 2024. Expect minor syntax or behavior changes.

Systems Manager Session Manager: Portless Shell Access

When zero open inbound ports are required—Session Manager (SSM) is default. Unlike Instance Connect, you don’t need even port 22 available.

Practical Scenario

Compliance mandates: no public IPs, no security group holes, full audit trail via CloudTrail, limited shell access per-operator, restricted sudo.

Minimum Requirements

• EC2 IAM role: AmazonSSMManagedInstanceCore.
• amazon-ssm-agent running (Amazon Linux 2: 2.3.1644.0+; Ubuntu: 3.0.161.0+).
• Outbound HTTPS (443) to SSM endpoints, typically via NAT.

Check agent status:

sudo systemctl status amazon-ssm-agent

Example: Start a Session

aws ssm start-session --target i-0123456789abcdef0

Returns a direct shell.

SSH over SSM (No Open Port 22, but Want Your SSH Tools?)

Tunneling is possible. Edit ~/.ssh/config:

Host i-*
  ProxyCommand sh -c "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"
  User ec2-user

Now this works:

ssh i-0123456789abcdef0

For multiple bastion hops, latency can be higher (first-hop SSM is not low-latency), but the security win is decisive.

IAM Policy Example

For user or assumed roles:

{
  "Effect": "Allow",
  "Action": [
    "ssm:StartSession",
    "ssm:DescribeInstanceInformation"
  ],
  "Resource": "*"
}

Restrict by resource tags or session documents for tighter controls.

Tip: For full session logging, enable S3 or CloudWatch logging via SSM settings—session output and commands will be persisted, aiding forensics.

Advanced: OpenSSH Certificate Authorities (CA) Integrated with IAM

Large organizations with hundreds of EC2 hosts often need centralized, short-lived SSH certificate-based auth tied to corporate SSO.

Example Workflow

1. User authenticates (e.g., SAML/SSO or IAM).
2. IDMS system issues a signed SSH certificate (e.g., ssh-keygen -s ca_key).
3. EC2 base AMI trusts only the org CA in /etc/ssh/sshd_config:

   TrustedUserCAKeys /etc/ssh/ca.pub
   

4. Certificate validity: typically 2–12 hours.
5. Attributes (allowed principals, forced commands, source addresses) embedded per certificate grant granular control.

Practical Note: Standing up a lightweight certificate signing service can be nontrivial. Popular: Netflix’s [BLASTED], Facebook’s [Bastion], Teleport. For organizations not yet fully federated into AWS SSO or Okta, this approach outpaces legacy key handling—but requires higher-touch initial configuration.

Summary Table

Additional Recommendations:

• Rotate ephemeral credentials frequently—do not depend on single priv-key for Interactive Connect.
• Enable CloudTrail and SSM session logging for all access patterns.
• Remove unused IAM users/roles proactively.
• Test fall-back access paths (e.g., in case SSM agent is broken or IAM misfire).

Practical tip: If you build golden AMIs, bake the correct agents and CA key directly in immutable images to avoid one-off provisioning races.

Relying solely on static SSH keys is unsustainable for secure, compliant, and scalable AWS environments. Instance Connect and SSM Session Manager cover at least 90% of daily operational needs with minimal friction and strong auditability. OpenSSH CA integration addresses the last 10% for mature orgs needing strict lifecycle and lateral movement controls.

For further reading: see AWS whitepapers on secure access patterns, or the EC2 Instance Connect and SSM Agent release notes for version-specific quirks. Feedback or production war stories welcome. Secure access is never “set and forget.”