Dropbear komplett mit OpenSSH ersetzen?

[cuma]

Das "mad" heisst soviel wie wütend, also seh ich da wirklich kein Problem! Bin das Problem mit Dropbear angegangen und hab einfach rev 7300 genommen ;-) Bastele nicht so gern an Baustellen anderer herum
@mehle:
Aus meiner Erinnerung
1) gab es
2) nein
3) es gab nur /tmp/flash/dropbear/authorized_keys (ohne _root)
4) wie 3), gab nur eine
Den Link ~root/.ssh gab es, nur war dieser auf /tmp/flash/authorized_keys_root und nicht wie es sollte /tmp/flash/dropbear/.
Den Key muss ich mir nicht unbedingt im Webif ansehen, wollte das nur zusätzlich als Rückmeldung geben

 

[itzy]

BTW: ich bekommen beim Erstellen eines Images noch den Fehler:

installing packages
  syslogd-cgi-0.2.3
  avm-firewall-2.0.4_rc2
  rrdtool-1.2.30
  transmission-cgi-0.0.2
  samba-3.0.24
  rrdstats-0.6.9
  authorized-keys-0.1
  e2fsprogs-1.41.3
  fstyp-0.1
  haserl-0.9.26
  modcgi-0.2
  openssh-5.2p1
WARNING: build/modified/filesystem/etc/default.openssh/rsa_key.def not found
WARNING: build/modified/filesystem/etc/default.openssh/dsa_key.def not found
  screen-4.0.3
  transmission-1.75

 

[sf3978]

Ist kein Fehler. Es sind nur Warnungen und Warnungen bekomme ich auch (... schon immer).

 

[mehle]

Hier der Fix für das Problem: da mit meinem authorized_keys patch dropbear ~ root/.ssh nicht mehr anlegt, kopiert rc.authorized_keys /tmp/flash/dropbear/authorized_keys nach /tmp/flash/authorized_keys_root falls in /tmp/flash/authorized_keys_root noch keine authorized_keys Datei existiert.

Damit sollte ein Problemloser Umstieg vom alten dropbear auf dropbear+authorized_keys gelingen. Es gibt keine entsprechenden Vorkehrungen, falls jmd. das alte OpenSSH verwendet hat (ich hoffe, dass es niemand entsprechendes gibt).

Ciao
Stephan

 

[Silent-Tears]

Ich komme mit obigem Patch auch nicht per dropbear und key auf meine Box.

 

[mehle]

Grmpf - kannst du mir nochmal die 4 Fragen von oben beantworten?

Danke
Stephan

 

[Silent-Tears]

Zu 1,2,3:

/var/mod/root # ls -l /etc/init.d/rc.authorized-keys .ssh* /tmp/flash/dropbear/authorized_keys /tmp/flash/authorized_keys_root/
lrwxrwxrwx    1 root     root           31 Sep 27 11:24 .ssh -> /tmp/flash/authorized_keys_root
lrwxrwxrwx    1 root     root           19 Sep 27 11:24 .ssh.orig -> /tmp/flash/dropbear
-rwxr-xr-x    1 root     root         1024 Sep 24 21:49 /etc/init.d/rc.authorized-keys
-rw-r--r--    1 root     root          393 Sep 27 11:44 /tmp/flash/dropbear/authorized_keys

/tmp/flash/authorized_keys_root/:

somit zu 4: nein.

 

[mehle]

Ich verstehe es nicht warum es bei cuma nicht funktioniert: wenn ich folgende Ausgansszenarios teste, bekomme ich nach dem Aufruf von rc.authorized-keys load, welche meinem letzten Patch enthält, immer ein ~root/.ssh welches auf /tmp/flash/authorized_keys_root/ zeigt und die authorized_keys von /tmp/flash/dropbear/ enthält:

~root/.ssh zeigt auf /tmp/flash/dropbear/

~root/.ssh existiert nicht

Hmmm

Ciao
Stephan

 

[cuma]

Hab eben ein neues Image ausprobiert, noch immer Fehler:

~/.ssh zeigt auf /tmp/flash/authorized_keys_root
/tmp/flash/authorized_keys_root gibt es nicht
in /tmp/flash/dropbear/authorized_keys liegt mein key

Nach manuellem Verschieben von meiner authorized_keys _root geht der keyfile-login wieder.

 

[sf3978]

Das Problem hatte ich auch. Nach dem ich alles was nach dropbear auf der Box ausgesehen hat gelöscht habe, funktioniert es:

drwx------    2 root     root            0 Jan  1  2000 authorized_keys_root

lrwxrwxrwx    1 root     root           31 Oct 20 23:26 .ssh -> /tmp/flash/authorized_keys_root

Setting up SSH authorized_keys for root ...initialized.
Looking for group 'sshd' ... found
Looking for user 'sshd' ... found

 

[er13]

@mehle: könntest Du mich/uns mal bitte aufklären, wozu Dein authorized-keys Paket ein eigenes Verzeichnis in /tmp/flash braucht und den ~root/.ssh-Symlink auf dieses setzt? Damit schränkst Du User ein, die andere Dateien in .ssh ablegen wollen, die eher zu dropbear oder openssh gehören als zu authorized_keys_root. Warum kann der ~root/.ssh-Symlink nicht auf /tmp/flash/dropbear bzw. openssh zeigen und aus rc.dropbear bzw. rc.openssh heraus angelegt werden? authorized-keys Paket soll meiner Meinung nach erkennen, welcher ssh-server genutzt wird und die authorized_keys Datei in dem entsprechenden Ordner anpassen und, wenn es beide gibt (was ich allerdings für sehr unwahrscheinlich halte), einfach beide authorized_keys-Dateien anpassen...

 

[RalfFriedl]

Wie wäre es, gleich das gesamte .ssh Verzeichnis dauerhaft zu speichern?

 

[mehle]

@mehle: könntest Du mich/uns mal bitte aufklären, wozu Dein authorized-keys Paket ein eigenes Verzeichnis in /tmp/flash braucht und den ~root/.ssh-Symlink auf dieses setzt?

Das Paket für die authorized-keys Datei bearbeitet nur diese Datei für root. Meine Annahme ist, dass das home-Verzeichnis von root fix auf /var/mod/root zeigt, welches sich im ramfs befindet. Deswegen ist dieses Verzeichnis nicht für Daten geeignet, welche einen Reboot überstehen sollen (wie die authorized-keys Datei).

Damit schränkst Du User ein, die andere Dateien in .ssh ablegen wollen, die eher zu dropbear oder openssh gehören als zu authorized_keys_root.

Diese Aussage ist mir leicht unklar - du kannst Dateien jetzt in ~root/.ssh/ ablegen und dauerhaft speichern. Vorher ging dies nicht.

Warum kann der ~root/.ssh-Symlink nicht auf /tmp/flash/dropbear bzw. openssh zeigen und aus rc.dropbear bzw. rc.openssh heraus angelegt werden? authorized-keys Paket soll meiner Meinung nach erkennen, welcher ssh-server genutzt wird und die authorized_keys Datei in dem entsprechenden Ordner anpassen und, wenn es beide gibt (was ich allerdings für sehr unwahrscheinlich halte), einfach beide authorized_keys-Dateien anpassen...

Diese Lösung ist möglich, aber ich verstehe den Grund nicht. Mein Ziel war es, eine Vereinheitlichung beider SSH-Daemons zu schaffen, da die doch sich nicht gegenseitig behindern (oder doch?). Die Konfigurationen von OpenSSH in ~/.ssh/ sind doch ein Superset zu dropbear, oder etwa nicht?

Natürlich kann man auch deinen Vorschlag umsetzen, aber er braucht mehr Code/Logik und ich verstehe den Sinn halt nicht (bitte bedenke, ich stehe auf dem Standpunkt, dass Komplexität, vor allem unnötige, unser aller Feind ist).

UPDATE: nachdem ich mir das trac Ticket angeschaut habe, ist meine Verwirrung noch gestiegen: der Symlink zeigt auf ein Verzeichnis, welches Reboots übersteht! Vorher konnte der Inhalt von ~root/.ssh/ nicht über reboots gerettet werden. Auch ist der Titel des trac Tickets unklar, ich kann in ~root/.ssh/ schreiben:

/var/mod/root # ls -la .ssh/
drwx------    2 root     root            0 Jan 10 21:20 .
drwxr-xr-x    9 root     root            0 Jan  1  2000 ..
-rwx------    1 root     root         1710 Oct  5 04:32 authorized_keys
/var/mod/root # touch .ssh/file
/var/mod/root # ls -la .ssh/
drwx------    2 root     root            0 Jan 10 21:20 .
drwxr-xr-x    9 root     root            0 Jan  1  2000 ..
-rwx------    1 root     root         1710 Oct  5 04:32 authorized_keys
-rw-r--r--    1 root     root            0 Jan 10 21:20 file
/var/mod/root #

Bitte erklärt mir nochmal das Problem.

Ciao
Stephan

 

[er13]

Diese Aussage ist mir leicht unklar - du kannst Dateien jetzt in ~root/.ssh/ ablegen und dauerhaft speichern. Vorher ging dies nicht.

das stimmt leider nicht, das war sehr wohl möglich (s. da)

Mein Ziel war es, eine Vereinheitlichung beider SSH-Daemons zu schaffen

Wieso in aller Welt soll ein Paket, welches einzige Aufgabe (aus meiner Sicht) darin besteht, ein Web-Interface zum Editieren von authorized_keys zur Verfügung zu stellen, das Ziel verfolgen SSH-Daemons zu vereinheitlichen?

Natürlich kann man auch deinen Vorschlag umsetzen, aber er braucht mehr Code/Logik

Nicht wirklich oder, höchstens paar Zeilen? Und von der Logik her aus User-Sicht ist die Lösung sogar deutlich verständlicher.

 

[RalfFriedl]

Gibt es denn einen Grund, verschiedene Dateien je nach SSH-Server zu verwenden?
Ich weiß, daß man mit OpenSSH mehr Optionen in der Datei unterbringen kann, aber wenn man die verwendet, ist man sowieso auf OpenSSH festgelegt, und zwei Server gleichzeitig laufen zu lassen funktioniert (mit dem gleichen Port) sowieso nicht.
Es geht also immer darum, die Datei ~root/.ssh/authorized_keys zu bearbeiten, Und das Verzeichnis ~root/.ssh/ sollte an einem Ort abgelegt sein, wo Änderungen dauerhaft gespeichert werden können.

 

[mehle]

[Edit frank_m24: Mehrere Beiträge zusammengefasst. Man kann seine Beiträge auch editieren.]

das stimmt leider nicht, das war sehr wohl möglich (s. da)

Ich stehe immer noch auf dem Schlauch - das authorized-key frontend *ISOLIERT* und *EXTRAHIERT* doch nur folgendes aus dem dropbear Paket:

- frontend für die authorized-keys Datei

- umbenennen des /tmp/flash/dropbear Verzeichnisses in /tmp/flash/authorized-keys-root

Jeglicher anderer Code im authorized-keys Paket ist NUR für die automatische Umstellung der alten Konfig (von dropbear) zur neuen gedacht.

Wieso in aller Welt soll ein Paket, welches einzige Aufgabe (aus meiner Sicht) darin besteht, ein Web-Interface zum Editieren von authorized_keys zur Verfügung zu stellen, das Ziel verfolgen SSH-Daemons zu vereinheitlichen?

Mein Ziel war es, dropbear und OpenSSH einfach ersetzen zu können (wie du es auch auf normalen Systemen kannst). Ohne dieses stand-alone authorized-keys Paket geht es nicht! Z.B.: du hast zuerst dropbear mit key-based auth. Nun wählst du dropbear ab und installierst OpenSSH - ohne das authorized-keys Paket hast du KEINE key-based auth mehr, da ja die auth-keys Datei von dropbear NICHT von OpenSSH gefunden wird!

D.h. ohne das auth-keys Paket ist das Verhalten der Fritzbox anders als man es erwarten würde.

Nicht wirklich oder, höchstens paar Zeilen? Und von der Logik her aus User-Sicht ist die Lösung sogar deutlich verständlicher.

Also, die Lösung soll sein, dass für dropbear und OpenSSH separate Verzeichnisse in /tmp/flash existieren sollen? Das auth-keys Paket soll automatisch identifizieren, wo der Link gesetzt werden soll?

Hm, sollen wir dann 2 Kopien der auth-keys Datei speichern?

Warum soll das alles gut sein? Auf einem normalen System hast du doch auch nur EIN .ssh?! Ok, ich gebe zu, dass der Name /tmp/flash/authorized-keys-root vielleicht besser /tmp/flash/dot-ssh-root heissen sollte. Aber mir ist es total unklar warum wir ZWEI .ssh Verzeichnisse für root verwalten sollen.

Ciao
Stephan

[Beitrag 2:]

Gibt es denn einen Grund, verschiedene Dateien je nach SSH-Server zu verwenden?
Ich weiß, daß man mit OpenSSH mehr Optionen in der Datei unterbringen kann, aber wenn man die verwendet, ist man sowieso auf OpenSSH festgelegt, und zwei Server gleichzeitig laufen zu lassen funktioniert (mit dem gleichen Port) sowieso nicht.

Genau mein Punkt - auf normalen System haben wir doch auch nur EIN .ssh, welches automatisch von dropbear oder OpenSSH verwendet wird. D.h., dropbear ist es egal, wenn in .ssh Informationen stehen, die drobear nicht kennt (z.B. OpenSSH Optionen).

Es geht also immer darum, die Datei ~root/.ssh/authorized_keys zu bearbeiten, Und das Verzeichnis ~root/.ssh/ sollte an einem Ort abgelegt sein, wo Änderungen dauerhaft gespeichert werden können.

Exakt.

Und mir ist im Moment total unklar was der Unterschied zwischen dem auth-keys Paket und der alten dropbear Konfig ist - beide machen doch das gleiche: ein Verzeichnis in /tmp/flash anlegen und ein Symlink von ~root/.ssh zu diesem Verzeichnis in /tmp/flash erzeugen.

UPDATE: ich habe mir nochmal das auth-keys Paket angeschaut. Im Endeffekt macht ja alles die rc.authorized-keys Datei. Die einzigste Änderung, die mir wirklich einfällt, die man sinnvoller weise machen sollte ist folgende: anstatt

mv -f $obs_auth_file $dir

sollte man vielleicht

mv -f $(dirname $obs_auth_file)/* $dir

verwenden, damit ggf. weitere Dateien die bereits für dropbear gespeichert wurden alle ins neue Verzeichnis kopiert werden.

Ciao
Stephan

 

[olistudent]

http://trac.freetz.org/changeset/4197

Ich hab das jetzt erstmal so eingebaut und außerdem noch sichergestellt, dass das Verzeichnis existiert und der Symlink somit nicht ins Leere zeigt.

Ansonsten konnte ich der Diskussion hier noch keinen Konsens entnehmen.

MfG Oliver

 

[mehle]

Hm, ich warte noch auf Antwort auf meine Einwände.

Ciao
Stephan

 

[er13]

Ansonsten konnte ich der Diskussion hier noch keinen Konsens entnehmen.

ich bin quasi noch am Überlegen, mir hat die ganze Woche die Zeit gefehlt...

In Bezug auf 4197 frage ich vorsichtig, funktioniert es denn? s. da

 

[olistudent]

Wenn ich mir das nochmal durchlese, dann denke ich, dass es wohl so nicht funktioniert, weil dann die dropbear host keys verschoben werden. Ich hätte es doch ausprobieren sollen...

MfG Oliver