Sophos Firewall per SSH verbinden

Für viele Support- und Troubleshooting-Aufgaben benötigt man Zugriff auf die Sophos Firewall per SSH. Dazu gehören zum Beispiel Loganalysen, Service-Neustarts, spezielle Diagnosebefehle oder das Arbeiten in der Advanced Shell.

SSH ist aber auch ein Management-Zugang mit hohem Risiko. Der Zugriff sollte deshalb nur aus vertrauenswürdigen Admin-Netzen, über eine gezielte Local Service ACL Exception Rule oder über einen klar definierten Support-Zugang erlaubt werden. Für die allgemeine Härtung lokaler Firewall-Dienste passt zusätzlich Device Access richtig konfigurieren.

Voraussetzungen

Für eine SSH-Verbindung zur Sophos Firewall benötigt man:

• Administrativen Zugriff auf die Sophos Firewall.
• Die IP-Adresse oder den DNS-Namen der Firewall.
• Zugriff auf den Benutzer admin.
• Eine vertrauenswürdige Admin-Quelle, zum Beispiel Management-Netz, VPN oder feste Admin-IP.
• Auf macOS oder Linux: die vorinstallierte Terminal-App mit SSH.
• Auf Windows: Windows Terminal mit OpenSSH oder PuTTY.
• Erlaubten SSH-Zugriff unter Administration > Device access oder über eine Local service ACL exception rule.
• Bei geplanten Änderungen in der Advanced Shell: Backup, Wartungsfenster und klarer Rollback-Pfad.

⚠️ SSH sollte nur aus vertrauenswürdigen Netzen erlaubt werden. Für produktive Umgebungen ist es besser, den Zugriff auf eine Management-IP oder ein Admin-Netz zu beschränken, statt SSH allgemein freizugeben.

Vorher klären, wofür SSH benötigt wird

Nicht jede Analyse braucht die Advanced Shell. Vor dem Login sollte klar sein, welche Konsole benötigt wird und wie stark der Eingriff ist.

Typische Zuordnung:

• Routing, DNS, Ping und einfache Systembefehle: Dafür ist meistens die Device Console richtig. Diese Konsole nutzt die Sophos CLI und ist weniger riskant als die Advanced Shell.
• Logdateien lesen: Für tail, grep, less und direkte Loganalysen braucht man die Advanced Shell. Dabei sollte man nur lesen und keine Dateien ändern oder löschen.
• Service-Status oder Debug prüfen: Das gehört ebenfalls in die Advanced Shell. Debug sollte nur gezielt aktiviert und danach wieder deaktiviert werden.
• Unbekannte Befehle: Nicht im Produktivsystem ausprobieren. Besser zuerst prüfen, in einer Testumgebung nachvollziehen oder einen Supportfall eröffnen.

Die Unterscheidung ist wichtig, weil Device Console und Advanced Shell unterschiedliche Syntax verwenden. Viele Fehler entstehen nur dadurch, dass ein korrekter Befehl am falschen Ort eingegeben wird. Eine breitere Übersicht steht in Sophos Firewall Troubleshooting: Services und Logs.

SSH-Zugriff auf der Firewall erlauben

Damit eine Verbindung möglich ist, muss die Sophos Firewall SSH auf der passenden Zone oder über eine Local Service ACL Exception Rule erlauben.

1. Im Web Admin der Sophos Firewall anmelden.
2. Administration öffnen.
3. Device access auswählen.
4. Prüfen, ob SSH für die gewünschte Zone erlaubt ist.

Für interne Administrationsnetze kann SSH direkt für die passende Zone aktiviert werden, zum Beispiel für LAN. Wenn der Zugriff gezielter eingeschränkt werden soll, ist eine Local service ACL exception rule sinnvoll.

Device Access steuert Zugriff zur Firewall selbst. Das ist nicht dasselbe wie eine normale Firewall-Regel, die Traffic durch die Firewall erlaubt. Wenn SSH in Device Access zu breit aktiviert ist, erreicht ein Client den lokalen SSH-Dienst der Firewall unabhängig davon, ob eine klassische LAN-zu-WAN-Regel sauber gebaut ist.

Wichtig ist auch die Unterscheidung zwischen SSH und der webbasierten CLI Console: Für einen SSH-Client braucht man SSH-Zugriff auf TCP 22. Wenn man die CLI Console aus dem WebAdmin-Menü öffnet, muss dagegen HTTPS für die passende Zone erlaubt sein.

Bei einer ACL-Ausnahme sollten die Werte möglichst eng gesetzt werden:

• Rule position: Reihenfolge der Ausnahme in der Local Service ACL
• IP version: IPv4 oder IPv6 passend zur Admin-Quelle und Zieladresse
• Source zone: die Zone, aus der administriert wird
• Source Network / Host: die Admin-IP oder das Management-Netz
• Destination host: die Firewall-IP oder das Interface, das administriert werden soll, wenn der Zugriff zusätzlich auf eine konkrete Zieladresse eingeschränkt werden kann
• Services: SSH
• Action: Accept

SSH sollte nicht unkontrolliert aus dem Internet erreichbar sein. Wenn externer Zugriff notwendig ist, sollte dieser nur über eine klar definierte Quell-IP, VPN oder einen dedizierten Support-Zugang erlaubt werden.

Diagnostics > Support access ist ein separater Mechanismus. Dabei öffnet man nicht einfach SSH aus dem Internet, sondern erlaubt Sophos Support temporären Zugriff über einen von der Firewall aufgebauten Support-Kanal. Auch dieser Zugriff sollte zeitlich begrenzt und nach dem Supportfall wieder deaktiviert werden.

Beim Aktivieren von Support access wählt man eine Dauer, danach erzeugt die Firewall eine eindeutige Access ID für Sophos Support. Sophos Support kann damit auf WebAdmin und Shell zugreifen, ohne normale Admin-Zugangsdaten zu benötigen. Die Firewall baut die Verbindung zu Sophos Support selbst über TCP 22 auf; das ist betrieblich etwas anderes als eine eingehende SSH-Freigabe aus dem WAN.

Public Key für admin hinterlegen

Für SSH-Zugriffe ist die Authentifizierung mit einem Public Key die bevorzugte Methode. Auf der Sophos Firewall kann der Public Key für den Benutzer admin unter Administration > Device access hinterlegt werden. Passwort-Login kann für Notfälle notwendig sein, sollte aber nicht der bequemste Standardzugang bleiben.

⚠️ Eine SSH-Anmeldung an der Sophos Firewall ist nur mit dem Benutzer admin möglich. Andere WebAdmin-Benutzer können sich nicht per SSH anmelden.

Wichtig: Nur der Default-Admin kann die Public-Key-Authentifizierung für SSH ändern, also Keys hinzufügen oder entfernen. Für den Betrieb heisst das: Key-Änderungen gehören in einen dokumentierten Admin-Prozess und sollten nicht als spontane Supportabkürzung behandelt werden.

Der Default-Admin ist kein normales Rollen-Konto, das man beliebig ersetzt. Sophos weist darauf hin, dass dieses Konto nicht umbenannt oder gelöscht werden kann. Deshalb gehören Default-Admin-Passwort, MFA-/Recovery-Informationen für interaktive Admin-Anmeldungen und die hinterlegten SSH Public Keys gemeinsam in den Admin-Betriebsprozess. Ein Public Key ersetzt keine saubere Kontrolle über dieses Konto.

Der Public Key wird im Bereich Public key authentication for admin hinzugefügt:

1. Administration öffnen.
2. Device access auswählen.
3. Zum Bereich Public key authentication for admin scrollen.
4. Enable authentication aktivieren.
5. Den Public Key unter Authorized keys hinzufügen.
6. Mit Apply speichern.

Der private Schlüssel bleibt immer auf dem Admin-Client und darf nicht weitergegeben werden. Auf der Firewall wird nur der Public Key hinterlegt.

Wenn mehrere Admins SSH nutzen, sollte nicht derselbe private Schlüssel geteilt werden. Besser sind getrennte Admin-Clients, dokumentierte Public Keys und ein Review, welche Schlüssel noch benötigt werden. Nach Personalwechseln oder Dienstleisterwechseln sollte der Bereich Authorized keys geprüft werden.

Unterstützte SSH-Key-Typen

Nicht jeder moderne SSH-Key-Typ ist auf Sophos Firewall gleich geeignet. Vor dem Rollout sollte man prüfen, ob der Schlüsseltyp unterstützt wird.

Wichtige Einordnung der Key-Typen:

• RSA: Mindestens 2048 Bit verwenden.
• DSA: Nur verwenden, wenn es aus Kompatibilitätsgründen nötig ist; dann ebenfalls mindestens 2048 Bit.
• ECDSA: Wird unterstützt. Wichtig ist nur, ECDSA nicht mit ED25519 zu verwechseln.
• ED25519: Für die SSH Public Key Authentication auf Sophos Firewall nicht verwenden, weil dieser Key-Typ für diesen Zweck nicht akzeptiert wird.

Für neue Admin-Zugänge ist ein sauber verwalteter RSA- oder unterstützter ECDSA-Key meist pragmatischer als ein moderner Key-Typ, den die Firewall oder ein älteres SSH-Tool nicht akzeptiert.

Verbindung mit macOS oder Linux herstellen

Auf macOS und Linux ist ein SSH-Client normalerweise bereits vorhanden. Die Verbindung wird im Terminal hergestellt.

Beispiel:

ssh admin@192.0.2.1

Dabei wird 192.0.2.1 durch die IP-Adresse oder den DNS-Namen der eigenen Sophos Firewall ersetzt.

Beim ersten Verbindungsaufbau fragt der SSH-Client, ob der Fingerprint des Zielsystems akzeptiert werden soll. Dieser Fingerprint sollte geprüft und anschliessend bestätigt werden.

Wenn nach einem Reimage, Hardwaretausch oder IP-Wechsel eine Warnung zu einem geänderten Host Key erscheint, sollte der neue Fingerprint nicht blind akzeptiert werden. Zuerst prüfen, ob wirklich dieselbe Firewall ersetzt, neu installiert oder auf eine neue IP verschoben wurde. Erst danach kann der alte Eintrag in ~/.ssh/known_hosts bereinigt und der neue Fingerprint angenommen werden.

Danach wird je nach Konfiguration das Passwort des Benutzers admin abgefragt oder die Anmeldung über den hinterlegten SSH-Key durchgeführt.

Wenn ein bestimmter private Key verwendet werden soll:

ssh -i ~/.ssh/sophos-admin-key admin@192.0.2.1

Für wiederkehrende Zugriffe sollte der Key-Pfad, die erlaubte Quell-IP und der Zweck dokumentiert werden. Der known_hosts-Eintrag gehört nicht in Tickets oder Chatverläufe kopiert; bei Host-Key-Warnungen ist die Änderungshistorie wichtiger als ein schneller Workaround.

Verbindung mit PuTTY herstellen

Unter Windows kann man entweder Windows Terminal mit OpenSSH verwenden oder PuTTY einsetzen.

Mit Windows Terminal funktioniert der Verbindungsaufbau ähnlich wie unter macOS oder Linux:

ssh admin@192.0.2.1

Für PuTTY:

1. PuTTY öffnen.
2. Unter Host Name die IP-Adresse oder den DNS-Namen der Sophos Firewall eintragen.
3. Port auf 22 setzen.
4. Connection type auf SSH stellen.
5. Mit Open verbinden.
6. Den SSH-Fingerprint prüfen und bestätigen.
7. Als Benutzer admin anmelden und je nach Konfiguration Passwort oder SSH-Key verwenden.

Nach dem Login erscheint das Konsolenmenü der Sophos Firewall.

Wenn PuTTY mit einem privaten Schlüssel genutzt wird, muss der Key zum hinterlegten Public Key auf der Firewall passen. Nach einem Personal- oder Dienstleisterwechsel sollte nicht nur das Passwort geändert werden; alte Public Keys müssen ebenfalls aus Authorized keys entfernt werden.

Device Console oder Advanced Shell öffnen

Nach erfolgreicher Anmeldung per SSH zeigt die Firewall ein Konsolenmenü. Welche Option gewählt wird, hängt davon ab, was man erledigen möchte.

Für viele SFOS Befehle verwendet man:

4. Device Console

Für tiefere Linux- oder Dateisystem-Aufgaben verwendet man die Advanced Shell über:

5. Device Management
3. Advanced Shell

Die Advanced Shell bietet sehr weitreichenden Zugriff auf das System. Befehle sollten dort nur ausgeführt werden, wenn klar ist, was sie bewirken.

Typische Beispiele:

• Device Console: ping, dnslookup, traceroute, show, Routing- oder Systemoptionen.
• Advanced Shell: /log lesen, tail -f, grep, less, service -S oder Debug-Logs prüfen.

Für Loganalyse, Dienstnamen und typische Fehlerbilder ist Sophos Firewall Troubleshooting: Services und Logs der bessere Startpunkt als einzelne Befehle auswendig zu übernehmen.

Verbindung beenden

Wenn die Arbeiten abgeschlossen sind, sollte die SSH-Sitzung sauber beendet werden:

exit

Falls man sich in einem Untermenü befindet, kann es nötig sein, zuerst zurück ins Hauptmenü zu wechseln und die Sitzung danach zu beenden.

Sophos Firewall beendet inaktive SSH-Sitzungen nach 15 Minuten. Das ist kein Ersatz für sauberes Abmelden: Offene Sitzungen, Debug-Modi und temporäre Freigaben sollten trotzdem bewusst geschlossen beziehungsweise zurückgebaut werden.

Wenn SSH nur temporär für einen Supportfall aktiviert wurde, sollte die Freigabe danach wieder entfernt oder deaktiviert werden. Das gilt besonders für ACL-Ausnahmen, die von externen Quell-IP-Adressen oder Dienstleisterzugängen stammen.

Nach tiefen Eingriffen sollte zusätzlich geprüft werden:

• Ist Debug wieder deaktiviert?
• Wurde eine temporäre ACL Exception Rule entfernt oder deaktiviert?
• Sind keine temporären Dateien, Support-Dumps oder Mitschnitte unnötig auf der Firewall liegen geblieben?
• Sind Logauszüge, Uhrzeit, Befehl und Ergebnis im Ticket oder Change dokumentiert?
• Wurde der SSH-Key nur für den geplanten Admin- oder Supportzugang verwendet?

Häufige Probleme

Verbindung wird abgelehnt

Wenn die Verbindung abgelehnt wird, ist SSH auf der Firewall meistens nicht für die gewählte Zone oder Quelle erlaubt. In diesem Fall sollte Administration > Device access geprüft werden. Zusätzlich kontrollieren, ob eine ACL Exception Rule die Quelle erlaubt oder ob eine breitere Device-Access-Freigabe bewusst entfernt wurde.

Verbindung läuft in einen Timeout

Ein Timeout deutet oft darauf hin, dass die Firewall über die gewählte IP-Adresse nicht erreichbar ist, eine Route fehlt oder eine vorgelagerte Firewall den Zugriff blockiert.

Kein Netzwerkzugang zur Firewall

Wenn weder WebAdmin noch SSH erreichbar sind, sollte man nicht hektisch weitere WAN- oder Zonenfreigaben setzen. Der sauberere Rückfallweg ist lokaler Console-Zugriff am Gerät, zum Beispiel per Console-Kabel oder bei unterstützten Modellen per Micro-USB. Das ist besonders wichtig, wenn Device Access, Routing oder Interface-Zonen falsch gesetzt wurden.

Anmeldung schlägt fehl

Wenn die Anmeldung fehlschlägt, sollten der Benutzer admin, das Passwort beziehungsweise der SSH-Key und die erlaubten Quellnetze geprüft werden. Typische Meldungen wie Permission denied (publickey,password) deuten auf ein falsches Passwort, einen nicht passenden privaten Schlüssel oder fehlende Public-Key-Konfiguration hin.

Wenn Public-Key-Login fehlschlägt, zusätzlich Key-Typ, Key-Länge, falschen privaten Schlüssel, PuTTY-Keyformat und den Eintrag unter Authorized keys prüfen. Ein korrekt erlaubter SSH-Dienst hilft nicht, wenn der Schlüssel nicht zum hinterlegten Public Key passt.

Host-Key-Warnung erscheint

Eine Host-Key-Warnung kann harmlos sein, wenn eine Firewall neu installiert oder ersetzt wurde. Die Warnung kann aber auch auf ein falsches Zielsystem oder eine IP-Adressverwechslung hinweisen. Deshalb zuerst Firewall, IP-Adresse, DNS und Änderungshistorie prüfen. Erst danach sollte der alte known_hosts Eintrag entfernt werden.

Falsche Konsole geöffnet

Wenn ein Befehl nicht erkannt wird, ist häufig die falsche Konsole geöffnet. Befehle wie system ... gehören oft in die Device Console. Dateisystem- und Logbefehle wie tail, grep, less oder service -S gehören in die Advanced Shell.

Betriebscheckliste

• SSH nur aus vertrauenswürdigen Admin-Quellen erlauben.
• Wenn möglich Local Service ACL Exception Rule statt breiter Zonenfreigabe verwenden.
• Public Key Authentication für admin bevorzugen.
• Default-Admin-Passwort, MFA-/Recovery-Informationen und SSH-Keys getrennt dokumentieren.
• Unterstützten Key-Typ verwenden und Key-Länge dokumentieren.
• Private Keys nicht teilen.
• SSH-Fingerprint beim ersten Login prüfen.
• Host-Key-Warnungen nach Reimage oder Hardwaretausch bewusst behandeln.
• Device Console und Advanced Shell nicht verwechseln.
• Änderungen in der Advanced Shell nur mit klarem Zweck ausführen.
• Temporäre SSH-Freigaben nach Supportfällen wieder entfernen.
• Alte Public Keys nach Personal- oder Dienstleisterwechsel löschen.

FAQ