Privaten SSH-RSA-Schlüssel im 1781AW tauschen klappt nicht

[timfriske]

Kann mir jemand von Euch weiterhelfen?

Ich versuche, den von Lancom Systems werkseitig installierten privaten SSH-RSA-1024-Schlüssel gegen einen privaten SSH-RSA-4096-Schlüssel zu tauschen. Die Public-Key-Authentication schlägt danach permanent fehl; auch nach einem Neustart des 1781AW über den Menüpfad "WEBConfig/Extras/Neustart".

Lokal nutze ich als Authentication Agent das "gpg-agent" Programm mit aktiviertem SSL-Agent-Protokoll (enable-ssh-support). Die Instanz des "gpg-agent" Programms kommuniziert korrekt, wenn ich mich bsp. mittels "ssh -T git@github.com" ohne Pseudo-TTY-Allokation verbinde.

Vorgehensweise

Den privaten SSH-RSA-4096-Schlüssel lade ich über den Menüpfad "WEBConfig / Dateimanagement / Zertifikat oder Datei hochladen" mit folgenden Formulareinträgen hoch:

• Dateityp: SSH - RSA Schlüssel (*.key [BASE64 unverschlüsselt])
• Dateiname: <Dateipfad zur hochzuladenden Datei, die den unverschlüsselten privaten SSH-RSA-4096-Schlüssel enthält.>
• Passphrase (falls benötigt): <leer, weil SSH-RSA-4096-Schlüssel unverschlüsselt.>

Das 1781AW quittiert das abgeschlossene Hochladen mit einer Erfolgsmeldung. Um sicher zu gehen, schaue ich mir den Fingerabdruck des SSH-RSA-Schlüssels unter dem Menüpfad "WEBConfig/Extras/Schlüssel-Fingerprints anzeigen" an: Der unter "ssh-rsa" angezeigte Fingerabdruck stimmt mit dem des hochgeladenen privaten SSH-RSA-4096-Schlüssels überein. Dennoch kann ich mich fortan nicht mehr per SSH anmelden. Ein Zurück zum werkseitig installierten SSH-RSA-1024-Schlüssel ist leider nach dem Wiederherstellen aus einer vollständigen Sicherungskopie der Konfiguration ("lancom.lcs") nicht möglich. Vermutlich, weil der SSH-RSA-Schlüssel nicht Teil der Sicherungskopie ist.

Den SSH-RSA-4096-Schlüssel erzeuge ich mit dem "ssh-keygen" Programm, das mit der Software OpenSSH in Version "OpenSSH_6.1p1, OpenSSL 1.0.1e-fips" installiert ist. Als Betriebssystem setze ich Fedora 18 x86_64 ein. Konkret habe ich den Befehl "ssh-keygen -t rsa -b 4096 -f hostkey" ausgeführt und bei der Aufforderung, den privaten Schlüssel mit einem Passwort zu schützen, dieses nicht gesetzt.

[alf29]

Moin,

Welche LCOS-Version wird eingesetzt?

Passiert das auch mit kuerzeren RSA-Schluesseln (2048 oder 1024 Bit)?

Was sagt ein SSH-Trace waehrend eines fehlgeschlagenen Verbindungsaufbaus?

Schluessel und Zertifikate sind in der Tast nicht Teil der normalen Konfiguration, sondern werden im Dateisystem abgelegt. Unter Status/Filesystem/contents auf der CLI oder dem LCOS-Menuebaum gibt es eine Tabelle, aus der man die Dateien wieder loeschen kann.

Gruss Alfred

[timfriske]

• Welche LCOS-Version wird eingesetzt?: LCOS 8.80 RU1
• Passiert das auch mit kuerzeren RSA-Schluesseln (2048 oder 1024 Bit)?: Ja, mit SSH-RSA-1024-Schlüssel getestet.
• Was sagt ein SSH-Trace waehrend eines fehlgeschlagenen Verbindungsaufbaus?: Reiche ich nach.

Leider ist der Austausch eines SSH-DSA-Schlüssels und SSH-RSA-Schlüssels weder im Lancom Referenz 8.6 Dokument, noch im Lancom Addendum 8.8 Dokument, noch in einem Lancom Knowledgebase Artikel beschrieben. Auch die sonstigen Optionen zur Konfiguration eines SSH Zugangs sind nur sehr spärlich im Lancom Addendum 8.8 Dokument beschrieben und zu den meisten ?-Hilfe-Knöpfen in WEBConfig fehlt deren Beschreibung. Da hätte ich von Lancom Systems mehr erwartet: Die sichere Verwendung von Funktionen steht und fällt nämlich mit deren Dokumentation.

[alf29]

Moin,

ich habe mir ein 1781EF genommen (ein AW habe ich gerade nicht da), es auf die 8.80RU1 geflasht, einen 4K-Schlüssel mit gleichem Kommando erzeugt (nur unter einer Debian 7.0), diesen in das Gerät mit einem

Code: Alles auswählen

scp <Key-Datei> root@<IP-Adresse>:ssh_rsakey

ins Gerät eingespielt. Ein Zugriff aufs Gerät per SSH mit einer OpenSSH vom gleichen Debian-Rechner aus oder von einem Windows-Rechner mit Putty war danach ohne Probleme möglich. Scheint mir also irgendeine Besonderheit mit Deinem SSH-Client zu sein -> SSH-Trace erforderlich.

Um die Antwort von heute morgen noch etwas zu präzisieren: ein auf dem Gerät installierter Schlüssel läßt sich auf der CLI mit dem Befehl

Code: Alles auswählen

del Status/File-System/Contents/ssh_rsakey

wieder löschen.

Leider ist der Austausch eines SSH-DSA-Schlüssels und SSH-RSA-Schlüssels weder im Lancom Referenz 8.6 Dokument, noch im Lancom Addendum 8.8 Dokument, noch in einem Lancom Knowledgebase Artikel beschrieben.

Der Upload von Dateien oder Zertifikaten an sich sollte schon beschrieben sein, und die SSH-Schlüssel gehören zu diesen Dateien...

Auch die sonstigen Optionen zur Konfiguration eines SSH Zugangs sind nur sehr spärlich im Lancom Addendum 8.8 Dokument beschrieben und zu den meisten ?-Hilfe-Knöpfen in WEBConfig fehlt deren Beschreibung. Da hätte ich von Lancom Systems mehr erwartet: Die sichere Verwendung von Funktionen steht und fällt nämlich mit deren Dokumentation.

Das Addendum selber ist erstmal genau das: eine Beschreibung der mit LCOS 8.80 neuen bzw. geänderten Dinge. Dinge, die schon länger drin sind, muß man im den älteren Addendums bzw. dem Referenzmanual selber nachschauen.

Generell muß man aber zugeben, daß im LANCOM-Management die Gerätekonfiguration sehr durch die LANtools-Brille gesehen. Kunden, die die CLI und/oder andere Betriebssysteme nutzen, werden eher als unter 'ferne liefen' betrachtet - leider...

Gruß Alfred

[timfriske]

Probleme gelöst. SSH-Authentifizierung funktioniert!

Ich denke, dass ich einen SSH-Trace nicht mehr nachreichen muss, weil ich mich doch mit einem selbst-generierten SSH-RSA-4096-Schlüssel am 1781AW per SSH anmelden kann.

Das Problem lag in der Vielzahl der Versuche mit unterschiedlichen SSH-Host-Schlüsseln und dem DNS-Namen des 1781AW, den ich zwischenzeitlich gewechselt habe. Außerdem habe ich während dessen auch mehrmals den als SSH-Agent agierenden GPG-Agent gestoppt und wieder gestartet.