Zyxel Speedlink 5501 IAD - Freischalten des ssh-Zugangs

Da die Deutsche Telekom nun auch unser Ortsnetz auf All-IP umstellt und die bestehenden ISDN-Verträge gekündigt hat, war Ersatz für den Thomson ST585v6, der bisher unsere ADSL2-Annex-J-Verbindung recht zuverlässig betrieb, fällig, da hier jetzt auch VDSL verfügbar ist.

Die Deutsche Telekom hat unter anderem den Zyxel (vormals Sphairon) Speedlink 5501 im Programm, ein Kombinationsgerät, das neben dem V/ADSL-Modem mit PPOE-Passthrough u.a. auch noch einen WLAN-AP, VOIP, eine Telefonanlage, einen S0-Bus zum Anschluß von ISDN-Geräten oder -Telefonanlagen, 2x100Mb und 2x1Gb LAN-Ports bietet.

Leider ist bei diesem Gerät im Auslieferungszustand der ssh-Zugang deaktiviert. Dank der Forschungen von Hanno Heinrichs ist jedoch das Format der Konfigurationsdateien für das Gerät bekannt, so daß sich der ssh-Zugang relativ leicht aktivieren läßt. Hanno hat allerdings nicht schrittweise beschrieben, wie das geht, daher mache ich das hier nun.

Das Folgende wurde getestet unter Debian GNU/Linux 'Stretch'; ich gehe hier nicht auf Voraussetzungen ein, wenn nötige Programme fehlen, ist aptitude Euer Freund.

Warnung: Dieses Howto fußt auf undokumentierten Funktionen, die sich mit jeder Firmwareänderung verändern können. Es ist möglich, daß Euer Device durch die hier beschriebene Methode 'gebrickt' wird oder auf andere Weise kaputt geht. YMMV/YHBW!. Weiterlesen auf eigene Gefahr!

Update April 2017: Versteckte Option in der Benutzeroberfläche

Daniel Steglich weist auf eine versteckte Option in der Benutzeroberfläche hin, mit der sich auf diesem Gerät ein Entwicklermodus freischalten läßt, der ebenfalls den ssh-Zugang aktiviert, direkt über das Webinterface des Routers. Da diese Funktion einfacher zu benutzen ist als die unten folgende Methode, muß ich hier auf sie hinweisen (Danke an S. G. für den Link!).

Kurz gefaßt: die versteckte Option liegt unter

/webng.cgi?sid=auto&controller=WebConfig&action=hiddenDevActivation

auf dem Speedlink, dort die Checkbox markieren, Save, dann den Resetbutton am Speedlink drücken, was als Sicherheitsfeature dient (worüber man ja auch unterschiedlicher Meinung sein kann). Ich habe diese Funktion nicht getestet, insbesondere nicht geprüft, ob durch ihre Aktivierung der ssh-Zugang auch WAN-seitig freigegeben wird (siehe unten). Dies solltet Ihr bei Nutzung dieser Methode aus Sicherheitsgründen unbedingt prüfen.

Alternativmethode: ssh-Zugang über die Konfigurationsdatei aktivieren

Über die Benutzeroberfläche, unter dem Eintrag System - Konfiguration sichern, laden wir uns die Konfiguration herunter. Sie landet als config.bin auf unserem Rechner.

Konfiguration extrahieren

Dazu muß der 72-Byte-Header entfernt werden. Wir überspringen 72 Byte und schreiben den Rest in eine neue Datei.

$ dd bs=4096 skip=72 iflag=skip_bytes if=config.bin of=config.tgz

Damit liegt die Konfiguration als komprimiertes tarball vor. Entweder durch Entpacken oder mit einem Dateimanager machen wir die Datei sql/persistent-network.db.sql ausfindig und öffnen sie in einem Editor (ich habe die kombinierte Entpack- und Edierfunktion in Brian Havards File Commander verwendet).

Konfiguration ändern

Wie bei Hanno beschrieben, muß die Konfiguration geändert werden.

Firewallregeln

Nur, wenn der ssh-Zugang auch von der WAN-Seite (aus dem Internet) erreichbar sein soll (Sicherheitsrisiko!), muß die Firewall für den Port 22 geöffnet werden.
Im Abschnitt FirewallRulesStatic sind eine Anzahl Regeln definiert. Bei mir hatte die letzte die ID 8, also müssen wir die Regel mit der ID 9 hinzufügen (das kann je nach Konfiguration anders sein, die ID ist der erste Wert in der Klammer). Die einzelnen Felder sind im Abschnitt, der den Regeln vorhergeht, erläutert.
Nebenbei gesagt: bei der Durchsicht der Regeln fällt auf, daß der Port 32767/tcp für alle Welt offen steht. Hier läuft ein gSOAP 2.7 Server. Das ist die Hintertür für die automatischen Konfigurationsupdates der Telekom; nach Abschalten derselben im GUI schließt sich der Zugang.
Durch Anpassen der bereits vorhandenen Regeln ließe sich diese Hintertür hier auch in der Firewall schließen; angesichts der möglichen Sicherheitsrisiken der Fernkonfiguration vielleicht überlegenswert.
Zurück zur Konfiguration: Eine Regel zur Öffnung der Firewall würde so lauten:

INSERT INTO "FirewallRulesStatic" VALUES(9,1,'IPv4','0.0.0.0','0.0.0.0',0,0,22,0,'TCP',4,'ACCEPT',1,'INCOMING',0,0,'system entry');

Wenn der ssh-Zugang nur aus dem LAN erreicht werden soll, ist die obenstehende Änderung nicht nötig.

Inbetriebnahme des ssh-Servers und Aktivierung des ssh-Nutzers

Nun muß der ssh-daemon aktiviert und ein Nutzer angelegt werden. Dazu suchen wir

INSERT INTO "SshConfiguration" VALUES(1,0,5,22,'',0);

und ändern dies in

INSERT INTO "SshConfiguration" VALUES(1,1,5,22,'',0);

Der Nutzer wird in der folgenden (zu suchenden) Zeile angelegt:

INSERT INTO "SshUser" VALUES(1,0,'admin','admin',0);

Sie wird so geändert:

INSERT INTO "SshUser" VALUES(1,1,'Nutzername','Passwort',1);

Dabei ändern wir Nutzernamen und Passwort in sinnvolle/sichere Werte. Der boolesche Wert nach dem Passwort steuert den Rootzugang.

Schließlich packen wir alles wieder in die .tgz-Datei.

Wiederzusammenbau

Nun muß die Konfigurationsdatei nach den von Hanno entdeckten Kriterien wieder zusammengebaut werden. Zuerst klauen wir uns den Anfang des Headers aus der Originaldatei (die ersten Bytes sind festgelegt, den Timestamp habe ich nicht neu berechnet):

$ dd if=config.bin bs=8 count=1 of=config.hdr

Dann fügen wir den SHA1-Hash der zuvor modifizierten .tgz-Datei hinzu:

$ openssl dgst -sha1 -binary config.tgz | cat >> config.hdr

Darauf folgen 12 Bytes Nullen:

$ dd if=/dev/zero bs=1 count=12 | cat >> config.hdr

Jetzt liegt der 40-Byte-Header vor, aus dem der zweite Hash erzeugt und an ihn angehängt werden kann:

$ openssl dgst -sha1 -binary config.hdr | cat >> config.hdr

Es folgen wieder 12 Bytes Nullen:

$ dd if=/dev/zero bs=1 count=12 | cat >> config.hdr

Jetzt sollte der Header 72 Byte groß sein. Wir hängen die .tgz-Datei hinten an.

$ cat config.tgz >> config.hdr

Nun räumen wir die Originaldatei weg, benennen config.hdr in config.bin um und laden diese Datei über das GUI auf den Router, der sich daraufhin neu startet.

Nun sollte der ssh-Zugang möglich sein; bei meinem ssh-client mußte ich allerdings noch einen veralteten Verschlüsselungsalgorithmus aktiveren, indem ich die Datei ~/.ssh/config mit dem Inhalt

Host $IP-Adresse-des-Speedlink
     HostkeyAlgorithms ssh-dss

erzeugt habe.

Zunächst begrüßt einen ein kaputter ASCII-Art-Splashscreen, aber nach dem Login landet man immerhin auf einem richtigen Linux und nicht auf einem dieser üblichen Router-Betriebssysteme.
Let the fun begin!

P.S.: Man kann das Ganze latürnich auch automatisieren. Ich war aber zu faul, ein 'richtiges' Skript mit Fehlerprüfung usw. zu schreiben, daher gibt es nur Batchfiles: zum Auspacken und zum Wiedereinpacken.