nach Upgrade von Buster auf Bullseye, kein Zugriff mehr als root auf xrdp (Desk wird nicht geladen)

  • Hallo,


    ich habe kürzlich auf meinen beiden rPI4 von Buster auf Bullseye geupgraded.

    Seitdem kann ich als User root keine RDP-Sitzung mehr aufbauen. Die Anmeldung funktioniert, aber der Desktop wird nicht geladen.

    Das seltsame ist, mit dem User pi funktioniert es und der Desktop wird geladen.


    meine xrdp.log, zuerst die Verbindung mit pi-user, danach als root:


    in der xrdp-sesman.log findet sich das hier:

    Code
    [20220523-15:10:51] [ERROR] sesman_data_in: scp_process_msg failed[20220523-15:10:51] [INFO ] Starting session reconnection script on display 10: /etc/xrdp/reconnectwm.sh[20220523-15:10:51] [ERROR] sesman_main_loop: trans_check_wait_objs failed, removing trans


    hättet ihr eine Idee woran das liegen könnte?


    Vielen Dank schonmal.

    Edited once, last by blacksun ().

  • Ich hatte vor wenigen Tagen das gleiche Problem, wobei ich nicht einmal als "pi" in die RDP-Session kam. Ich musste einen neuen User anlegen, bis es geklappt hat. Ich bin mir nicht sicher, ob das ein Bug ist, oder ob es nur Folge einer neuen Restriktion ist: Offenbar darf auf dem Pi und in der XRDP-Sitzung nicht mehr gleichzeitig der selbe User angemeldet sein. ?(

  • hättet ihr eine Idee woran das liegen könnte?

    Einige grafische Oberflächen verhindern mittlerweile die Anmeldung als root, was auch Sinn macht.


    Ich kann mir vorstellen, dass du das nicht hören/lesen willst.


    Quote


    Bei anderen Linux-Distributionen war es in der Vergangenheit möglich, sich über den grafischen Anmeldebildschirm als Root anzumelden und einen Root-Desktop zu erhalten, obwohl sich viele Anwendungen möglicherweise beschweren (und sich sogar weigern, wie VLC als Root ausgeführt zu werden).


    Mit sudo führen Sie einen bestimmten Befehl (mit dem Präfix sudo) aus, der Root-Berechtigungen erhält. Mit su verwenden Sie den Befehl su, um eine Root-Shell zu erhalten, in der Sie den gewünschten Befehl ausführen, bevor Sie (hoffentlich) die Root-Shell verlassen. Sudo hilft bei der Durchsetzung von Best Practices, indem nur Befehle ausgeführt werden, die als Root ausgeführt werden müssen (z. B. Softwareinstallationsbefehle), ohne dass Sie sich in einer Root-Shell befinden, in der Sie möglicherweise angemeldet bleiben oder andere Anwendungen als Root ausführen.


    Den Schaden begrenzen

    Wenn Sie sich als Ihr eigenes Benutzerkonto anmelden, dürfen Programme, die Sie ausführen, nicht in den Rest des Systems schreiben. Sie können nur in Ihren Basisordner schreiben. Sie können Systemdateien nicht ändern, ohne Root-Berechtigungen zu erhalten. Dies hilft, Ihren Computer sicher zu halten. Wenn der Firefox-Browser beispielsweise eine Sicherheitslücke aufweist und Sie diese als Root ausführen, kann eine schädliche Webseite in alle Dateien auf Ihrem System schreiben, Dateien in den Home-Ordnern anderer Benutzerkonten lesen und Systembefehle durch kompromittierte ersetzen Einsen. Wenn Sie dagegen als eingeschränktes Benutzerkonto angemeldet sind, kann die böswillige Webseite nichts davon tun - sie kann nur Schaden in Ihrem Home-Ordner verursachen. Dies kann zwar immer noch Probleme verursachen, ist jedoch viel besser, als wenn Ihr gesamtes System kompromittiert wird.

  • Wozu will man sich denn als root auf dem Desktop anmelden? :conf:


    Wenn man mal kurz root-Rechte brauchen sollte, dann könnte man z.B. den Dateibrowser zur Not auch mit sudo per Terminal starten.

    Der Dateimanager wäre allerdings auch schon das einzige Programm was mir zu root-Rechten und GUI einfallen würde, aber sowas (z.B. den Midnight Commander) gibt es auch für die Konsole.

  • Wozu will man sich denn als root auf dem Desktop anmelden?

    Das ist Gewohnheit von Windows.

    Allerdings verhindert da die Benutzerkontensteuerung bei Windows (sofern nicht deaktiviert) gewisse Zugriffe und Installationen, indem der Zugriff nochmals bestätigt werden muss.

    Das ist den meisten frischen Linux-Anwendern aber nicht bewusst.

  • Einige grafische Oberflächen verhindern mittlerweile die Anmeldung als root, was auch Sinn macht.

    das mag ja alles seinen Sinn haben und von mir aus kann das auch der Standard sein. Ich meine der Parameter

    AllowRootLogin

    in der

    /etc/xrdp/sesman.ini

    steht per default auch auf false


    Wenn man diesen manuell auf true setzt, dann sollte das auch passieren was man haben möchte.


    Wozu will man sich denn als root auf dem Desktop anmelden?

    na wenn System nur Serverdienste bereitstellt, dann meldet man sich ausschließlich als root an, sowohl auf

    ich weiß, jetzt kommt bestimmt gleich wieder "dass sich Serverdienste und Desktopoberfläche ausschließen". Manche Dinge kann ich mit einer GUI einfach schneller erledigen

    Ich hatte vor wenigen Tagen das gleiche Problem, wobei ich nicht einmal als "pi" in die RDP-Session kam. Ich musste einen neuen User anlegen, bis es geklappt hat. Ich bin mir nicht sicher, ob das ein Bug ist, oder ob es nur Folge einer neuen Restriktion ist: Offenbar darf auf dem Pi und in der XRDP-Sitzung nicht mehr gleichzeitig der selbe User angemeldet sein. ?(

    das mit den 2 Anmeldungen gleichzeitig habe ich noch gar nicht ausprobiert.

    Ich kann mich auch nicht als Root per RDP verbinden wenn sonst keine weitere Sitzung läuft.

  • na wenn System nur Serverdienste bereitstellt, dann meldet man sich ausschließlich als root an

    Nö, so jedenfalls nicht! Wenn, dann meldet man sich als Systemadminisrator lokal als root an, denn ein Server sollte nie, egal wie, per Remote einen root-Login bereitstellen. Das ist ein Sicherheitsrisiko.


    Es gibt gute Gründe, weshalb sich root nicht default per SSH anmelden darf und es wurde höchste Zeit die Hintertür über den Desktop auch zu deaktivieren.