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.

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 März 2021(war: April 2017): Versteckte Option in der Benutzeroberfläche

Es existiert (Update September 2020: Der Originallink zur dieser Methode ist leider nicht mehr zugänglich) auch eine versteckte Option in der Benutzeroberfläche, mit der sich auf diesem Gerät ein Entwicklermodus freischalten läßt, der ebenfalls den ssh-Zugang aktiviert, direkt über das Webinterface des Routers.

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 (bis die Power-LED rot wird). Wenn nach Neuladen der Benutzeroberfäche oben Ansicht: ENTWICKLER steht, hat das geklappt.

In dieser Ansicht gibt es einige vorher versteckte Menüeinträge zu sehen, unter anderem unter System den Eintrag SSH. Dort könnt Ihr Nutzer eintragen, Rechte definieren und auch einstellen, ob der SSH-Zugang übers WAN-Interface aktiv sein und damit von außen erreichbar sein soll (womit ich sehr vorsichtig wäre).

Damit könnt Ihr Euch dann über ssh einloggen. Falls Ihr dabei die Meldung

no matching host key type found. Their offer: ssh-dss

bekommt, hilft die Option

ssh -oHostKeyAlgorithms=+ssh-dss

Nun sollte der ssh-Zugang möglich sein; um den (veralteten) Verschlüsselungsalgorithmus auf Dauer zu konfigurieren, die Datei ~/.ssh/config mit dem Inhalt

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

erzeugen.

So habt Ihr Zugriff auf das Linux, was auf dem Speedlink läuft (und sogar die ASCII-Art wurde gefixt :-) ). Aber: hic sunt leones. Ihr könnt jetzt alles konfigurieren und damit auch alles kaputtmachen. Ein vorheriges Backup der funktionierenden Einstellungen sollte selbstverständlich sein, so wie auch der Grundsatz, Änderungen nur vorzunehmen, wenn klar ist, was sie bewirken.

Alles, was folgt, ist nur noch von hiostorischem Interesse!

Alternativmethode (deprecated): ssh-Zugang über die Konfigurationsdatei aktivieren

Dank der Forschungen von Hanno Heinrichs ist 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' und neuere Versionen; ich gehe hier nicht auf Voraussetzungen ein, wenn nötige Programme fehlen, ist aptitude Euer Freund.

Ü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 (nicht mehr 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.