SFTP

Moin,

bin ein angehender Umsteiger von der Reelbox AVG2, noch am rumspielen, um ein für mich geeignetes Setup zu finden und vermißte die Möglichkeit, die Box für Kleinkram mal schnell per sshfs mounten zu können. Hab deshalb die Pakete gestern testweise auf meiner Duo 4K SE mit aktuellem VTi 15.0.2 installiert.

Zunächst lief danach der sshd, nach einem Neustart gab es aber wieder nur den dropbear. Hab mir daraufhin das postinst-Script mal angeschaut und denke, das hatte in meinem Setup ein paar Probleme:

• Es gab kein "update-rc.d", deshalb wurden die Links für den sshd in rcX.d nicht angelegt. Das Paket existiert aber, ich konnte das per "opkg install update-rc.d" auf die Box bringen und die Links nachträglich manuell erzeugen. Vielleicht könnte das Paket also in die Depends mit rein oder gibt es dann Probleme mit anderen Boxen/Image-Versionen?
  
• Es gab trotz laufendem dropbear keine "/var/run/dropbear.pid", so daß der dropbear nicht beendet wurde und gar nicht erst versucht wurde, dessen rcX.d-Links zu löschen (und warum gibt es eigentlich für die Existenz von "update-rc.d" oben eine Abfrage und hier nicht mehr?)
  
• Selbst wenn die PID so gefunden worden wäre, hätte der "update-rc.d ... remove"-Befehl wahrscheinlich nicht funktioniert, da /etc/init.d/dropbear weiterhin existiert und deshalb der Parameter "-f" mit an den Befehl gemußt hätte
  

Eine kleine Anmerkung zur sshd_config hätte ich auch noch. Die Boxen haben per se ja kein root-Passwort gesetzt und da die nur in meinem LAN rumdümpelt, hatte ich das auch erstmal so gelassen. Dann kann man mit dem sshd in der aktuellen Konfiguration aber keine Verbindung aufbauen. Wäre es schlimm, die Option "PermitEmptyPasswords yes" noch mit in die Config aufzunehmen, damit der sshd auch in der Standardkonfiguration genutzt werden kann?

Darüberhinaus scheint zumindestens das Server-Paket aber zu funktionieren, hab bisher allerdings nur die Shell und sshfs genutzt. Den Client noch gar nicht, den hab ich hauptsächlich wegen des ssh-keygen mitinstalliert. Apropos, sollte der Client dann nicht auch noch in die Depends des Servers mit rein, wenn der sshd ohne ihn nicht starten kann (es sei denn man hatte vorher schon Keys zu liegen)?

Auf jeden Fall besten Dank dafür, das dürfte ein sicherer Kandidat für mein finales Setup werden!

Schau ich mir bei Gelegenheit an, sind fast alles valide Punkte.

Bei update-rc.d muss ich selber noch mal schauen; aus dem Kopf würde ich aber sagen, dass der Sinn des Aufrufs ist, das Start-Script aus den Runlevel-Verzeichnissen zu löschen, nicht das Init-Script selber. Das ist Aufgabe des Paket-Remove-Scripts.

Wenn die sshd_config noch nicht entsprechend angepasst ist (hast du das Paket manuell oder über den "Feed+" installiert?), passe ich das an. Aus der Erinnerung heraus sollte das aber schon passen - schau ich mir an.

Da war noch ein anderes Binary, was eigentlich ins Server-Paket gehört; das nachträglich so zu ändern, dass es noch über den Feed installierbar bleibt, ist ein wenig tricky; mal schauen, ob ich das geändert bekomme.

Über den Feed+ bin ich danach erst gestolpert, ich hatte die Pakete aus diesem Thread benutzt. Unterscheiden die sich?

Und ja, update-rc.d kümmert sich nur um die Runlevel-Verzeichnisse. Aber das hat für den "remove"-Befehl die Einschränkung, daß /etc/init.d/[daemon] nicht mehr existieren darf, sonst entfernt das die Links nicht. Es sei denn, daß die Option "-f" mit übergeben wurde, wie du das in postrm und preinst ja z.B. auch schon gemacht hast.

Achja, das Server-postrm-Script aktiviert den dropbear auch nicht, wäre es nicht gut, wenn nach dem Entfernen des Pakets der ursprüngliche Zustand wiederhergestellt wird? Wobei das Jammern auf hohem Niveau ist, wer den OpenSSH installiert, wird den wohl auch dauerhaft drauf lassen und kann zur Not ja per telnet den dropbear wieder aktivieren, man sperrt sich glücklicherweise nicht völlig aus...

Nein, sofern du die aus #17 installiert hast; die sind auch auf dem Feed+.

So eine ausgefeilte Logik, den dropbear wieder zu aktivieren, werde ich sicher nicht in das postrm Script einbauen

Wenn ich an /bin/bash, /usr/sbin/sshd und solchen Programmen arbeite, lasse ich sicherheitshalber immer eine Shell mit dem alten Binary offen. Außerdem habe ich noch einen "toor"-Account mit einer anderen Shell eingerichtet.

Ja, das waren die Pakete aus Post #17, gestern Abend runtergeladen. Sollten also die aktuellen gewesen sein. Werde die Box dann nochmal auf den Feed+ umstellen. Ich brauche die Reaktivierung vom dropbear auch nicht mehr, werde schön den sshd drauf lassen

Warum die dropbear.pid bei dir nicht gefunden wurde, weiß ich ehrlich gesagt nicht, bei mir wird eine angelegt, wenn dropbear gestartet wird. Aber egal, einfacher ist es sowieso, dropbear per Init-Script zu stoppen und dann die Runlevel-Scripten mit update-rc.d anzupassen.

Ich habe das openssh-server.postinst bei mir lokal jetzt so angepasst:

Etwas mehr Holzhammer, aber damit wird ein laufender dropbear hoffentlich immer gestoppt und die Runlevel korrekt geupdatet. So sollte es passen.

Das Paket "update-alternatives" kommt als Dependency mit in die beiden control-Files, und "update-rc.d" als "Recommends". Außerdem "openssh-client" als Recommends für openssh-server. "ssh-keygen" gehört schon in das Client-Paket - ich muss keine Binaries verschieben, und so wird das Client-Paket nachinstalliert, wenn es auf einem Feed gefunden wird.

Ich bereite die Tage mal ein Update vor.

Ach ja: Danke für die Hinweise

Mit der PID wirst du recht haben, grad testweise nochmal den dropbear gestartet und ich sehe nun sehr wohl auch eine /var/run/dropbear.pid. Rückblickend werde ich Pfeife die dropbear-Instanz, die meine nach der Paketinstallation ja noch immer laufende remote-shell offen gehalten hat, mit dem bereits beendeten daemon verwechselt haben. Die alten Conditions mit der PID hätten also sicherlich bleiben können, mea culpa für das falsche Drittel meiner Behauptungen

War das beabsichtigt, daß der sshd jetzt am Ende der postinst nicht mehr gestartet wird?

Und wie siehts mit "PermitEmptyPasswords" aus? Vom sicherheitstechnischen Standpunkt ist das bestimmt korrekt, ein gesetztes root-Passwort vorauszusetzen. Allerdings läuft der telnetd ja trotzdem noch.
(Fand das immer elegant, wie OpenWRT das gelöst hatte. Nach der Installation hatten die auch kein root-PW und nur telnet, sobald man aber ein Passwort gesetzt hat, lauschte nur ein ssh.)

Ich habe mir update-rc.d vorhin etwas genauer angesehen; mit den Optionen, die dort übergeben werden - -s - wird der Daemon gleich mitgestartet. Der Aufruf des Startscripts am Ende war daher eher überflüssig.

Bei dem "PermitEmptyPasswords" bin ich noch nicht überzeugt:
- es ist wirklich unsicher
- OpenSSH ist eben nicht der Standard-sshd der Box, und du musst schon mal wenigstens per Telnet auf der Box gewesen sein, damit du es installieren kannst.
- wenn du dann immer noch ohne Passwort auf die Box möchtest, kannst du entweder von Hand diese Option setzen, oder (viel besser) einen SSH-Key erzeugen.
- wenn du einen Grund hast, OpenSSH zu installieren, hast du dich normalerweise soweit mit dem System auseinandergesetzt, dass du um diese Optionen weisst.

Wenn du noch Argumente dafür hast, immer her damit

Nein, die einzigen "dafür"-Argumente waren schon, daß der default-SSH-Daemon das auch zuläßt und das neben dem sshd ein weiterer standardmäßig laufender Dienst einen noch unsichereren Login ermöglicht. Da nie die Gefahr besteht, sich durch die Installation des OpenSSH-Pakets auszusperren, spricht nix weiter gegen die aktuelle Konfiguration. PubKey-Auth ist für einen passwortlosen Zugang auf jeden Fall der beste Kompromiß an dieser Stelle und gut dokumentiert, sollte für den interessierten Nutzer also keine unangemessene Hürde darstellen.

Noch eine Frage zum update-rc.d, unter welchen Bedingungen bekommt das postinst-Script eigentlich die Variable $D im Environment übergeben, ist das für ein chroot? Müßte dieses $D in dem Falle nicht auch dem /etc/init.d/dropbear vorangestellt werden (und dessen stop ggf. entfallen)?

Zu $D: hab ich nie ausprobiert, in die Sourcen von opkg hab ich jetzt auch nicht geschaut, aber ich gehe davon aus, dass das bei "-o" bzw. "--offline-root" benutzt wird. Und doch, die Option wird doch durchgereicht - Zeile 5.

Ah, verstehe was du meinst: ja, in dem Fall sollte der Stop nicht gemacht werden. Passe ich an.

Nach einer schnellen Suche sieht es so aus, als wenn das $D nicht von opkg gesetzt wird. Ich finde das aber im Yocto Project, was wohl eine build-Umgebung für embedded Systeme ist. Und nach dem was ich dort gelesen hab, steht das D für destination directory, wird nur zur Erzeugung des rootfs nach dem build gesetzt und zeigt dann halt auf das Verzeichnis wo das image liegt. Unter anderem kann man so in den Scripten an einer gesetzten Variable $D erkennen, daß das Script in der build-Umgebung läuft. Später im finalen System würde diese Variable dann also nicht mehr gesetzt werden.

Das Yocto-Project - oder OpenEmbedded - ist die Heimat von opkg und Basis von allen E2-Images.

Jep, sehe ich genauso. Da siehste mal wieder, wieviel unnötiges Zeugs man sich durch Unwissenheit un blindes kopieren einfängt. Ich entferne dann mal die Abfrage für das $D aus dem postinst-Script .

Und wieder was gelernt, glaub dem war ich bislang nie begegnet. Der Umstieg von der Reelbox wird bestimmt noch für viele solcher Momente sorgen...
In den anderen Scripten ist das auch drin