EC2 SSH connection stops working after a period of time while status checks remain 3/3

Hello.

I, too, have experienced an issue in the past where using VS Code Remote-SSH caused a load on the EC2 instance, making SSH connections impossible.
In my case, VSCode Remote SSH was consuming a large amount of memory, causing OOM errors.
The issue was resolved by creating a swap file to increase the temporary memory space and simply upgrading the instance size.
I cannot say for certain without looking at your EC2 instance's syslog, but I suspect there may be a memory-related issue, as indicated here.
https://github.com/microsoft/vscode/issues/175830

Most likely causes: The sshd process itself has hung, or OS resources are exhausted.

1. CPU credit exhaustion (for T-series instances): Burstable instances (t2/t3/t4g series) drop to baseline performance when CPU credits run out; this can make forking new processes (i.e., establishing new SSH sessions) extremely slow or effectively unresponsive.

2. Memory exhaustion: In an OOM (Out of Memory) state, the system cannot spawn new processes; even if the existing sshd listener process remains active, it cannot launch session handlers for new connections. Disk space exhaustion: If partitions like /var or /tmp become full, sshd may fail to write logs or perform PAM-related tasks, leading to similar symptoms.

3. Factors specific to VS Code Remote-SSH: There are reports that sessions generated by the Remote-SSH extension can accumulate and consume server-side resources over time. This aligns with your observation that the issue became noticeable after a VS Code update.

Most important next step: Use the serial console.

While both SSH and EC2 Instance Connect rely on network stack access, the EC2 serial console provides direct access to the instance's virtual console, bypassing the network stack entirely. This means that even if SSH is completely unresponsive, there is a high probability that you can still log in via the serial console.

The three usual suspects: CPU is maxed out – Some program is eating 100% of the processor, so "sshd" can't get a turn to respond. Memory is full – The server ran out of RAM. Linux may have killed "sshd" or the system is crawling because it's swapping to disk. Disk is full – The hard drive has zero free space, so "sshd" can't even write log files or create a session. What to do when you get back in: Run "top" to see what's eating CPU/memory Run "df -h" to check disk space Look at "journalctl -u sshd" to see what happened

Hello AWS Support,

I would like to provide an update regarding the intermittent SSH connectivity issue with my EC2 instance.

The issue currently appears to be resolved or at least no longer reproducible. I have been able to use the instance normally through both VS Code Remote-SSH and standard SSH connections.

During the investigation, I observed the following:

• The instance is running Amazon Linux 2023.
• The instance has approximately 913 MiB of total RAM and no swap configured.
• VS Code Remote-SSH starts VS Code Server processes on the instance. The extension host was using approximately 430–435 MB RSS.
• CPU load remained very low (approximately 0.00–0.18).
• Root filesystem usage was approximately 28%, so disk space does not appear to be an issue.
• I checked the kernel/journal logs for OOM (Out Of Memory), "killed process", and related memory-pressure messages. No OOM events were found.
• I tested file creation, reading, and deletion through the Remote-SSH terminal successfully.
• I disconnected and reconnected using VS Code Remote-SSH successfully. The previous VS Code Extension Host process was terminated and a new one was created; I did not observe multiple Extension Host processes accumulating.
• I also established a separate standard SSH connection while the VS Code Remote-SSH connection was active. Both connections worked simultaneously.
• The sshd process and multiple sshd sessions were functioning normally.

I also discovered that the user's ~/.bashrc file contained a corrupted PS1 prompt definition and an unexpected "OA" line. This was causing shell errors such as:

-bash: 5: command not found -bash: 82m]u[e[0m]@[e[38: command not found

I corrected the ~/.bashrc configuration, and these login/shell errors no longer occur.

At this point, the instance is stable and I can connect through both normal SSH and VS Code Remote-SSH without problems.

However, I would still like AWS Support to help determine the root cause of the original incident. Previously, after using VS Code Remote-SSH, the EC2 instance eventually became inaccessible through SSH, and I was also unable to connect using EC2 Instance Connect. Rebooting the instance was required before connectivity could be restored.

Could you please review the available EC2/system-level logs and determine whether there was any evidence of:

1. SSH/sshd failure or resource exhaustion,
2. memory pressure or process termination,
3. network-level connectivity problems,
4. EC2 host or instance-level issues,
5. or any interaction between VS Code Remote-SSH / VS Code Server and the observed SSH connectivity failure?

The issue is currently not reproducible, so I would especially appreciate any analysis of the historical period when the instance became completely inaccessible.

Thank you.

The 'works fine then stops after a while' pattern with status checks still green is almost always the Linux OOM killer taking out sshd. EC2 status checks only measure CPU and network reachability, not memory, so a box can be quietly running out of RAM and look perfectly healthy in the console.

Quick thing to check right now: run dmesg | grep -i oom on the instance and look for lines mentioning sshd. If you see them, that's your answer.

Also worth enabling AWS Systems Manager Session Manager as a fallback if you haven't already. It's free and gets you a shell even when SSH is completely dead, which is really useful for diagnosing the next occurrence live.

If dmesg confirms OOM, the fix is usually adding swap (EC2 doesn't configure any by default) and installing the CloudWatch Agent to start collecting memory metrics so you can actually see the pressure building.

I've put together a structured write-up covering the root-cause matrix for exactly this failure pattern, with diagnostic commands, a CloudWatch Agent config for memory and sshd process monitoring, and an optional auto-remediation setup. Happy to share it. One quick question that would help me point you to the right section first: what error do you see on the client when SSH fails, 'Connection refused' or 'Connection timed out'? That single detail tells us whether sshd is dead or the instance is fully unresponsive, and changes what to do next.