I recently encountered a perplexing issue where my Amazon EC2 instance running Ubuntu 13.10 would lose SSH connectivity after a simple reboot. The instance would start normally, accept SSH connections initially, but after rebooting, all attempts to connect would result in "Connection refused" errors. The security groups were properly configured (port 22 open to 0.0.0.0/0), and the IP address remained unchanged.

Examining the system logs (available here) revealed some critical clues:

[FAILED] Failed to start OpenBSD Secure Shell server.
See 'systemctl status ssh.service' for details.

This indicated that the SSH service wasn't starting automatically after reboot. While Ubuntu 13.10 is quite old now (this issue applies to newer versions too), the fundamental problem remains relevant.

After extensive testing, I identified three potential culprits:

• SSH daemon not configured to start on boot
• EC2 instance metadata service issues
• Filesystem check failures preventing full startup

Here's the step-by-step solution I developed through trial and error:

1. Checking SSH Service Status

sudo systemctl status ssh
# Or for older systems:
sudo service ssh status

2. Enabling SSH at Boot

sudo systemctl enable ssh
# Alternative for older Ubuntu:
sudo update-rc.d ssh defaults

3. Manual Recovery When Locked Out

If you're already locked out, use EC2 Instance Connect or attach the volume to another instance to modify these files:

# /etc/rc.local
/usr/sbin/service ssh start

# /etc/init/ssh.conf
start on (filesystem and net-device-up IFACE=eth0)

To avoid this issue in future deployments:

#!/bin/bash
# Cloud-init script for EC2
apt-get update
apt-get install -y --reinstall openssh-server
systemctl enable ssh

For persistent cases, check these additional configurations:

# Verify network interface initialization
cat /etc/network/interfaces

# Check cloud-init logs
cat /var/log/cloud-init.log

# Examine systemd boot sequence
journalctl -b

After implementing these changes, test the solution by:

1. Rebooting the instance through AWS console
2. Waiting 2-3 minutes for full initialization
3. Attempting SSH connection with verbose output:

ssh -vvv -i your_key.pem user@ec2-instance

This approach has consistently resolved the SSH-after-reboot issue across multiple Ubuntu EC2 instances in my environment.

---

When dealing with SSH connectivity loss specifically after rebooting an EC2 instance, we're typically looking at one of these scenarios:

# Classic connection pattern before failure
ssh -i ~/.ssh/your-key.pem ec2-user@your-instance-public-ip
# Returns: Connection refused (port 22)

First, validate basic network accessibility:

# Check if port 22 is even reachable
nc -zv your-instance-public-ip 22
# Alternative using telnet
telnet your-instance-public-ip 22

# If these fail, check Security Group rules:
aws ec2 describe-security-groups --group-ids sg-xxxxxxxx --query 'SecurityGroups[0].IpPermissions'

The system logs you provided indicate potential filesystem issues during reboot. Key things to verify:

# Get instance console output (replace with your instance ID)
aws ec2 get-console-output --instance-id i-0123456789abcdef > instance-console.log

# Look for these critical markers:
grep -E "Filesystem errors|Failed to mount|sshd.*failed" instance-console.log

When logs show filesystem corruption (common with unexpected reboots):

# For ext4 filesystems (common on Ubuntu)
sudo fsck -y /dev/xvda1

# For XFS filesystems (common on Amazon Linux 2)
sudo xfs_repair /dev/xvda1

Sometimes the SSH service fails to start automatically. Check these:

# Verify sshd is running
sudo systemctl status sshd

# Check for configuration errors
sudo sshd -t

# Examine the auth log
sudo tail -50 /var/log/auth.log | grep sshd

When all else fails, attach the volume to another instance:

# Detach the problematic volume
aws ec2 detach-volume --volume-id vol-0123456789abcdef

# Attach to a rescue instance
aws ec2 attach-volume --volume-id vol-0123456789abcdef --instance-id i-rescueinstance --device /dev/sdf

# Then on the rescue instance:
sudo mount /dev/xvdf1 /mnt/temp
# Repair config files in /mnt/temp/etc/ssh/

To avoid recurrence:

# Enable instance auto-recovery
aws ec2 modify-instance-attribute --instance-id i-0123456789abcdef --attribute disableApiTermination --value false

# Configure cloud-init to handle reboots properly
cat << EOF | sudo tee /etc/cloud/cloud.cfg.d/99_reboot.cfg
cloud_final_modules:
 - [scripts-user, always]
EOF