EC2 SSH Verbindungs-Timeout: Security Group Inbound-Regeln richtig konfigurieren

Du startest eine neue EC2-Instanz, versuchst dich per SSH zu verbinden — und bekommst sofort ein 'Connection timed out'. Kein 'Connection refused', kein Passwort-Prompt, einfach Stille. Das ist fast immer ein Netzwerkproblem auf Infrastrukturebene, und die häufigste Ursache ist eine fehlende oder falsch konfigurierte Inbound-Regel in der Security Group der EC2 SSH-Verbindung.

TL;DR — EC2 SSH Verbindungs-Timeout auf einen Blick

Schicht	Was prüfen	Häufigste Ursache
Security Group	Inbound-Regel für TCP Port 22	Regel fehlt oder falsche Quell-IP
Network ACL	Inbound + Outbound für Port 22 und Ephemeral Ports	Outbound-Regel für Ephemeral Ports fehlt
Route Table	Route zum Internet Gateway (0.0.0.0/0)	Kein Internet Gateway zugewiesen
Instanz	Public IP vorhanden, Instanz-Status 'running'	Keine öffentliche IP zugewiesen

Wie EC2-Netzwerkzugriff funktioniert — Pflichtlektüre vor Schritt 1

Ein SSH-Verbindungsversuch zu einer EC2-Instanz durchläuft mehrere Filterschichten, bevor er die Instanz überhaupt erreicht. Das Verständnis dieser Reihenfolge ist entscheidend, weil ein Timeout an jeder dieser Schichten identisch aussieht — der Client wartet einfach, bis er aufgibt.

Internet Gateway (IGW): Eintrittspunkt ins VPC. Ohne IGW und passende Route erreicht kein externes Paket das Subnetz.
Route Table: Das Subnetz muss eine Route 0.0.0.0/0 → igw-xxxxxxxx besitzen. Fehlt sie, werden Pakete ins Nichts geroutet.
Network ACL (NACL): Zustandslose Firewall auf Subnetz-Ebene. Inbound- und Outbound-Regeln werden unabhängig ausgewertet. Ephemeral Ports (1024–65535) müssen in der Outbound-Richtung explizit erlaubt sein, damit der TCP-Handshake abgeschlossen werden kann.
Security Group: Zustandsbehaftete Firewall auf Instanz-Ebene. Eine erlaubte Inbound-Verbindung erzeugt automatisch den passenden Outbound-Rückkanal — aber nur, wenn die Inbound-Regel überhaupt greift.
Öffentliche IP der Instanz: Ohne zugewiesene Public IP oder Elastic IP ist die Instanz von außen schlicht nicht adressierbar.

Security Groups sind wie ein Türsteher direkt vor der Instanz — er kennt jeden Gast, den er reingelassen hat, und lässt ihn auch wieder raus. NACLs sind wie die Schranke am Parkplatz — sie prüfen jedes Fahrzeug einzeln, egal ob rein oder raus, ohne Gedächtnis.

Schritt-für-Schritt-Diagnose bei EC2 SSH Verbindungs-Timeout

Schritt 1: Öffentliche IP und Instanzstatus prüfen

Bevor du irgendetwas an Firewall-Regeln änderst, stelle sicher, dass die Instanz überhaupt eine öffentliche IP hat und im Status running ist. Eine Instanz ohne Public IP ist von außen nicht erreichbar — die Security Group spielt dann keine Rolle mehr, weil das Paket nie ankommt.

aws ec2 describe-instances \
  --instance-ids i-0123456789abcdef0 \
  --query 'Reservations[*].Instances[*].{State:State.Name,PublicIP:PublicIpAddress,PublicDNS:PublicDnsName}' \
  --output table \
  --region us-east-1

Wenn PublicIP leer ist, wurde beim Start keine öffentliche IP zugewiesen. Du kannst nachträglich eine Elastic IP zuweisen:

# Elastic IP allozieren
aws ec2 allocate-address \
  --domain vpc \
  --region us-east-1

# Elastic IP der Instanz zuweisen (AllocationId aus vorherigem Befehl)
aws ec2 associate-address \
  --instance-id i-0123456789abcdef0 \
  --allocation-id eipalloc-0123456789abcdef0 \
  --region us-east-1

Schritt 2: Security Group Inbound-Regeln prüfen

Das ist die häufigste Ursache. Eine neue EC2-Instanz hat standardmäßig keine SSH-Inbound-Regel, wenn du beim Start keine Security Group mit einer solchen Regel ausgewählt hast. Prüfe zuerst, welche Security Groups der Instanz zugewiesen sind, und dann deren Regeln.

# Security Groups der Instanz ermitteln
aws ec2 describe-instances \
  --instance-ids i-0123456789abcdef0 \
  --query 'Reservations[*].Instances[*].SecurityGroups' \
  --output table \
  --region us-east-1

# Inbound-Regeln einer Security Group prüfen
aws ec2 describe-security-groups \
  --group-ids sg-0123456789abcdef0 \
  --query 'SecurityGroups[*].IpPermissions' \
  --output json \
  --region us-east-1

In der Ausgabe suchst du nach einem Eintrag mit FromPort: 22, ToPort: 22, IpProtocol: tcp. Fehlt er, musst du ihn hinzufügen. Verwende deine eigene IP als Quelle — 0.0.0.0/0 öffnet SSH für das gesamte Internet, was in Produktionsumgebungen vermieden werden sollte.

# Deine aktuelle öffentliche IP ermitteln
curl -s https://checkip.amazonaws.com

# SSH-Inbound-Regel hinzufügen (ersetze 203.0.113.10/32 mit deiner IP)
aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --protocol tcp \
  --port 22 \
  --cidr 203.0.113.10/32 \
  --region us-east-1

graph TD Start(["SSH Timeout beobachtet"]) Q1{"Instanz hat
Public IP?"} Q2{"Security Group:
Inbound TCP 22
für Quell-IP?"} Q3{"NACL: Inbound Port 22
+ Outbound 1024-65535
erlaubt?"} Q4{"Route Table:
0.0.0.0/0 → IGW
vorhanden?"} Fix1["Elastic IP zuweisen"] Fix2["Inbound-Regel Port 22
in Security Group hinzufügen"] Fix3["NACL-Regeln korrigieren
(Inbound + Outbound)"] Fix4["Route zum IGW
hinzufügen"] OK(["SSH-Verbindung möglich"]) Start --> Q1 Q1 -->|"Nein"| Fix1 Q1 -->|"Ja"| Q2 Fix1 --> Q2 Q2 -->|"Nein"| Fix2 Q2 -->|"Ja"| Q3 Fix2 --> Q3 Q3 -->|"Nein"| Fix3 Q3 -->|"Ja"| Q4 Fix3 --> Q4 Q4 -->|"Nein"| Fix4 Q4 -->|"Ja"| OK Fix4 --> OK

Schritt 3: Network ACL prüfen — der häufig übersehene Schuldige

Wenn die Security Group korrekt aussieht und das Timeout trotzdem besteht, ist die Network ACL des Subnetzes der nächste Kandidat. NACLs sind zustandslos — das bedeutet, du brauchst explizite Regeln für beide Richtungen. Der TCP-Handshake schlägt fehl, wenn die NACL zwar Port 22 eingehend erlaubt, aber die ausgehenden Ephemeral Ports (1024–65535) blockiert. Das Timeout sieht identisch aus wie ein fehlendes Inbound-Regel-Problem.

# Subnetz der Instanz ermitteln
aws ec2 describe-instances \
  --instance-ids i-0123456789abcdef0 \
  --query 'Reservations[*].Instances[*].SubnetId' \
  --output text \
  --region us-east-1

# Network ACL des Subnetzes ermitteln
aws ec2 describe-network-acls \
  --filters Name=association.subnet-id,Values=subnet-0123456789abcdef0 \
  --query 'NetworkAcls[*].{AclId:NetworkAclId,Entries:Entries}' \
  --output json \
  --region us-east-1

Prüfe in der Ausgabe:

Inbound: Regel mit RuleAction: allow, Protocol: 6 (TCP), Port 22, für deine Quell-IP oder 0.0.0.0/0
Outbound: Regel mit RuleAction: allow, Protocol: 6 (TCP), Port-Range 1024–65535 (Ephemeral Ports), für 0.0.0.0/0

NACLs werden nach Regelnummer aufsteigend ausgewertet. Die erste passende Regel gewinnt — eine frühe DENY-Regel kann eine spätere ALLOW-Regel vollständig neutralisieren.

Schritt 4: Route Table und Internet Gateway prüfen

Ein Timeout kann auch entstehen, wenn das Subnetz kein Internet Gateway erreicht. Das passiert häufig bei Subnetzen, die ursprünglich als private Subnetze angelegt wurden und nachträglich für öffentliche Instanzen verwendet werden.

# Route Table des Subnetzes prüfen
aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-0123456789abcdef0 \
  --query 'RouteTables[*].Routes' \
  --output json \
  --region us-east-1

Du brauchst eine Route mit DestinationCidrBlock: 0.0.0.0/0 und einem GatewayId, das mit igw- beginnt. Fehlt diese Route, ist das Subnetz effektiv privat — unabhängig von Security Group und NACL-Konfiguration.

# Internet Gateways im VPC auflisten
aws ec2 describe-internet-gateways \
  --filters Name=attachment.vpc-id,Values=vpc-0123456789abcdef0 \
  --query 'InternetGateways[*].{IGW:InternetGatewayId,State:Attachments[0].State}' \
  --output table \
  --region us-east-1

# Route zum Internet Gateway hinzufügen (falls fehlend)
aws ec2 create-route \
  --route-table-id rtb-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --gateway-id igw-0123456789abcdef0 \
  --region us-east-1

Erfahrung aus der Praxis: Der falsche Verdächtige

Symptom: SSH-Timeout auf eine neue Instanz, obwohl die Security Group eine Inbound-Regel für Port 22 mit 0.0.0.0/0 enthält. Instanz hat eine Public IP, Status ist running.

Erstdiagnose: Irgendwas stimmt mit dem SSH-Key nicht, oder der SSH-Daemon ist nicht gestartet. Also: Instanz über EC2 Instance Connect versucht — auch kein Erfolg.

Tatsächliche Ursache: Das VPC war ein älteres Setup. Die Network ACL des Subnetzes hatte eine explizite DENY-Regel für Port 22 mit Regelnummer 100, die vor der ALLOW-Regel mit Nummer 200 ausgewertet wurde. Die Security Group war korrekt — die NACL hat die Verbindung still verworfen, bevor das Paket die Instanz je erreichte.

Fix: NACL-Regel 100 entfernt, Verbindung sofort erfolgreich. Die Lektion: Wenn die Security Group sauber aussieht, ist die NACL der nächste Ort — nicht der SSH-Daemon.

Ein Timeout sagt dir nicht, wo das Paket verloren geht. Es sagt dir nur, dass es nie zurückgekommen ist.

IAM-Berechtigungen für die Diagnose

Die oben gezeigten CLI-Befehle benötigen mindestens folgende IAM-Berechtigungen. Read-Aktionen wie Describe* erfordern häufig Resource: "*", da sie keine ressourcenspezifische ARN-Filterung unterstützen — prüfe dies im AWS Service Authorization Reference.

🔽 IAM Policy für EC2-Netzwerkdiagnose anzeigen

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EC2NetworkDiagnose",
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstances",
        "ec2:DescribeSecurityGroups",
        "ec2:DescribeNetworkAcls",
        "ec2:DescribeRouteTables",
        "ec2:DescribeInternetGateways",
        "ec2:DescribeAddresses"
      ],
      "Resource": "*"
    },
    {
      "Sid": "EC2NetworkModify",
      "Effect": "Allow",
      "Action": [
        "ec2:AuthorizeSecurityGroupIngress",
        "ec2:AllocateAddress",
        "ec2:AssociateAddress",
        "ec2:CreateRoute"
      ],
      "Resource": "*"
    }
  ]
}

EC2 SSH Verbindungs-Timeout — Nächste Schritte und weiterführende Ressourcen

Wenn du alle vier Schichten geprüft hast und das Timeout weiterhin besteht, prüfe zusätzlich, ob auf der Instanz selbst ein Host-Firewall (z.B. iptables oder firewalld) aktiv ist. Das ist eine Betriebssystem-Ebene, die unterhalb von Security Groups und NACLs liegt und ebenfalls Verbindungen blockieren kann — ohne dass AWS-seitige Logs darauf hinweisen.

Für Produktionsumgebungen empfiehlt sich der Einsatz von AWS Systems Manager Session Manager als SSH-Alternative, die ohne offene Port-22-Regeln auskommt und vollständig über IAM gesteuert wird.

Glossar

Begriff	Erklärung
Security Group	Zustandsbehaftete virtuelle Firewall auf EC2-Instanz-Ebene. Erlaubte Inbound-Verbindungen erzeugen automatisch den Rückkanal.
Network ACL (NACL)	Zustandslose Firewall auf Subnetz-Ebene. Inbound- und Outbound-Regeln werden unabhängig ausgewertet. Regeln werden nach Nummer aufsteigend geprüft.
Ephemeral Ports	Kurzlebige TCP-Ports (1024–65535), die das Betriebssystem für ausgehende Verbindungsantworten dynamisch zuweist. Müssen in NACL-Outbound-Regeln explizit erlaubt sein.
Internet Gateway (IGW)	Horizontaler VPC-Komponente, die öffentlich adressierbaren Instanzen den Internetzugang ermöglicht. Muss im Subnetz-Route-Table referenziert sein.
Elastic IP	Statische öffentliche IPv4-Adresse, die einem AWS-Konto zugewiesen und flexibel mit EC2-Instanzen oder Network Interfaces verknüpft werden kann.

Dieses Blog durchsuchen

SW BBANG D