Limit SSH to AWS console connect and home IP

Hello.

Are you connecting from the Management Console using EC2 Instance Connect?
In that case, please try configuring your EC2 security group to allow the EC2 Instance Connect managed prefixes as described in the following document.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-connect-tutorial.html#eic-tut1-task2

When you use EC2 Instance Connect in the Amazon EC2 console to connect to an instance, the traffic that must be allowed to reach the instance is traffic from the EC2 Instance Connect service. This is different to connecting from your local computer to an instance; in that case, you must allow traffic from your local computer to your instance. To allow traffic from the EC2 Instance Connect service, you must create a security group that allows inbound SSH traffic from the IP address range for the EC2 Instance Connect service.

I’ll explain why the Console SSH attempt is failing, give a secure recommended solution (no open 22), and provide exact steps/commands you can run to allow only your home IP + AWS Console access (with options).

Checklist (requirements)

• Allow SSH access from: (A) your home IP and (B) AWS Console method you use.
• Minimize exposure (avoid 0.0.0.0/0 on port 22).
• Provide step-by-step fix and a secure alternative if you don’t want to open port 22 to AWS IP ranges.

Short answer / recommendation

• Don’t try to open port 22 to the “AWS Console” IPs — those come from ephemeral AWS service IP ranges and are brittle to maintain. Instead use AWS Systems Manager (Session Manager) or Session Manager port‑forwarding. This allows console-based shell or SSH without opening inbound 22 at all, and is the most secure, recommended fix.

Why your existing rule (home IP only) doesn’t work

• Security group rules allow traffic based on the packet’s source IP. When you click “Connect” in the AWS Console, the connection may be proxied or originate from AWS service IPs (not your home IP), so the packet source isn’t your home IP and the SG blocks it. Relying on AWS-managed IP ranges is possible but fragile and broad.

Two secure options (with steps)

Option A — Recommended: Use AWS Systems Manager (Session Manager) (no inbound SSH required) Benefits: no inbound 22, IAM-based access, auditable, works from AWS Console and AWS CLI.

Steps overview:

1. Give the instance an IAM role with the managed policy AmazonSSMManagedInstanceCore.
2. Ensure the SSM Agent is installed and running on the instance.
3. Ensure the instance can reach SSM endpoints (outbound HTTPS or VPC endpoints).
4. Connect via Console > Systems Manager > Session Manager (or aws ssm start-session).

Key commands and checks (run on instance or locally as indicated)

• Attach IAM role (console easiest): EC2 > Instance > Actions > Security > Modify IAM role → choose a role that has AmazonSSMManagedInstanceCore.
  • Or create role via AWS CLI (example skeleton):

# create trust policy file trust.json with EC2 assume-role (one-time)
# then (PowerShell)
aws iam create-role --role-name EC2SSMRole --assume-role-policy-document file://trust.json
aws iam attach-role-policy --role-name EC2SSMRole --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
# create instance profile and attach to instance (or use console)

• Install/start SSM Agent (run on the instance). Examples:

For Amazon Linux 2:

sudo yum install -y amazon-ssm-agent
sudo systemctl enable amazon-ssm-agent
sudo systemctl start amazon-ssm-agent
sudo systemctl status amazon-ssm-agent

For Ubuntu:

sudo snap install amazon-ssm-agent --classic
sudo systemctl enable snap.amazon-ssm-agent.amazon-ssm-agent
sudo systemctl start snap.amazon-ssm-agent.amazon-ssm-agent

• Verify instance appears as managed in Systems Manager: Console > Systems Manager > Fleet Manager or use CLI:

aws ssm describe-instance-information

• Open a console session (no SG changes):
  • Console: Systems Manager → Session Manager → Start session (select instance).
  • OR CLI:

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

• SSH over SSM (port forwarding) — if you want to use your normal SSH client but without opening 22:

# Start port-forwarding session (local port 2222 -> instance 127.0.0.1:22)
aws ssm start-session --target i-0123456789abcdef0 --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters '{"host":["127.0.0.1"],"portNumber":["22"],"localPortNumber":["2222"]}'
# In another terminal, SSH to the forwarded port:
ssh -i path\to\private_key -p 2222 ec2-user@127.0.0.1

Option B — If you must use EC2 Instance Connect (browser SSH): allow AWS service IP ranges (less secure)

• You can add inbound SG rules for the AWS IP prefixes that the console uses, but these prefixes change and may be broad. AWS publishes ip-ranges.json you can filter, but there is no guarantee coverage and it expands attack surface.

Example (fetch prefixes and add to SG) — informational only:

# Fetch AWS ip ranges
Invoke-RestMethod -Uri https://ip-ranges.amazonaws.com/ip-ranges.json | ConvertTo-Json -Depth 10
# Filter for relevant service/region and add inbound rules to your SG — NOT recommended for narrow security

If you choose this route, prefer adding only the minimal required prefixes and revert them after use. Or use a short-term temporary SG rule for contest time window.

Extra security option: Bastion host + private SSH + SSM

• Run a small bastion host restricted to your home IP, or better: put bastion in private subnet and use Session Manager (SSM) for admin access. This reduces instances with public 22 exposure.

Troubleshooting checklist

• If you pick SSM and it fails: check IAM role attached, SSM agent running, instance has outbound internet (NAT or internet) or SSM VPC endpoints, and the instance shows up in Systems Manager console.
• If you pick SG rule and console still blocked: confirm what exact “Connect” method you use (EC2 Instance Connect, browser-based SSH, or SSM). If browser-based EC2 Instance Connect, source IP likely is AWS; inspect CloudWatch VPC Flow Logs to see the packet source and confirm.