[Gelöst] Fritzbox 7490 mit ssh.

[DeJe]

ich würde gern einen netzinternen git für mehrere Clients aufsetzen. Das Netz besteht aus zwei (auch örtlich) getrennten Fritzen die per VPN (DSL, DynDNS) permanent verbunden sind. An einer Fritz sind die Platten.
Aus verschiedenen Gründen würde ich Freetz gern vermeiden.
Nach den Anleitungen hier und hier funktioniert der ssh-Zugriff für verschiedene User sowohl per PW als auch public key Verfahren (da muß ich noch entscheiden was ich letztlich nutze). Ich möchte für den Zugriff auf git keinesfalls root verwenden, max. einen gemeinsamen gituser.

Folgende "Probleme" habe ich derzeit identifiziert und hoffe das diese sich klären lassen ohne Freetz einzusetzen:

1) Die Fritzen kommen nicht mit der Gruppenverwaltung zurecht. Auch wenn ich diese in /etc/group eintrage und die user entsprechend in /etc/passwd setze ist kein Login möglich. Will sagen, jede Gruppe ausser "0" wird abgewiesen. Gibt es bei den Fritzen nur die root-Gruppe?

2) beim Login über ssh, egal ob per PW oder auth file, bekomme ich für alle User außer root folgende Fehler:

login as: xyz # NOT root
[email protected]'s password:
-sh: /etc/init.d/rc.conf: line 4: can't create /var/env: Permission denied
rm: can't remove '/var/htmltext.db': Permission denied
ln: /var/htmltext.db: File exists
rm: can't remove '/var/TZ': Permission denied
ln: /var/TZ: File exists
ermittle die aktuelle TTY
ls: /proc/2427/fd/0: Permission denied
tty is ""
unbekanntes Terminal
disable start/stop characters and flowcontrol
~ $

Das ist eher ein kosmetisches Problem als NoGO. Aber warum muss die rc.conf bei jedem (ssh)login abgearbeitet werden? Kann man das unterdrücken?

3) hätte ich gern einen halbwegs zeitgemässen editor, nano wäre schon OK. Aber vi ist doch echt ein Krampf, da nehm ich ja emacs noch lieber... Gibts den nano irgendwo als binary wie dropbear oder busybox? Wenn ich mir das recht überlege...mc wäre auch nicht schlecht.

Danke fürs Lesen,
DeJe

 

[RalfFriedl]

1) Die Fritzen kommen nicht mit der Gruppenverwaltung zurecht. Auch wenn ich diese in /etc/group eintrage und die user entsprechend in /etc/passwd setze ist kein Login möglich. Will sagen, jede Gruppe ausser "0" wird abgewiesen. Gibt es bei den Fritzen nur die root-Gruppe?

Was konkret hast Du gemacht?

2) beim Login über ssh, egal ob per PW oder auth file, bekomme ich für alle User außer root folgende Fehler:
Aber warum muss die rc.conf bei jedem (ssh)login abgearbeitet werden? Kann man das unterdrücken?

Weil es aus /etc/profile aufgerufen wird.

3) hätte ich gern einen halbwegs zeitgemässen editor, nano wäre schon OK. Aber vi ist doch echt ein Krampf, da nehm ich ja emacs noch lieber... Gibts den nano irgendwo als binary wie dropbear oder busybox? Wenn ich mir das recht überlege...mc wäre auch nicht schlecht.

Du kannst mit Freetz die gewünschten Programme erstellen und dann diese Programme auf die Box bringen, ohne ein komplettes Freetz Image zu verwenden.

 

[DeJe]

Was konkret hast Du gemacht?

/var/tmp # addgroup gituser
/var/tmp # cat group
root:x:0:
gituser:x:1000:

Und dann den entsprechenden usern die Gruppe zugewiesen.

/var/tmp # cat passwd
root:x:0:0:root:/var/root/:/bin/sh
...
xyz:x:1000:1000:git user:/var/home/xyz:/bin/sh
...

Ergebnis bei login von xyz ist:

Aiee, segfault! You should ...
Connection to fritz.box closed

zu 2) schon klar. Wer zum Geier, außer AVM, ruft beim ssh-Login die rc.conf in der profile auf?

zu 3) schade. Ich wollte mir dieses ganze Theater eben ersparen...und hoffte es gibt prebuilt binaries.

Gruß,
DeJe

 

[koyaanisqatsi]

Abend

Schau dir in der passwd mal die boxusr an.
Ausnahmslos alle sind in der Gruppe root (0),
mach es doch einfach genauso.

Die Boxen waren noch nie für Multiuserbetrieb ausgelegt.

Dich stört die /etc/profile ?
Dann übermounte sie mit einer Eigenen...

touch /var/tmp/profile
mount -o bind /var/tmp/profile /etc/profile

 

[DeJe]

Abend

Schau dir in der passwd mal die boxusr an.
Ausnahmslos alle sind in der Gruppe root (0),
mach es doch einfach genauso.

Ja, geht derzeit nicht anders und habe ich auch so. Als "alter" *nixer widerstrebt mir einfach die Nutzung von "root" immer und überall.

Dich stört die /etc/profile ?
Dann übermounte sie mit einer Eigenen...

touch /var/tmp/profile
mount -o bind /var/tmp/profile /etc/profile

Das werde ich mal angehen.

PS: Ich habe recht viel mit "kleinen" und auch "großen" Linuxen zu tun. Aber bisher ist mir keines untergekommen, das dermaßen konsequent die Rechteverwaltung (user, groups, ..) verbiegt/ignoriert wie der Fritz.

Gruß,
DeJe

 

[PeterPawn]

zu 2) schon klar. Wer zum Geier, außer AVM, ruft beim ssh-Login die rc.conf in der profile auf?

Warum läßt Du überhaupt ein profile-File beim SSH-Login ausführen ? AVM berücksichtigt überhaupt keine weiteren (interaktiven) Shell-Logins, egal ob per Telnet oder SSH oder woher auch immer.

Am Ende steht da eigentlich nichts drin, was Du wirklich für eine SSH-Session benötigen würdest.

zu 3) schade. Ich wollte mir dieses ganze Theater eben ersparen...und hoffte es gibt prebuilt binaries.

Gaaanz dünnes Eis ... erst "Theater" und dann noch "ersparen", da hilft auch demonstrative Ehrlichkeit nur noch begrenzt. :mrgreen:

Aber Spaß beiseite, ist doch kein Theater. Und so spannend ich die Idee mit einem ordentlichen Repository auch finde/fände, auch da muß sich ja jemand der Mühe unterziehen, das dann zu pflegen. Bei allgemein verwendeten Paketen wie dropbear und sogar dem Apache-Server könnte ich mir das sogar noch vorstellen ... aber der Wunsch nach fertigen Paketen wie 'nano' oder 'mc' (beide allerdings als Freetz-Pakete tatsächlich verfügbar, man muß aber - speziell für ncurses und mc - einige Anpassungen vornehmen, wenn man nicht mit der Freetz-Dateisystemstruktur am Start ist) ist dann für einen Router schon etwas ungewöhnlicher. Das dann auch noch aktuell zu halten - auch bei Security-Fixes für irgendwelche einkompilierten Pakete - ist sicherlich eine nicht zu unterschätzende Aufgabe. Soviel nur mal zu "fertigen Binärpaketen" ...

Abschließend noch ein Vorschlag für git und "multi-user": Eventuell ermöglicht Dir gitolite eine passende User-Verwaltung, allerdings wirst Du - solange Du das Problem mit der Linux-Benutzerverwaltung nicht gelöst hast, wobei das Freetz ja auch versucht - damit leben müssen, daß der verwendete "hosting user" in einem root-Kontext arbeitet (zumindest als Gruppe) und damit als potentielles Sicherheitsrisiko bestehen bleibt. Ich habe allerdings keine Ahnung, ob gitolite für Dein konkretes Szenario wirklich paßt, aber einen Blick wäre es wert, wenn Du ansonsten nicht weiter kommst.

EDIT:
Ich nutze die Gelegenheit mal wieder zum Trommeln für modfs, weil es hier (7490, Linux-Kenntnisse, SSH-Server erforderlich, diverse anzupassende Files und die "Ablehnung" von Freetz (als kompletter Mod, das ist ja nur ein klitzekleiner Teil von Freetz gesamt und keine Wertung in Bezug auf Freetz)) passen könnte ... wie Körperteil auf Eimer.

Zum Beispiel ist das Modifizieren von /etc/profile (Umwandeln in Symlink nach /var/profile und Integration von /var/profile in das var.tar-Archiv im root-Verzeichnis) ein Job, den man auch ohne Freetz sehr gut erledigen kann. Ebenso die Integration eines dropbear und anderer zusätzlicher Pakete, solange der Platz in der FS-Partition noch ausreicht ... und um den zu füllen, muß man schon eine komplette Perl-Installation o.ä. einbinden wollen - normalerweise sind da > 20 MB noch frei, das reicht für einige zusätzliche Pakete.

 

[DeJe]

Hallo Peter,
danke für die ausführliche Antwort. Das modfs habe ich hergenommen. Allerdings nur um die Möglichkeiten der rc.user nutzen zu können.
Der komplette Rest liegt auf Festplatte/Stick und wird von dort aus geladen/installiert. Somit bleibt die Box nahe am Original.

meine rc.user sieht übrigens so aus:

eventadd 1 "Die Datei rc.user (TFFS-Minor-ID 98) wird abgearbeitet ..."

HDD_BOOT=''
HDD_PATH='/var/media/ftp'
TEMP='/var/tmp'

while [ -z $HDD_BOOT ] ; do
        sleep 5
        for HDD in $(mount | grep $HDD_PATH | sed -e "s|^.*ftp/||g" -e "s/ .*$//")
        do
                if [ -d $HDD_PATH/$HDD/FritzBoot ] ; then
                        HDD_BOOT=$HDD_PATH/$HDD/FritzBoot
                        break
                fi
        done
done

cd $TEMP
cp $HDD_BOOT/myrc.user $TEMP
$TEMP/myrc.user $HDD_BOOT

Naja, jetzt werde ich erst einmal schauen git (über ssh) ans Laufen zu bekommen. Verfeinerungen dann später.

Gruß,
DeJe

 

[PeterPawn]

Verfeinerungen dann später.

In diesem Kontext würde ich dann tatsächlich eine Verfeinerung für sinnvoll erachten:

Häng' Dich einfach mit dem Aufruf Deiner eigenen Modifikationen an den Code hinter dem mount-Befehl für USB-Volumes in der /etc/hotplug/udev-mount-sd an. Das erspart Dir die Abfrage der Mountpoints in der Schleife und arbeitet sogar dann noch richtig, wenn Du den USB-Speicher erst viel später ansteckst (solange liefe Deine rc.user immer in der Schleife vor sich hin) oder ihn nach dem Entfernen erneut ansteckst. Wenn Du das erneute Verarbeiten der myrc.user nicht willst, benutze eine Semaphore/ein Lockfile nach der ersten Abarbeitung.

Wenn Du Dich dann auch noch im umount/lost-Teil in dieser Datei verewigst, kannst Du sogar auf unerwartete Aktionen wie ein Abziehen des Speichers ohne Abmeldung oder sogar auf die Abmeldung noch ordentlich reagieren und ggf. Dienste beenden, die den USB-Speicher unbedingt benötigen. Am Ende ist es eigentlich egal, ob Du die Abarbeitung der rc.user als Änderung ggü. AVM-Original-FW hast oder eine modifizierte udev-mount-sd ... es wäre auch da nur ein einzelnes File. Wenn Du ohnehin alles auf USB-Stick machst (hatte ich auch mal, um durch Abziehen die Modifikationen auf einen Schlag zu verhindern), dann ist das in meinen Augen die optimale Stelle. Ich bin allerdings irgendwann dann doch (wegen des Problems, daß die Kunden immer den USB-Stick nur mal kurz "ausleihen" wollten) bei der Nutzung des NAND-Flashs der "großen" Modelle gelandet, den kann wenigstens niemand entfernen.

 

[koyaanisqatsi]

Moin

Tips für Verfeinerung...

/etc/shells = erlaubte Loginshells
Wird in /etc/passwd eine andere angegeben, ist das Login gesperrt.
Kann also als Zugriffssteuerung benutzt werden.

/etc/securetty = erlaubte Login Gerätedateien
Wird hier /dev/pts/0 bis /dev/pts/9 eingetragen, klappt zum Beispiel das root Login in "shellinabox"
Shellinabox als CGI, setzt natürlich einen Webserver auf der Box voraus.
Das geht aber nur, wenn /etc/shadow gelöscht wird und das root Passwort in /etc/passwd steht.

rm /var/tmp/shadow

Achtung: passwd benutzt per default schwache Verschlüsselung
Deswegen sollte der Algorythmus beim Erstellen mit angegeben werden...

passwd -a md5 root

 

[DeJe]

Danke für die Hinweise.
Um git per ssh auf die Box zu bekommen bleibt mir wohl doch nur Freetz (zumindest um die binaries zu bilden).

Das mit der groups. Da habe ich eine Vermutung...unter / sind alle wichtigen Verzeichnisse auf 750 gesetzt und root:root. Damit kann man ja mit dem System nix anfangen wenn man nicht mindestens in group root ist.
ein "su - xyz" bringt mir "permission denied".

 

[koyaanisqatsi]

su - xyz" bringt mir "permission denied

Das geht schon, allerdings nicht mit der busybox in /bin .
Dafür braucht es eine im internen Speicher, oder auf USB,
die setuid root bekommen hat...
chmod u=rwxs busybox
oder
chmod +s busybox

ls -la /var/media/ftp/NAME_DES_USB_SPEICHERS/mips/busybox*
lrwxrwxrwx    1 nobody   nobody          12 Sep 29 12:26 mips/busybox -> busybox-1.21*
-rw[COLOR=red]s[/COLOR]rwxr-t    1 root     root       1565400 Sep 29 11:46 mips/busybox-1.20*
-rw[COLOR=red]s[/COLOR]rwxr-t    1 root     root       1576156 Sep 29 11:46 mips/busybox-1.21*

...im $HOME/.profile den PATH auf die busybox Applets setzen,
$HOME/.profile

PATH=/var/media/ftp/SanDisk-Cruzer-01/bin:/var/media/ftp/SanDisk-Cruzer-01/mips:/var/media/ftp/SanDisk-Cruzer-01/scripts:/bin:/usr/bin:/sbin:/usr/sbin
PS1=$(echo -e "\033[1;35m$(whoami)@$(hostname) # \033[0;37m\n")
export PATH PS1

echo $PATH
/var/media/ftp/SanDisk-Cruzer-01/bin:/var/media/ftp/SanDisk-Cruzer-01/mips:/var/media/ftp/SanDisk-Cruzer-01/scripts:/bin:/usr/bin:/sbin:/usr/sbin

...dann klappt auch: su -l root (su -)

 

[DeJe]

Moment. Dein nobody ist aber in Gruppe root, richtig?
Und "su - xyz" geht auch bei mir problemlos. Aber xyz muß eben in Gruppe root sein.

 

[koyaanisqatsi]

Ja, das ist richtig.
Der nobody hat uid 65335 und gid 0.
Wenn ich der busybox setuid root wegnehme,
klappt su - bei mir nicht mehr.

Das Pro/Kontra kannst du hier auch nachlesen...
su braucht suid

...der Sicherheit nicht gerade zuträglich, deswegen Sorge tragen dass nur du dich einloggen darfst.
Möglichst nur aus dem LAN, und wenn nicht gebraucht, deaktivieren.

Wenn nur su suid root sein soll, einfach die busybox umbenennen in: su

 

[DeJe]

Dann geht die Frage an Peter...
Wäre es möglich in modfs entsprechende "chmod 755 ..." einzubauen um die permissions zu ändern? Das Zeugs liegt ja alles im squashfs (/dev/loop0) und das wird ja neu gebaut...wenn ich das richtig sehe?
Das wäre mir ein Test wert.

 

[PeterPawn]

Kein Problem ... Du kannst entweder eigene Scripte in modscripts ablegen oder einfach am "last exit" den Prompt stehen lassen und in aller Ruhe aus einer zweiten Session heraus die Dateien im angezeigten temp-Verzeichnis modifizieren. Erst wenn Du dann in der ersten Session fortsetzen läßt, wird das Verzeichnis 1:1 per mksquashfs zu einem neuen Root-System zusammengepackt.

 

[DeJe]

Ah, ich frage noch mal nach: Die modscripts werden im context des entpackten squashfs ausgeführt und modifizieren dieses. Später wird das dann so eingepackelt, richtig?
OK, dann baue ich mal ein modscript...
Was ich nicht so ganz verstehe ist die Sache mit den PaxHeaders. Muß ich das modfs.tar speziell zusammenpacken (ich nutze derzeit 7zip, kann aber auf Kubuntu ausweichen)?
Vielleicht nehme ich doch erstmal die temp-Variante.

@koyaanisqatsi, nein, das möchte ich nicht, busybox als su. Das war nur ein Test das ich von root aus mit der anderen Benutzeridentität arbeiten kann. Das geht schneller als sich jedesmal mit ssh einzuloggen. Aber das geht ja schon schief (mit su - verliert man ja die Nutzerrechte von root).

Gruß,
DeJe

 

[PeterPawn]

Ah, ich frage noch mal nach: Die modscripts werden im context des entpackten squashfs ausgeführt und modifizieren dieses. Später wird das dann so eingepackelt, richtig?
OK, dann baue ich mal ein modscript...

Eigentlich schon richtig ... bis hierher. Die vier von mir bereitgestellten Dateien können ja als Modell herhalten.

Was ich nicht so ganz verstehe ist die Sache mit den PaxHeaders. Muß ich das modfs.tar speziell zusammenpacken (ich nutze derzeit 7zip, kann aber auf Kubuntu ausweichen)?
Vielleicht nehme ich doch erstmal die temp-Variante.

Hier habe ich einen Filmriß ... und nicht den geringsten Schimmer, was Du am Ende meinen könntest.

EDIT: Ich habe einen blassen Schimmer, was Du meinst. Du kannst das Archiv bei der 7490 doch auch ins NAND-Flash entpacken (also irgendwo in ein Unterverzeichnis unter /var/media/ftp), dann brauchst Du das nicht jedesmal neu laden und kannst dort Deine eigenen Script-Files in aller Ruhe testen. Die PaxHeader sind umsonst, nur mein Fehler beim Packen, daß ich nicht das Busybox-tar genommen habe und deshalb unbekannte Header im tar-File sind. Korrigiere ich bei der nächsten Änderung mit ...

 

[DeJe]

EDIT: Ich habe einen blassen Schimmer, was Du meinst. ... Die PaxHeader sind umsonst, nur mein Fehler beim Packen ...

Damit wäre das geklärt, super.
Heute wirds wahrscheinlich nix mehr. Kaum auszudenken wenn ich der Regierung die Telefonleitung/Internet kappe.

Gruß,
DeJe

 

[PeterPawn]

Kaum auszudenken wenn ich der Regierung die Telefonleitung/Internet kappe.

Immer auf den Anbieter schieben, stimmt in > 95% aller Fälle ohnehin.

 

[KunterBunter]

Kaum auszudenken wenn ich der Regierung die Telefonleitung/Internet kappe.

Dann warst du das heute morgen? :?
Überlastungsangriffe haben die Webseiten der Bundeskanzlerin und des Bundestags lahmgelegt.