Ready-to-use AWS Account AWS Linux Server Access Troubleshooting Guide

AWS Linux Server Access Troubleshooting Guide

When you can’t access an AWS Linux server, the problem is rarely one single thing. It’s usually a chain: network path, security rules, instance reachability, and finally the operating system and services. This guide walks through a practical, step-by-step troubleshooting flow that helps you narrow down the cause quickly—without jumping randomly between fixes.

Use it like a checklist. Start with the fastest, most common causes, and only move deeper when the earlier checks confirm everything looks healthy.

1) Clarify the Symptom Before Troubleshooting

“Can’t access” can mean different failures. Before you start, write down exactly what you see when you try to connect.

Ready-to-use AWS Account Common symptom patterns

• Connection timed out: Usually a network path issue (security group, NACL, route, firewall, wrong IP/subnet).
• Connection refused: Network path exists, but the service isn’t listening (SSH daemon down, wrong port, wrong bind address).
• Permission denied (publickey): Network is fine; authentication/keys/user permissions are wrong.
• Host key verification failed: You’re connecting to a different instance than before, or keys changed.
• Unable to locate instance / DNS fails: Wrong public IP/DNS name, instance stopped, or incorrect region.

Even one sentence like “I get a timeout on port 22” will save hours.

2) Confirm You’re Targeting the Right Instance and Region

It sounds basic, but many access issues come from operational mistakes.

Verify these items in the AWS console

• Region: Make sure you’re viewing the same AWS region where the instance lives.
• Instance state: The instance must be running to accept network connections.
• Correct instance: Confirm the instance ID matches what you intended.
• Public IP vs private IP: If you’re connecting from your laptop over the internet, you usually need the instance’s public IP (or a reachable bastion/VPN setup for private IP).

If the instance is stopped or has been replaced, your previous access assumptions (including keys and host fingerprints) may no longer apply.

3) Check Security Group Rules (Most Common Cause)

For EC2, the security group is your first gatekeeper. A wrong rule often produces the classic timeout.

What to verify

• Ready-to-use AWS Account Inbound rule for SSH: For standard SSH, check that port 22 is allowed.
• Source IP (or CIDR): Restricting to your IP is good, but make sure it includes your current public IP.
• Protocol: Must be TCP for SSH.
• Correct security group attached: Instances can have multiple security groups—verify the inbound rules in all of them.

Quick practical test

Temporarily widen the SSH source rule to a known safe CIDR for testing (only if your security posture allows). If access suddenly works, you’ve confirmed the problem is in the security group rules, not in the instance OS.

4) Consider Network ACLs and Route/Link Issues

Even if the security group allows traffic, a network ACL (NACL) can still block it. Also, routing problems can cause timeouts.

Network ACL checks

• Inbound rule allows the TCP port (22 or your custom SSH port) from your source range.
• Outbound rule allows responses back (for stateful behavior, remember that NACLs are stateless).
• Rule order: NACL rules are evaluated in order. Ensure the matching rule permits traffic.

Route table checks

If the instance is in a private subnet, confirm the route table points to a path that makes sense (for example, a NAT gateway for outbound, and appropriate ingress via VPN/bastion for inbound). Without a reachable path, SSH will never succeed from the public internet.

5) Verify the Instance Public Access Path

If you’re connecting to a public endpoint, ensure that the public IP/DNS and any gateways are correct.

Ready-to-use AWS Account Public IP basics

• The instance must have a valid public IP (if you rely on it).
• If you use an Elastic IP, confirm it’s associated with the instance.
• Double-check you’re using the correct public DNS name or public IP for that instance.

If your security group allows SSH but you still time out, you may be targeting the wrong IP/DNS, the instance might not be reachable due to subnet routing, or something upstream is blocking.

6) Confirm SSH Is Actually Running Inside the OS

Once network-level access is possible, the next failure point is the SSH daemon and its configuration.

On the instance: check SSH service

After you gain any form of access (console, SSM, or a bastion), run checks like the following. The exact commands can vary slightly by distribution.

• Check service status (systemd): systemctl status sshd (or ssh on some distributions)
• Confirm it’s enabled: systemctl is-enabled sshd
• Confirm it’s listening on the port: ss -lntp | grep -E ':22|:YOUR_PORT'

Common SSH daemon problems

• sshd not running: The service crashed or was disabled.
• Changed SSH port: Security group still allows 22, but sshd listens on another port.
• Bind address mismatch: sshd is bound only to localhost, making remote connections impossible.
• Firewall inside the instance: OS-level firewall can block inbound traffic even when AWS security groups allow it.

7) Check Local Firewall Rules (Linux-Level)

AWS security controls traffic before it reaches the instance, but Linux can also block it.

Typical firewall tools

• firewalld
• ufw (Ubuntu)
• iptables/nftables

What to look for

• Is the SSH port permitted in the firewall?
• Is the firewall enabled and enforcing default deny?
• Are there rules that only allow from a specific interface or subnet?

If you recently hardened the server, check your changes. A small firewall rule update can break remote access quickly.

8) Validate the SSH Port, Protocol, and Configuration

Even with service running, configuration can prevent successful logins.

Check sshd_config basics

Inspect your SSH configuration (often at /etc/ssh/sshd_config).

• Port: Confirm it matches the port you opened in the security group.
• ListenAddress: Confirm it’s not limited to a non-routable address.
• PasswordAuthentication and PubkeyAuthentication: Confirm it allows the authentication method you’re using.
• AllowUsers, DenyUsers: These can silently block your username.
• Match blocks: A Match User or Match Address section may apply only to certain users/clients.

After changes, restart SSH safely

Use a controlled restart and keep console access available when testing. A typo in sshd_config can lock you out.

9) Handle Authentication Failures (Keys, Users, and Permissions)

If you can reach the server but authentication fails, you’re past networking. Now it’s about keys, users, and file permissions.

Typical error: Permission denied (publickey)

• You’re using the wrong key for this instance.
• The SSH username is wrong (for example, using ec2-user vs ubuntu vs admin depending on image).
• Ready-to-use AWS Account The public key isn’t installed in the right place.
• Directory/file permissions on ~/.ssh and authorized_keys are too loose.

Check the expected authorized_keys location

Ready-to-use AWS Account For the target user, authorized keys are usually stored in:

• /home/USERNAME/.ssh/authorized_keys

On some hardened or custom images, the path may differ, but the general structure is the same.

Permissions that commonly break SSH

Ready-to-use AWS Account SSH expects strict permissions:

• ~/.ssh directory: commonly 700
• authorized_keys file: commonly 600
• Ownership must be correct for the target user

If ownership or permissions are off, SSH may refuse the key even when it’s present.

10) Confirm IAM, Instance Profile, and SSM (If You Use It)

If you rely on AWS Systems Manager (SSM) Session Manager instead of opening SSH to the internet, your troubleshooting shifts toward IAM and agent health.

SSM common failure causes

• The SSM agent isn’t installed or isn’t running.
• The instance doesn’t have the correct IAM role (instance profile) attached.
• Network egress is blocked if the instance can’t reach SSM endpoints (in private subnets, this often requires NAT or VPC endpoints).

What to check

• Agent status inside the OS
• Instance profile permissions
• Whether the instance appears as managed in Systems Manager

If SSM works, you can troubleshoot SSH config and keys locally from the instance shell without relying on inbound SSH.

11) Use AWS Console Recovery Options When SSH Is Broken

When you can’t log in via SSH, you still have options. The goal is to regain enough access to fix root causes.

Ready-to-use AWS Account Practical recovery paths

• EC2 Serial Console (if enabled for the instance)
• SSM Session Manager (if configured)
• EC2 Instance Connect (if supported and configured)
• Modify user data or disk-based fixes via snapshots and mounts (more involved)

Pick the option available in your environment. The best approach depends on what access methods you set up beforehand.

12) Troubleshoot Using a Simple Decision Tree

Here’s a straightforward way to decide where to focus next.

Step 1: Is the connection timing out?

• Yes → focus on route, security group inbound, NACL, correct IP/region, and whether the instance is in a reachable subnet.
• No, it connects but authentication fails → focus on sshd status, sshd_config, and user/key permissions.
• No, it connects and shows “connection refused” → focus on sshd listening port and firewall blocking.

Step 2: If you can connect, what error message do you get?

• publickey denied → keys/user mismatch, missing public key, wrong permissions on authorized_keys.
• password auth disabled → enable correct method or use the key-based approach your server allows.
• host key mismatch → verify you’re not connecting to the wrong instance; after rebuilding, update local known_hosts if you trust the new host.

This decision tree prevents you from chasing OS settings when the network path is the real issue.

13) Validate Instance Health and Logs

Ready-to-use AWS Account If SSH is running but still fails, check system logs for hints.

Helpful log sources

• Ready-to-use AWS Account SSH service logs (journal): journalctl -u sshd
• Authentication logs (paths vary by distro): commonly /var/log/auth.log or /var/log/secure
• System logs around network or firewall events

Look for patterns like “not allowed” messages, failed key parsing, or configuration errors at startup.

14) Security Group Strategy for Long-Term Stability

Once you fix the immediate problem, consider making access safer and more predictable.

Recommended practices

• Use least privilege in security groups (restrict source CIDR instead of 0.0.0.0/0).
• Prefer SSM Session Manager to avoid public SSH exposure.
• Standardize AMIs so usernames, keys, and SSH ports are consistent across environments.
• Document recovery steps so you know which access method is available when SSH breaks.

A good setup turns “access troubleshooting” from a panic event into a routine process.

15) A Practical “What to Do Next” Checklist

If you need a quick, actionable plan right now, follow this order.

• Confirm instance is running and you’re using the correct region and IP/DNS.
• Check security group inbound for SSH port and source IP.
• Check NACL and subnet routing if timeouts persist.
• From the OS side, verify sshd is running and listening on the expected port.
• Check Linux firewall for the SSH port.
• Verify sshd_config for Port, ListenAddress, and user restrictions.
• Validate authorized_keys and permissions if you get publickey errors.
• Check logs for exact reasons of failure.
• Use SSM/console recovery if SSH can’t be restored through normal means.

Most importantly: make one change at a time and record what you learned. That way, the next incident is faster, and you don’t repeat the same mistakes.

Conclusion

AWS Linux access troubleshooting becomes manageable when you treat it as a layered problem: network path first, then instance reachability, then service configuration, and finally authentication and permissions. With the symptom-based approach in this guide, you can narrow down the cause quickly and fix it with confidence—without turning the server into a guessing game.