Skip to content

AWS Updated 2026-07-04

Using the EC2 serial console when SSH is dead

The EC2 serial console gives you an out-of-band terminal into an instance when SSH is dead — no working network required. Here is how to enable it, log in, and fix the firewall, fstab, or sshd mistake that locked you out.

The EC2 serial console is the crash cart of AWS: a text terminal attached to the instance’s serial port that works even when the network configuration, firewall, or sshd on the instance is completely broken. It needs three things you should set up before the emergency: serial console access enabled at the account level, an IAM permission, and an OS user with a password — because the serial console lands you on a login prompt, and most cloud images ship with password login disabled. Set those up on a calm afternoon and a locked-out instance becomes a five-minute fix instead of a volume-swap surgery.

What’s happening

SSH depends on the entire stack working: network path, security groups, the OS network configuration, a running sshd, and valid keys. The serial console bypasses all of it. It connects to ttyS0 — the virtual serial port — through AWS’s control plane, the same way a physical console cable would on a rack server. Security groups, route tables, and the instance’s iptables rules are irrelevant to it, which is exactly why it is the right tool when you have firewalled yourself out, broken /etc/fstab, mangled netplan or NetworkManager config, or killed sshd with a bad config edit.

The constraints: it is available on Nitro-based instances only (virtualized — bare metal is excluded), access must be enabled per account per region, one session per instance at a time, and the OS side presents a standard login: prompt on the serial line. That last point is the trap. Ubuntu, Amazon Linux, and Debian images ship with no password set on any user, so the serial console shows you a login prompt you cannot pass. You need to have set a password beforehand — or set one now through some other channel (SSM, user data trickery, or a volume swap) — which is why the honest advice is: prepare this before you need it. There is no additional charge for using the serial console.

What to check first

  • Is the instance Nitro-based? aws ec2 describe-instance-types --instance-types m7i.large --query 'InstanceTypes[].Hypervisor' returns nitro for supported families. Older Xen types have no serial console.
  • Is serial console access enabled for the account in this region? It is off by default.
  • Do you have the IAM permission? ec2-instance-connect:SendSerialConsoleSSHPublicKey gates access, browser and CLI alike.
  • Does any OS user have a password? No password, no login — the console will connect and still leave you at a prompt you cannot pass.
  • Is the instance running? The serial console attaches to running (and rebooting) instances; a stopped instance has no console to attach to.

How to verify

Check and enable account-level access:

aws ec2 get-serial-console-access-status

# Enable it (account-wide, per region)
aws ec2 enable-serial-console-access

In the console, the same toggle lives under EC2 > Settings (Account attributes) > EC2 Serial Console. To open a session from the browser: EC2 > Instances > select instance > Actions > Monitor and troubleshoot > EC2 Serial Console. From a terminal, you push a temporary SSH public key and connect to the regional serial-console endpoint:

aws ec2-instance-connect send-serial-console-ssh-public-key \
  --instance-id i-0123456789abcdef0 \
  --serial-port 0 \
  --ssh-public-key file://~/.ssh/id_ed25519.pub

ssh -i ~/.ssh/id_ed25519 \
  i-0123456789abcdef0.port0@serial-console.ec2-instance-connect.ca-central-1.aws

The key is valid for 60 seconds, so connect promptly. Full prerequisites and the per-region endpoints are in the EC2 documentation at https://docs.aws.amazon.com/ec2/.

The runbook

  1. Enable access and set a break-glass password now, not during the incident. Enable serial console access in each production region, grant the IAM permission to the operations role, and set a strong password on a dedicated local user (sudo passwd ec2-user, or a purpose-made console-rescue user) on your base images. Store the password in your secrets manager.
  2. Open the session and log in. Browser or SSH method above. If the screen is blank, press Enter to wake the getty. You land in a normal shell with root available via sudo.
  3. Fix what locked you out. The usual suspects, in observed order: an iptables/ufw/firewalld rule dropping port 22 (sudo ufw status, sudo iptables -L -n), a broken sshd config (sudo sshd -t names the bad line, then sudo systemctl restart sshd), a bad /etc/fstab entry holding boot hostage (comment it out, reboot), or a network config edit that took eth0 down (ip a, then repair the netplan/NetworkManager file and reapply).
  4. Watch a broken boot live. Reboot from within the session and the serial console shows GRUB and kernel output in real time — the failing unit or the panic message scrolls past instead of being something you infer from a screenshot. On distros where you see nothing, the kernel command line may be missing console=ttyS0; Amazon Linux ships correctly configured.
  5. Verify SSH works again before you close the console. Test the actual login path from your workstation. The serial session is your safety line — do not drop it until the normal door is confirmed open. If SSH still times out from outside, the remaining problem is on the AWS network path, and the SSH timeout checklist walks that side.

When this is the wrong move

If SSM Agent is on the instance, healthy, and registered, Session Manager is the better everyday door — IAM-authenticated, audited, no passwords involved; keep the serial console for when the agent or the network beneath it is the casualty. If the instance fails to boot at all because the root filesystem is corrupted, the serial console shows you the failure but cannot always fix it — that escalates to the stop, detach, repair-on-a-helper, reattach flow described in the status-check recovery runbook. And on Xen-generation instances there is no serial console; volume swap is the only surgery available.

Common mistakes

  • Discovering during the outage that serial console access was never enabled and no user has a password — the tool works, but only for people who prepared.
  • Leaving the serial session before confirming SSH works, then paying for a second lockout.
  • Setting a weak break-glass password because “it is only the serial console” — it is a root-capable door; treat the password like one.
  • Assuming the serial console needs the instance’s network to be healthy — it does not; that is the entire point.

Prevention

  • Enable serial console access in every production region as part of account baseline, and audit the IAM permission to a small operations group.
  • Bake a passworded break-glass user into your AMIs, with the password vaulted and rotated.
  • Prefer Session Manager for daily access so port 22 can stay closed entirely.
  • Test the whole path quarterly: open a session, log in, exit. An untested break-glass procedure is a hope, not a procedure.
  • Keep console=ttyS0 on the kernel command line of custom images so boot output is actually visible.

An out-of-band console turns “we are locked out of production” from an incident into a chore — but only if the account was prepared before the day it mattered. If nobody on your team truly owns the AWS environment end to end, that is the root of most of these problems — Stack Harbor runs AWS accounts daily under AWS Operations, and you can book an AWS review.