Replace the 0.0.0.0/0 rule with your specific office/VPN CIDRs, or remove inbound SSH entirely. Prefer SSM Session Manager for shell access: no open port, full audit trail, IAM-controlled. If you need ad-hoc access, use EC2 Instance Connect with short-lived, scoped permissions.

Compliance High severity

AWS Security Hub · EC2

EC2.13: SSH (port 22) is open to the entire internet

Written and reviewed by Emnode · Last reviewed 27 May 2026

What does AWS Security Hub EC2.13 check?

EC2.13 fails security groups that allow inbound SSH (TCP port 22) from 0.0.0.0/0 or ::/0: SSH open to the entire internet.

Why does EC2.13 matter?

Port 22 open to the world is a magnet for automated brute-force and credential-stuffing. It is one of the most exploited misconfigurations in AWS, and it only takes one weak key or reused password. Administrative access should never be reachable from anywhere on the planet.

How do I fix EC2.13?

Replace the 0.0.0.0/0 rule with your specific office/VPN CIDRs, or remove inbound SSH entirely.
Prefer SSM Session Manager for shell access: no open port, full audit trail, IAM-controlled.
If you need ad-hoc access, use EC2 Instance Connect with short-lived, scoped permissions.

Remediation script · bash

# Revoke an over-open admin rule, covering both IPv4 and IPv6 in one call.
aws ec2 revoke-security-group-ingress --group-id sg-0a1b2c3d \
  --ip-permissions 'IpProtocol=tcp,FromPort=22,ToPort=22,IpRanges=[{CidrIp=0.0.0.0/0}],Ipv6Ranges=[{CidrIpv6=::/0}]'

# Where access is genuinely needed, re-add it scoped to a source security group, not a CIDR.
aws ec2 authorize-security-group-ingress --group-id sg-0a1b2c3d \
  --ip-permissions 'IpProtocol=tcp,FromPort=6379,ToPort=6379,UserIdGroupPairs=[{GroupId=sg-0app1234,Description=app-tier}]'

# Strip a default security group to empty by feeding its current rules back into revoke.
INGRESS=$(aws ec2 describe-security-groups --group-ids sg-0default01 \
  --query 'SecurityGroups[0].IpPermissions')
[ "$INGRESS" != "[]" ] && aws ec2 revoke-security-group-ingress \
  --group-id sg-0default01 --ip-permissions "$INGRESS"

Full walkthrough (console steps, edge cases and verification) in the lesson Harden security groups and restrict ingress.

Is EC2.13 a false positive?

Genuine false positives here are rare and should be treated with suspicion: port 22 open to 0.0.0.0/0 or ::/0 is almost never intentional. The closest legitimate case is a security group that exists but is attached to nothing, or a bastion fronted by a separate control such as an NLB or AWS Network Firewall that actually restricts the source, since EC2.13 evaluates the security group rule in isolation and can't see that upstream layer. Even then, the safer move is to tighten the rule to the real allowed CIDRs rather than rely on the outer layer. If you must keep the rule (for example a deliberately isolated honeypot) suppress that specific finding with the workflow status set to SUPPRESSED (via BatchUpdateFindings or an automation rule) and a documented justification, and never blanket-suppress this High-severity control across the account.

Full lesson Harden security groups and restrict ingress Step-by-step remediation with CLI, code and persona-specific context.

AWS documentation for EC2 controls ↗ Check your own account for EC2.13 →

Part of the learning path Lock down access

EC2.1 An EBS snapshot is publicly restorable by any account
EC2.2 Default security groups still allow traffic
EC2.3 Attached EBS volumes are not encrypted at rest
EC2.4 Long-stopped instances are abandoned attack surface
EC2.6 No VPC flow logs, so there is no network audit trail
EC2.7 New EBS volumes are not encrypted by default
EC2.8 IMDSv1 lets an SSRF steal instance credentials
EC2.9 Instances are directly reachable on public IPv4
EC2.10 EC2 API traffic leaves the VPC over the internet
EC2.14 RDP (port 3389) is open to the entire internet
EC2.15 Subnets auto-assign public IPs to new instances
EC2.17 Instances with multiple ENIs can bridge network boundaries