Firewall oder Fehlkonfiguration? So lösen Sie Verbindungsprobleme über Port 22 von einem AVD Rechner

Die Verwaltung von Servern, insbesondere Linux-Systemen, erfolgt oft über das Secure Shell (SSH)-Protokoll auf Port 22. Wenn Sie jedoch versuchen, von einem Azure Virtual Desktop (AVD)-Rechner aus eine Verbindung zu einem entfernten Server über Port 22 herzustellen und scheitern, kann das frustrierend sein. Die Ursachen hierfür sind vielfältig, doch die häufigsten Verdächtigen sind entweder eine restriktive Firewall oder eine subtile Fehlkonfiguration. Dieser Artikel bietet Ihnen eine umfassende, detaillierte und systematische Anleitung, um diese Verbindungsprobleme zu diagnostizieren und erfolgreich zu beheben.

### Warum Port 22 so wichtig ist und seine Herausforderungen im AVD-Kontext

Port 22 ist der Standardport für SSH, das Rückgrat für die sichere Fernverwaltung von Servern, das Dateiübertragungen (SFTP) und Tunneling ermöglicht. Für Systemadministratoren, Entwickler oder Data Scientists, die auf entfernte Linux-VMs zugreifen müssen, ist eine funktionierende SSH-Verbindung unerlässlich.

Im Kontext von Azure Virtual Desktop (AVD) werden die Dinge jedoch etwas komplexer. Ein AVD-Rechner ist selbst eine virtuelle Maschine, die in Azure gehostet wird. Das bedeutet, dass die Netzwerkkommunikation nicht nur die Pfade zum Zielserver, sondern auch die spezifische Netzwerkarchitektur und Sicherheitskontrollen von AVD und Azure durchlaufen muss. Dies kann zusätzliche Schichten für potenzielle Problemquellen hinzufügen, die bei einem herkömmlichen Client-Server-Setup nicht vorhanden wären.

Typische Symptome eines fehlgeschlagenen Verbindungsversuchs über Port 22 sind:
* `Connection timed out` (Verbindung Zeitüberschreitung)
* `Connection refused` (Verbindung abgelehnt)
* `No route to host` (Keine Route zum Host)
* Der SSH-Client hängt und zeigt keine Ausgabe.

Jedes dieser Symptome kann auf eine spezifische Art von Problem hindeuten, sei es eine blockierende Firewall, ein nicht erreichbarer Host oder ein inaktiver SSH-Dienst.

### Die Firewall als Verdächtiger: Wo könnte der Zugriff blockiert werden?

Firewalls sind wesentliche Sicherheitskomponenten, die den Netzwerkverkehr filtern und unerwünschte Zugriffe verhindern sollen. Sie können jedoch auch versehentlich legitime Verbindungen blockieren. Im Falle von AVD und Port 22 gibt es mehrere Stellen, an denen eine Firewall den Zugriff verhindern könnte:

#### 1. Azure Network Security Groups (NSGs)
NSGs sind die primäre Methode in Azure, um den Netzwerkverkehr zu und von Azure-Ressourcen zu filtern. Sie können auf Subnetzen oder einzelnen Netzwerkschnittstellen angewendet werden.
* **NSG des AVD Host-Pool Subnetzes**: Wenn Ihr AVD-Rechner in einem Subnetz betrieben wird, das eine NSG mit restriktiven Ausgangsregeln (Outbound Rules) besitzt, könnte diese den SSH-Verkehr zu Port 22 blockieren. Stellen Sie sicher, dass eine Regel existiert, die ausgehenden TCP-Verkehr auf Port 22 zum Zielserver (oder zu allen Zielen, wenn breit erforderlich) erlaubt.
* **NSG des Zielserver Subnetzes**: Dies ist der häufigste Ort für Blockaden. Der Zielserver, zu dem Sie sich verbinden möchten, befindet sich wahrscheinlich in einem eigenen Subnetz. Die dort angewendete NSG muss eine eingehende Regel (Inbound Rule) haben, die TCP-Verkehr auf Port 22 von der Quell-IP-Adresse Ihres AVD-Rechners (oder dem gesamten AVD-Subnetz, oder einer spezifischen JIT-IP) zulässt.

#### 2. Azure Firewall oder NVA (Network Virtual Appliance)
Wenn Ihre Azure-Infrastruktur komplexer ist und einen zentralen Firewall-Dienst wie die Azure Firewall oder eine Drittanbieter-Netzwerkvirtualisierungslösung (NVA) nutzt, muss auch dort eine Regel definiert sein, die den SSH-Verkehr von Ihrem AVD-Netzwerk zum Zielserver zulässt. Diese Firewalls arbeiten auf einer höheren Ebene als NSGs und können auch URL- oder FQDN-basierte Regeln umfassen, obwohl dies für SSH auf Port 22 weniger relevant ist.

#### 3. User Defined Routes (UDRs)
UDRs beeinflussen das Routing des Netzwerkverkehrs. Wenn eine UDR den Traffic über ein NVA leitet, das keine entsprechende Firewall-Regel hat, kann die Verbindung scheitern, selbst wenn die NSGs korrekt konfiguriert sind. Prüfen Sie, ob der Datenverkehr zum Zielserver korrekt geroutet wird.

#### 4. Betriebssystem-Firewall des Zielservers
Jeder Server, ob Linux oder Windows (oft nur unter Linux für SSH), verfügt über eine eigene softwarebasierte Firewall, die den eingehenden Verkehr filtern kann.
* **Linux (Zielserver)**: Programme wie `iptables` oder `firewalld` (bei RedHat/CentOS-basierten Systemen) können Port 22 blockieren.
* **Überprüfung mit `iptables`**: `sudo iptables -L -n | grep 22`
* **Überprüfung mit `firewalld`**: `sudo firewall-cmd –list-all` oder `sudo firewall-cmd –zone=public –list-ports`
Stellen Sie sicher, dass Port 22 in der entsprechenden Zone (z.B. `public`) für TCP-Verbindungen geöffnet ist.

#### 5. Corporate Firewall (On-Premises oder Hybrid Cloud)
Wenn der Zielserver nicht in Azure, sondern in einem On-Premises-Netzwerk steht und über eine VPN-Verbindung (Site-to-Site oder Point-to-Site) oder Azure ExpressRoute mit Azure verbunden ist, muss auch die physische Firewall in Ihrem Rechenzentrum eine Regel haben, die den eingehenden SSH-Verkehr von Ihrem Azure-VNet (wo sich der AVD-Rechner befindet) auf Port 22 zulässt.

### Fehlkonfiguration als Ursache: Wenn alles andere scheitert

Nachdem Sie die Firewall-Regeln an allen relevanten Stellen sorgfältig überprüft und eventuell angepasst haben, aber immer noch keine Verbindung herstellen können, ist es an der Zeit, sich auf mögliche Fehlkonfigurationen zu konzentrieren.

#### 1. SSH-Dienst auf dem Zielserver
Der SSH-Dienst (`sshd`) muss auf dem Zielserver laufen und korrekt konfiguriert sein, um Verbindungen anzunehmen.
* **Dienststatus prüfen**: Auf Linux-Systemen können Sie den Status des SSH-Dienstes mit `sudo systemctl status sshd` (für systemd-basierte Systeme) oder `sudo service ssh status` (für ältere Systeme) überprüfen.
* **Port prüfen**: Stellen Sie sicher, dass der SSH-Dienst tatsächlich auf Port 22 lauscht (oder einem anderen Port, wenn er konfiguriert wurde). Dies können Sie mit `sudo ss -tulpn | grep sshd` oder `sudo netstat -tulpn | grep sshd` überprüfen.
* **Konfigurationsdatei**: Überprüfen Sie die SSH-Konfigurationsdatei, normalerweise unter `/etc/ssh/sshd_config`. Suchen Sie nach der Zeile `Port 22` und stellen Sie sicher, dass sie nicht auskommentiert ist (kein `#` davor). Achten Sie auch auf die Einstellung `ListenAddress`, die möglicherweise nur auf eine bestimmte IP-Adresse festgelegt ist, die von Ihrem AVD-Rechner nicht erreichbar ist. Nach Änderungen an `sshd_config` muss der SSH-Dienst neu gestartet werden: `sudo systemctl restart sshd`.

#### 2. IP-Adressen und DNS-Auflösung
Eine scheinbar triviale, aber häufige Ursache für Verbindungsprobleme ist die falsche Ziel-IP-Adresse oder ein DNS-Problem.
* **Korrekte IP-Adresse/Hostname**: Stellen Sie sicher, dass Sie die richtige öffentliche oder private IP-Adresse bzw. den korrekten Hostnamen des Zielservers verwenden.
* **DNS-Auflösung vom AVD-Rechner**: Verwenden Sie `nslookup` oder `dig` auf Ihrem AVD-Rechner, um zu prüfen, ob der Hostname des Zielservers korrekt in eine IP-Adresse aufgelöst wird. Wenn der Zielserver eine private IP in Azure hat und der AVD-Rechner sich im selben VNet (oder einem gepeerten VNet) befindet, sollte die private IP verwendet werden.

#### 3. Netzwerkkonnektivität (Routing)
Bevor Sie sich um SSH kümmern, sollten Sie die grundlegende Netzwerkkonnektivität prüfen.
* **Ping**: Versuchen Sie, den Zielserver vom AVD-Rechner aus anzupingen (`ping `). Beachten Sie, dass ICMP (Ping) von Firewalls oft blockiert wird, sodass ein fehlgeschlagener Ping nicht unbedingt ein Problem mit der Route bedeutet, aber ein erfolgreicher Ping grundlegende Erreichbarkeit bestätigt.
* **Traceroute**: Verwenden Sie `tracert ` (Windows/AVD) oder `traceroute ` (Linux), um den Pfad zu verfolgen und festzustellen, wo der Datenverkehr möglicherweise stecken bleibt. Dies kann Hinweise auf fehlende Routen oder blockierende Router/Firewalls geben.

#### 4. SSH-Client-Konfiguration auf dem AVD-Rechner
Der Client, den Sie auf dem AVD-Rechner verwenden, muss ebenfalls korrekt konfiguriert sein.
* **Korrekter SSH-Befehl**: Stellen Sie sicher, dass Sie den korrekten SSH-Befehl verwenden, z.B. `ssh benutzername@zielserver-ip -p 22` (wobei `-p 22` oft weggelassen werden kann, da es der Standard ist).
* **SSH-Schlüssel**: Wenn Sie schlüsselbasierte Authentifizierung verwenden, stellen Sie sicher, dass der private Schlüssel auf Ihrem AVD-Rechner korrekt gespeichert ist (typischerweise unter `~/.ssh/id_rsa` auf Linux/WSL oder in PuTTY/MobaXterm bei Windows-Clients) und die richtigen Berechtigungen hat. Prüfen Sie auch, ob der entsprechende öffentliche Schlüssel auf dem Zielserver in der Datei `~/.ssh/authorized_keys` des Zielbenutzers vorhanden ist.
* **SSH-Agent**: Wenn Sie einen SSH-Agent verwenden, stellen Sie sicher, dass der private Schlüssel dem Agenten hinzugefügt wurde.

#### 5. Anmeldeinformationen und Berechtigungen
Auch wenn die Verbindung hergestellt wird, können falsche Anmeldeinformationen oder fehlende Berechtigungen dazu führen, dass der Login fehlschlägt.
* **Benutzername**: Verwenden Sie den korrekten Benutzernamen für den Zielserver.
* **Passwort/Schlüsselphrase**: Stellen Sie sicher, dass das Passwort oder die Schlüsselphrase für den privaten Schlüssel korrekt ist.
* **Benutzerberechtigungen auf dem Zielserver**: Der verwendete Benutzer muss die Berechtigung haben, sich über SSH anzumelden. Prüfen Sie dies in der `sshd_config` des Zielservers (z.B. `AllowUsers`, `DenyUsers`, `AllowGroups`, `DenyGroups`).

### Systematisches Troubleshooting: Ein Schritt-für-Schritt-Ansatz

Ein strukturierter Ansatz ist der Schlüssel zur schnellen Problemlösung.

1. **Schritt 1: Problemdefinition und Symptome sammeln.**
* Was genau passiert? Welche Fehlermeldung erhalten Sie?
* Gibt es andere Benutzer, die sich anmelden können? Von anderen Rechnern?
* Wann trat das Problem zuletzt auf? Gab es Änderungen?

2. **Schritt 2: Einfache Konnektivität prüfen (vom AVD-Rechner zum Zielserver).**
* `ping `: Ist der Host überhaupt erreichbar (falls ICMP erlaubt)?
* `tracert `: Wo stoppt der Pfad? Gibt es Netzwerkgeräte, die den Traffic blockieren?
* `telnet 22` oder `nc -vz 22`: Zeigt dies `Connected to…` oder `Connection refused/timed out`? Wenn `Connection refused`, ist der Dienst wahrscheinlich nicht aktiv oder eine lokale Firewall blockiert. Wenn `Connection timed out`, blockiert wahrscheinlich eine Netzwerk-Firewall oder der Host ist nicht erreichbar.

3. **Schritt 3: SSH-Dienststatus auf dem Zielserver prüfen.**
* Melden Sie sich *direkt* am Zielserver an (z.B. über die Azure Serial Console oder eine andere Methode) und prüfen Sie:
* `sudo systemctl status sshd`
* `sudo ss -tulpn | grep 22` (lauscht er auf Port 22?)
* Überprüfen Sie `/etc/ssh/sshd_config` auf ungewöhnliche Einstellungen.

4. **Schritt 4: Lokale Firewall des Zielservers prüfen.**
* Überprüfen Sie `iptables` oder `firewalld` auf dem Zielserver. Ist Port 22 für eingehenden TCP-Verkehr geöffnet?
* Testen Sie dies, indem Sie die Firewall temporär deaktivieren (z.B. `sudo systemctl stop firewalld`) und erneut versuchen, sich vom AVD-Rechner zu verbinden. *Achtung: Dies ist ein Sicherheitsrisiko und sollte nur für Tests und nur in sicheren Umgebungen erfolgen!*

5. **Schritt 5: Azure/Netzwerk-Firewalls (NSGs, Azure Firewall) prüfen.**
* **NSG des Zielserver-Subnetzes**: Prüfen Sie die eingehenden Regeln. Erlaubt sie Port 22 von der Quell-IP des AVD-Rechners oder des AVD-Subnetzes?
* **NSG des AVD-Subnetzes**: Prüfen Sie die ausgehenden Regeln. Erlaubt sie Port 22 zum Zielserver?
* **Azure Firewall / NVA**: Wenn in Ihrer Umgebung vorhanden, prüfen Sie deren Regeln.

6. **Schritt 6: Client-Konfiguration (SSH-Befehl, Schlüssel) vom AVD-Rechner prüfen.**
* Stimmen Benutzername, IP-Adresse und ggf. Port im SSH-Befehl?
* Sind die SSH-Schlüssel korrekt konfiguriert und haben sie die richtigen Berechtigungen? (`chmod 400 ~/.ssh/id_rsa` auf Linux/WSL).
* Verwenden Sie den `ssh -v` Befehl für detaillierte Debug-Ausgaben.

7. **Schritt 7: Protokolle analysieren.**
* **Zielserver**: Überprüfen Sie die SSH-Logs auf dem Zielserver (z.B. `/var/log/auth.log` oder `/var/log/secure` auf Linux) auf Fehlermeldungen bei Verbindungsversuchen.
* **AVD-Rechner**: Client-seitige Logs können auch Hinweise geben, insbesondere bei schlüsselbasierten Authentifizierungsproblemen.

8. **Schritt 8: Isolationstest.**
* Versuchen Sie, sich von einem *anderen* Rechner (nicht AVD, falls verfügbar) zu dem Zielserver zu verbinden. Funktioniert es? Dies hilft festzustellen, ob das Problem spezifisch für den AVD-Rechner oder den Zielserver ist.
* Versuchen Sie, sich vom AVD-Rechner zu einem *anderen* Port (z.B. einem Webserver auf Port 80) auf dem Zielserver zu verbinden, um die grundlegende Netzwerkkonnektivität zu prüfen.

### Best Practices zur Vermeidung von Problemen

Um zukünftige Verbindungsprobleme zu minimieren, sollten Sie folgende Best Practices implementieren:

* **Dokumentation**: Führen Sie eine detaillierte Dokumentation Ihrer Netzwerkarchitektur, einschließlich aller NSG-Regeln, Azure Firewall-Konfigurationen und Server-Firewall-Einstellungen.
* **Automatisierung (Infrastructure as Code)**: Nutzen Sie Tools wie Azure Bicep oder Terraform, um Ihre Infrastruktur, einschließlich der Netzwerksicherheitsgruppen, zu definieren und bereitzustellen. Dies gewährleistet Konsistenz und Nachvollziehbarkeit.
* **Principle of Least Privilege**: Öffnen Sie nur die Ports und IP-Adressen, die unbedingt erforderlich sind. Verwenden Sie Just-in-Time (JIT) VM-Zugriff für SSH, um den Port 22 nur bei Bedarf und für eine begrenzte Zeit zu öffnen.
* **Überwachung und Protokollierung**: Konfigurieren Sie Azure Monitor und Log Analytics, um Netzwerk-Flow-Logs von NSGs und System-Logs von Ihren VMs zu sammeln. Dies hilft bei der schnellen Erkennung und Analyse von Problemen.
* **Regelmäßige Audits**: Überprüfen Sie regelmäßig Ihre Firewall-Regeln, um sicherzustellen, dass sie noch aktuell und notwendig sind.

### Fazit

Die Diagnose von Port 22 Problemen von einem AVD-Rechner kann eine Herausforderung sein, da sie eine Vielzahl von Schichten – vom Client über die Azure-Netzwerkinfrastruktur bis zum Zielserver – umfasst. Durch einen systematischen Ansatz, der sowohl Firewall-Regeln als auch Konfigurationsdetails sorgfältig überprüft, können die meisten Probleme jedoch schnell identifiziert und behoben werden. Denken Sie daran, dass Netzwerksicherheit und korrekte Konfiguration Hand in Hand gehen, um eine reibungslose und sichere Kommunikation zu gewährleisten. Mit den hier vorgestellten Schritten sind Sie gut gerüstet, um das Rätsel um Ihre SSH-Verbindungsprobleme ein für alle Mal zu lösen.