What is SSH IP Whitelisting?

Security Groups in AWS act as virtual firewalls attached to EC2 instances, controlling inbound and outbound traffic at the instance level.

IP whitelisting means explicitly allowing SSH connections only from specific IP addresses or CIDR ranges you trust, such as your office network, VPN exit IP, or a bastion host, while denying all other sources by default.

Why Restrict SSH Access?

• Publicly exposed SSH invites constant automated scanning and brute-force login attempts
• A single compromised credential can lead to full instance takeover
• Hard to trace which login attempts are legitimate vs. malicious
• Increases compliance risk under frameworks like ISO 27001, SOC 2, and CIS AWS Benchmarks

Benefits of Whitelisting SSH Access

• Drastically reduces exposed attack surface
• Only pre-approved IPs can even attempt to connect
• Easy to audit — security group rules clearly show who has access
• Works alongside other controls like key-based auth and MFA
• No additional infrastructure or agents required

How It Works

• Identify the trusted IP(s) that should have SSH access (e.g., office IP, VPN IP, bastion host IP)
• Edit the instance's Security Group inbound rules
• Remove any rule allowing SSH (port 22) from 0.0.0.0/0
• Add a new inbound rule allowing port 22 only from the specific IP/CIDR (e.g., 203.0.113.25/32)
• Save changes — AWS applies security group rules instantly, no instance restart needed

Use a Non-Standard SSH Port

In addition to IP whitelisting, changing SSH from the default port 22 to a non-standard port adds another layer of defense. Most automated bots and internet-wide scanners target port 22 by default, so moving off it significantly cuts down on noise from opportunistic scanning attempts.

• Update the Port directive in /etc/ssh/sshd_config to a custom high-numbered port (e.g., 2222 or another value outside common well-known ranges)
• Restart the SSH daemon (sudo systemctl restart sshd) for the change to take effect
• Update the corresponding Security Group inbound rule to allow the new port instead of 22, still restricted to your whitelisted IP(s)
• Update any bastion hosts, deployment scripts, or SSH config files (~/.ssh/config) that reference the old port

Note that this is a supplementary measure, not a replacement for IP whitelisting — obscuring the port reduces automated noise, but the whitelist is what actually enforces who can connect.

Common Use Cases

• Restricting SSH to a company's static office IP
• Allowing SSH only through a bastion/jump host's private IP
• Limiting SSH access to a VPN gateway's exit IP
• Locking down SSH for temporary access during maintenance windows, then removing the rule afterward

Example Scenario

• Team's office has a static public IP: 203.0.113.25
• Create/update inbound rule: Type = SSH, Port = 22, Source = 203.0.113.25/32
• Remove the old 0.0.0.0/0 rule for port 22
• Only requests originating from that IP can reach port 22; everyone else is blocked at the network level before authentication even happens

Best Practices

• Use /32 CIDR for a single IP rather than broad ranges
• Prefer a bastion host or VPN over exposing SSH broadly, even to a whitelist
• Rotate and review whitelisted IPs regularly, especially after employee offboarding or office network changes
• Combine with key-based authentication (disable password login)
• Use separate security groups per environment (prod, staging, dev)
• Monitor SSH access attempts via CloudTrail/VPC Flow Logs
• Run SSH on a non-standard port alongside IP whitelisting for defense in depth

Common Mistakes to Avoid

• Leaving 0.0.0.0/0 as a fallback "just in case" rule
• Whitelisting an entire office/ISP CIDR block instead of a specific IP
• Forgetting to update the whitelist when your IP changes (e.g., dynamic home IPs)
• Applying the rule to the wrong security group, leaving another instance still exposed
• Not documenting who requested access and why
• Changing the SSH port without updating the Security Group rule to match

Verify Hardening with Kawach Server Monitor

IP whitelisting and a non-standard port reduce exposure at the network level, but it's equally important to confirm that the underlying OS and login/access control configuration are hardened correctly.

You can install Kawach Server Monitor on your instances to continuously evaluate login and access control settings alongside Kawach's broader library of 100+ security and compliance checks, giving you audit-ready visibility beyond what security group rules alone can confirm.