Dropbear komplett mit OpenSSH ersetzen?

[mehle]

Was mir noch aufgefallen ist: in rc.openssh werden zwar 4 Keys registriert, beim Stop aber nur 2 unregistriert.

Dies ist genau mein Hinweis von vorhin: ich habe vergessen die Registrierung von pub_*_key zu entfernen. Ist bereits für den nächsten Patch vorgesehen. Alternativ kannst du das auch jetzt machen: in make/openssh/files/root/etc/init.d/rc.openssh muss in der load Sektion das laden von pub_* entfernt werden.

Ciao
Stephan

 

[itzy]

Ach, nerv, lag an den fehlenden x-Bits für die rc.authorized-keys, liegt wieder am patch-Programm.
Damit wurde die Datei nicht ausgeführt und auch die neue authorized-keys.def nichts registriert.

Jetzt passts. Ich teste mal weiter.

 

[itzy]

Sorry für Doppelpost, aber ich machs bewusst, wegen 2 Tagen Abstand und auch nem leicht anderem Thema:

Tests sehen ganz gut aus, mit folgenden Anmerkungen:
- Login per SSH-Key funktioniert nicht, Grund sind die 777-Verzeichnisrechte von /, siehe auch hier. Möglich wäre natürlich,die Abfrage aus der auth.c rauszupatchen. Lieber wäre mir aber andere Rechte auf / ;-)
- Die Lösung mit dem authorized-keys pro User konnte ich nicht testen (siehe oben), kommt mir aber recht flexibel vor. Vielleicht sogar etwas zu viel des guten. Wenn man weiss, dass der "--- User" vor dem Key unbedingt nötig ist, funktioniert auch das Speichern. Andernfalls gibt es zwar auch keine Fehlermeldung, es wird aber nichts verändert. Vielleicht wäre ein "No User - Ignoring Key #5" hilfreich.
- OpenSSH üer Intetd mach eh wenig Sinn und wird auch explizit nicht empfohlen, wenn es die Option aber schon gibt: in openssh.inetd ist noch ein Fehler, bzw. eine Referenz auf dropbear, was dazu führt das OpenSSH per inetd nicht funktioniert. Mit inetdcfg_arg0=sshd ist der Socket offen, ich habs aber bisher trotzdem noch nciht zum laufen gebracht.

Anbei noch ein Patch für die externalisierung von OpenSSH, mir wars auf die Dauer zu mühsam die Dateien immer selber einzutragen ;-)

 

[mehle]

- Login per SSH-Key funktioniert nicht, Grund sind die 777-Verzeichnisrechte von /, siehe auch hier. Möglich wäre natürlich,die Abfrage aus der auth.c rauszupatchen. Lieber wäre mir aber andere Rechte auf / ;-)

Jaja, leidige Probleme - in meinem openssh patch ist aber eine patch Datei dinnne, die genau diese Prüfung entfernt - wurde denn der Patch bei dir nicht angezogen (ggf. musst du openssh nochmal kompilieren - d.h. rm -rf sources/openssh*

- Die Lösung mit dem authorized-keys pro User konnte ich nicht testen (siehe oben), kommt mir aber recht flexibel vor. Vielleicht sogar etwas zu viel des guten. Wenn man weiss, dass der "--- User" vor dem Key unbedingt nötig ist, funktioniert auch das Speichern. Andernfalls gibt es zwar auch keine Fehlermeldung, es wird aber nichts verändert. Vielleicht wäre ein "No User - Ignoring Key #5" hilfreich.

Ok, Hinweis auf die Benutzer eingebaut. Ich hätte aber gerne die Flexibilität mit
den einzelnen Benutzern. Sinnvoll ist dies z.B. wenn du einen SVN Server aufsetzt, wo jeder Benutzer Zugriff haben soll. Mit meiner Lösung kannst du dann auch "commands" an die Schlüssel binden.

- OpenSSH üer Intetd mach eh wenig Sinn und wird auch explizit nicht empfohlen, wenn es die Option aber schon gibt: in openssh.inetd ist noch ein Fehler, bzw. eine Referenz auf dropbear, was dazu führt das OpenSSH per inetd nicht funktioniert. Mit inetdcfg_arg0=sshd ist der Socket offen, ich habs aber bisher trotzdem noch nciht zum laufen gebracht.

Ich habe diese Lösung nicht implementiert. Gibt es Gegenstimmen, diese Konfig zu entfernen?

Anbei noch ein Patch für die externalisierung von OpenSSH, mir wars auf die Dauer zu mühsam die Dateien immer selber einzutragen ;-)

Danke

Anbei meine aktualisierten Patches (ersetzen vollständig die 4 vorherigen - die freetz-authkey.patch ist unverändert).

Ciao
Stephan

 

[MaxMuster]

Ich habe den ganzen "Kram" mit inetd nicht testen können..

Von meiner Seite ganz klar, wenn es nicht geht: Weg damit. Besonders, wenn es grundsätzliche Vorbehalte gegen sshd über inetd gibt. Das war halt nur direkt aus dem dropbear Paket übernommen, ohne tiefere Prüfung.

Jörg

PS: Ich find es gut, dass ihr euch des Themas angenommen habt, ein "echter" Einsatz war auf meiner Box aus Platzgründen nicht möglich und deshalb auch mit ziemlichem Aufwand verbunden. Und grundsätzlich ich war ja auch nur der "Umsetzer", nicht der Requestor des Paketes...

 

[mehle]

Hier wieder ein Update:

- scp kann separat selektiert werden (wird auch als Server gebraucht)

- entfernen von inetd.

Alle anderen Patches sind identisch der vorherigen, sind zur Vollständigkeit aber hier nochmal angegeben.

UPDATE: openssh-authkey-20090824-3.patch: entfernen des Patches für auth.c und setzen von StrictMode auf no - dies hat den gleichen Effekt und wir brauchen nichts im Code zu verändern.

Ciao
Stephan

 

[itzy]

PS: Ich find es gut, dass ihr euch des Themas angenommen habt, ein "echter" Einsatz war auf meiner Box aus Platzgründen nicht möglich und deshalb auch mit ziemlichem Aufwand verbunden.

Da die Boxen inzwischen ja auhc immer mächtiger sind und spätestens mit external die Platzprobleme auhc überschaubar sind, ist für mich persönlich OpenSSH schon Alternative.
Zumal das letzte update für Dropbear auch schon etwas länger zurückliegt (wird das noch gepflegt?) und andrerseits die PrivilegeSeparation schon ein echtes Sicherheitsfeature ist...

Ich werde deine Patches und mein exyternal-Patch mal auf nem frischen trunk durchkompilieren, ich denke dann wärs langsam an der Zeit für ein Ticket. Hat schon wer dropbear mit dem authorized-key-package ausprobiert?

 

[mehle]

Ich habe diese Patches auch mit Dropbear ausprobiert. Bei mir konnte ich mich mit keys einloggen. Aber nun ist Dropbear nicht mehr auf meinem System

Ciao
Stephan

 

[itzy]

Zur Info: Ich habs mal per Ticket #533 in Trac eingetragen.

@Stephan: Wo genau patched du die Abfrage auf Dateirechte für den Login per Schlüssel weg?
Ich bekomme auf einem frischen Trunk mit obigen Patches immer noch ein:

Aug 30 20:34:51 fritz auth.info /usr/sbin/sshd[11296]: Authentication refused: bad ownership or modes for directory /

 

[mehle]

@Stephan: Wo genau patched du die Abfrage auf Dateirechte für den Login per Schlüssel weg?
Ich bekomme auf einem frischen Trunk mit obigen Patches immer noch ein:

Aug 30 20:34:51 fritz auth.info /usr/sbin/sshd[11296]: Authentication refused: bad ownership or modes for directory /

Himmel Arsch und Zwirn - ich habe diese Mail übersehen. Sorry.

Ich habe den Patch wieder entfernt - man braucht nur eine Option für sshd: "StrictModes no"

Leider wird die Option nicht mehr gesetzt, wenn du bereits an den Optionen etwas rumgestellt hast :-(

Füge diese Option einfach in OpenSSH ein.

Ciao
Stephan

 

[MaxMuster]

Pfui, er hat Zwirn gesagt ;-) ;-)

Jörg

 

[Whoopie]

Hi,

kann mal jemand zu diesem Changeset Stellung nehmen? Wird die Änderung in file.cgi gebraucht oder nicht?

Danke,
Whoopie

 

[mehle]

Diese Änderung wird benötigt - siehe make/authorized-keys/files/root/etc/default.authorized-keys/authorized-keys.def - Damit immer die aktuellen Keys angezeigt werden bevor sie editiert werden, muss ich irgendwie ein Kommando zulassen.

Falls ihr andere Lösungsvorschläge habt, würde ich die gerne integrieren

Update: dieses changeset ist ja ein removal :-( Ok, wenn diese Funktion nicht gewollt ist, könnt ihr mir bitte Vorschläge machen, wie ich die nötige Logik in make/authorized-keys/files/root/etc/default.authorized-keys/authorized-keys.def umsetzen soll?

 

[MaxMuster]

Hallo Mehle,

Wenn ich es recht verstehe, erzeugt die Zeite die Datei "/tmp/authorized_keys.tmp"??

Da hätte ich was für dich. Denk einfach dran, wie die Dinger in "file.cgi" aufgerufen werden (Zeile "[ -r "$4" ] && . $4"): Die .def-Datei wird ausgeführt!
Wenn du da also z.B. reinschreibst:

CAPTION='SSH Authorized Keys'
[...]
echo "Hallo ich bins  ;-)" > /tmp/authorized_keys.tmp
CONFIG_FILE='/tmp/authorized_keys.tmp'
[...]

Dann steht das da auch drin ;-)

Jörg

 

[mehle]

Die .def-Datei wird ausgeführt!

Oh, das war mir gar nicht bewusst - vielen Dank für den Hinweis. Dann sollte der Angehängte Patch ja funktionieren.

Ich habe leider jetzt und für die nächsten 5 Wochen nicht die Möglichkeit meine Box zu patchen. Könnte bitte jemand diesen Patch einfach einspielen und testen? Ziel ist, dass beim Aufrufen der Webseite etwas in der Box steht (mindestens ein paar Kommentarzeilen).

Danke
Stephan

 

[cuma]

Hallo, Login per auth-key funktioniert mit rev 3704 nicht mehr. Es wird ein Link von ~/.ssh nach /tmp/flash/authorized_keys_root angelegt. Die Datei wurde aber nach /tmp/flash/dropbear/authorized_keys verschoben. Jemand eine Idee?
Im Webinterface ist "SSH: authorized_keys" leer

 

[Silent-Tears]

@cuma: meinst du der smiley muss sein? Is der trunk, per definition geht da immer mal was nicht.

 

[cuma]

Per Definition sind Emoticons dafür gedacht
Und so ein Fehler fällt nunmal beim 1. Login auf

 

[Silent-Tears]

Nun denn, darfst deine Keys wieder sehen, whoopie hat obigen Patch eingechecked. Mir ist btw klar, wofür Emoticons sind, nur: Was stellt er doch dar? Was zähnefletchendes? Zumindest eben etwas, was nicht wirklich die Lust erhöht, das Problem anzugehen.

 

[mehle]

Hi cuma,

sorry für deine Unannehmlichkeiten.

Ich schaue gleich.

Update: kannst du bitte mal folgendes schauen:

1. hast du das Paket authorized-keys (schau ob /etc/init.d/rc.authorized-keys existiert)?

2. gibt es bei dir im ~root/ Verzeichnis ein Verzeichnis .ssh.orig?

3. ist die authorized_keys Datei im Verzeichnis /tmp/flash/authorized_keys_root zu finden?

4. ist die authorized_keys Datei im /tmp/flash/authorized_keys_root die gleiche wie in /tmp/flash/dropbear/authorized_keys?

Ich habe eine Vermutung: durch das Entfernen der authorized_keys Unterstützung wird von dropbear kein ~root/.ssh mehr angelegt und damit kopiert rc.authorized_keys die Datei nicht mehr an die neue zentrale Stelle (d.h. es existiert kein ~root/.ssh.orig bei dir).

Update II: dass du keine Information in der Webseite zu den SSH authorized_keys hast ist durch changeset 3703 bedingt, welches ich mit meinem letzten Patch beheben will.

Ciao
Stephan