su - root

  • Ein paar Sachen zur Systemsicherheit:


    Wenn SSH gegen das Inet offen ist, sollte im /etc/ssh/sshd_config der root Zugriff nicht erlaubt werden.
    Ausserdem muss dann ein Benutzer mit non-root Privilegien erstellt werden.
    (Habe ich so gemacht.)


    Ich logge dann (sshd restart) mit:
    ssh -l neueruser host.domain.net ein. Klappt alles wie erwartet.


    Danach mache ich einen su - (root) und erwarte nach der Passworteingabe eine rootshell...
    aber was passiert ist, dass eine *template-Fehlermeldung zurückkommt und somit der root User keine shell erhält. (Hier fummelt wohl die "middleware" dazwischen.)


    Gibt es hierzu einen fix?


    Ich möchte den root Zugang nicht unbedingt per default weltweit offen haben.


    Gruss runvdr

  • ich bin mir nicht genau sicher wie es bei lindvr ist, aber ist dein user auch in der gruppe 'wheel' ?
    bei vielen distributionen ist es so, dass nur user die auch in der gruppe wheel sind einen
    su durchführen dürfen.


    Marcus

  • Das 'su root' Kommando hat hier nicht direkt was mit wheel zu tun. (Aber man kann das so konfigurieren, das ist schon richtig.)


    Es ist ziemlich sicher das linvdr 0.7 hier etwas abfangen will, wo es eigentlich nichts abzufangen gibt. Darum auch die template Fehlermeldung. Ich weiss die genaue Meldung nicht auswendig und komme derzeit nicht an meinen vdr-Rechner heran. Das Problem ist aber sehr einfach nachzustellen. Einfach mit adduser (oder wars useradd...) einen User kreieren, Passwort setzen und damit einloggen. Dann 'su -' eingeben...


    Gruss, runvdr


    ---
    Missing linvdr features: RCS, ntpdate.

  • Servus,


    mit einer genauen Fehlermeldung wär's evtl. möglich, dir weiter zu helfen. Ansonsten wäre das su von BusyBox mein nächster Kandidat in der Liste der Verdächtigen.


    Übrigens: Wozu brauchen wir ein RCS, wenn es keine Revisionen zu kontrollieren gibt? Wozu eine Kanone, wenn es keine Spatzen gibt?


    Ansonsten schau mal in die Doku, dann siehst du, wie du Pakete nachinstallierst. Wenn du's brauchst, wirf's halt einfach drauf.


    Viele Grüße, Mirko

  • Ok, inzwischen bin ich an meinen Rechner gekommen. Also hier die Fehlermeldung:


    linvdr:~# su -
    su: This applet requires root priviledges!
    linvdr:~#


    (Der Rechtschreibefehler ist inklusive. ;) )


    Ich meine das linvdr hier irgendein applet mit root-Privilegien starten will, das (noch) nicht mit root-Berechtigung erfolgen kann, weil man erst root werden will. Ich meine das ist ein Bug.


    Apropos RCS, mit Kanonen auf Spatzen geschossen? RCS besteht im wesentlichen aus einem checkin, einem checkout und dem rcs programm. Das ist eher schon minimalistic. Es ist sehr praktisch, wenn man dauernd kleine Änderungen an den Systemfiles macht und man spart sich Dateien wie: /etc/init.d/runvdr-old, -save, -orig, -1, -2 usw. Aber das nur am Rande.


    Gruss, runvdr

  • Hi,


    ist das nicht etwas übertrieben auf root zu verzichten? Ich denke, daß wenn Du root sperrst auch su nicht funktionieren wird.


    Aus:
    http://www.faqs.org/docs/securing/chap15sec122.html


    PermitRootLogin no
    The option PermitRootLogin specifies whether root can log in using ssh. Never say yes to this option.


    Wäre es nicht einfacher/besser, daß root Paßwort länger/komplexer zu machen?

    Pentium Quad 8400s, 4 GB RAM, ASUS P5Q-E, 2x Mystique Dual (V2 und V3), 15 TB RAID, yaVDR 0.5a (VDR 2.x)

  • "The option PermitRootLogin specifies whether root can log in using ssh. Never say yes to this option."


    Das betrifft nur den Zugang für root über SSH. Never say yes ist sicherheitstechnisch eine katastrophale Aussage.


    Wenn man als User123 auf dem host eingeloggt ist, muss su gehen, es sei denn es gibt eine Einschränkung auf bestimmte User. (Bsp. über group wheel, wie es hier auch schon erwähnt wurde.)


    Gruss, runvdr

  • Hi,


    ich verstehe sicherheitstechnisch Deine Bedenken - ich finde auch nicht toll Adminrechte über das Internet zu erlauben. Die Aussage ist auch etwas bedenklich extrem formuliert.


    Entweder du möchtest root irgendwie über das Internet erlauben - oder eben nicht.


    Eine gute Schutzmöglichkeit ist in jedem Fall ein langes gutes Paßwort und ein langes Timeout bei falschem Passwort. Eventuell noch eine Brute force Detection (http://blog.andrew.net.au/2005…pt_recent_and_ssh_attacks) um nachzusehen, ob sich die Versuche häufen .. aber das war es schon. Evenutell könnest Du den Server noch an ein festes Client-Zertifikat zusätzlich binden (das nicht vom Server automatisch übertragen wird), das würde die Sache noch komplexer machen, jedoch kannst du dann nicht mehr von jedem SSH-Client einloggen (weil das Zertifikat fix eingespielt sein muß).


    Worin siehst Du den großen Vorteil, wenn Du zuerst mit einem anderen User einloggst und dann mit su auf root Rechte gehst ... es ist gerade einmal eine Zwischenebene - es sind dann zwar 2 Paßworte notwendig - aber da bist genauso gut dran, wenn du eines machst das deutlich länger/komplexer ist. (2 einzeln hackbare Passwörter sind genauso gut wie ein Passwort + 1 Bit [~Stelle] - also fast nicht besser)


    In beiden Fällen bis du aber Admin von remote - oder verstehe ich da etwas falsch?


    Hier ist die Anleitung: http://www.debianhowto.de/howt…shconfig/c_sshconfig.html

    Pentium Quad 8400s, 4 GB RAM, ASUS P5Q-E, 2x Mystique Dual (V2 und V3), 15 TB RAID, yaVDR 0.5a (VDR 2.x)

  • Hi, geht das nicht langsam am eigentlichen Problem vorbei ? Ich denke, die Aussage "Never say yes to this option." ist klar und deutlich. Und es ist sicher nicht verkehrt, das auch zu befolgen.


    runvdr:
    Welches su wird denn da ausgeführt (which su) ? Hast du es mal mit einem einfachen su (ohne -) probiert ?


    Gruß
    Mag1c

  • Zitat

    Also hier die Fehlermeldung:


    linvdr:~# su -
    su: This applet requires root priviledges!
    linvdr:~#


    (Der Rechtschreibefehler ist inklusive. ;) )


    Danke, das hilft mir weiter.


    Es gibt irgend ein Problem mit dem Symlink. Welches hab ich nicht raus. Lösch einfach mal den Symlink (rm /bin/su) und leg ihn als Root neu an (ln -s /bin/busybox /bin/su). Danach funktioniert es zumindest bei mir.


    Zitat

    Apropos RCS, mit Kanonen auf Spatzen geschossen? RCS besteht im wesentlichen aus einem checkin, einem checkout und dem rcs programm. Das ist eher schon minimalistic.


    ... aber immer noch größer als wenn's gar nicht drauf ist. Der Punkt ist folgender: Wer braucht es wirklich? Mehr als 1 Prozent der Benutzer? Ich glaube kaum. Und wenn es sich einfach nachinstallieren lässt, ist es ein Grund mehr, es zu einem Addon zu erklären -- wer's braucht, installiert einfach das Debian-Paket nach und kann es benutzen. LinVDR wäre längst sehr viel größer, wenn wir alles drauf packen würden, was irgend jemand nützlich findet. Es ist ja nicht mal der MC drauf, und das, obwohl ich ihn täglich benutze -- die Mehrheit der Leute braucht ihn nicht, also ein Addon und gut.


    Viele Grüße, Mirko

  • Danke für den Tipp, cooper. Leider hats nichts gebracht. Ich habe momentan zu wenig Zeit um mich weiter darum zu kümmern. Mein "Quick-Fix" besteht darin, den Zugang via SSH übers Internet komplett zuzumachen, so dass ich nurmehr aus dem internen Netz an die Büchse komme.


    Ja, das mit dem RCS als Addon ist eine gute Idee. Sollte man machen.


    Gruss, runvdr

  • Servus,


    Zitat

    Leider hats nichts gebracht.


    Achso, hattest du auch ein "chmod u+s /bin/su" gemacht? Ansonsten /bin/su löschen, /bin/busybox nach /bin/su kopieren und chmod u+s machen. Ist aber eine riesige Sicherheitslücke!


    Viele Grüße, Mirko


    Zitat

    Ja, das mit dem RCS als Addon ist eine gute Idee. Sollte man machen.


    Wie, "sollte man machen"? Es steht jedem frei, das Debian-Paket davon (es gibt doch hoffentlich eins?) selbst nachzuinstallieren. Ich werde definitiv nicht für irgend welche andere Software Debian-Pakete bauen, das können die hübsch selbst oder lassen es halt bleiben. Dann gibt's halt kein RCS.


    Viele Grüße, Mirko

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!