Fragliche Rechte der Benutzer-Home-Ordner

Tommes · March 29, 2025 at 6:18 PM

Hi!

Ich war grade dabei eine SSH-Public-Key-Authentifizierung auf meiner DXP2800 einzurichten. Ich hab das auch schon ziemlich oft gemacht, so das ich mir mittlerweile drei Skripte geschrieben habe, um das Ganze zu automatisieren. Trotzdem wollte der passwortlose SSH Administratorzugang zur DXP2800 nicht klappen, da ich stets nach dem Passwort gefragt wurde. Also ging ich auf die Suche und fand diesen Hilfe-Artikel "Use public key authentication for ssh instead of password", den ich gleich mal umgesetzt habe. Aber auch hier: Fehlanzeige.

Trotzdem habe ich wohl den Fehler gefunden. Diese lag augenscheinlich an falsch gesetzten Rechten der Benutzer-Home-Ordner. Der Ordner /home hatte korrekterweise zwar die Rechte 755, die Benutzerordner selbst jedoch die Rechte 777, was ja eigentlich schon grob fahrlässig ist. Nachdem ich dieses auf 750 geändert hatte, funktionierte der passwortlose SSH-Zugang auf Anhieb.

Mich würde jetzt interessieren, ob bei euch die Rechte ebenfalls auf 777 stehen, oder habe ich evtl. irgendwo etwas übersehen, das die Rechte bei mir so eingestellt wurden.

Tommes

Jerry · March 29, 2025 at 7:14 PM

Quote from Tommes

Mich würde jetzt interessieren, ob bei euch die Rechte ebenfalls auf 777 stehen, oder habe ich evtl. irgendwo etwas übersehen, das die Rechte bei mir so eingestellt wurden.

Hallo Tommes ,

bei meiner DXP6800Pro habe ich dasselbe Problem.

Allerdings setzt UGOS nach jedem Neustart die Rechte wieder auf 777 .

Ich habe das mal dem Support gemeldet.

Ich finde es super, dass UGOS auf einem Debian basiert, so kann man manuell in viele Konfigurationen eingreifen, die nicht oder nicht nach eigenen Wünschen über die Oberfläche abgedeckt werden. Allerdings überschreibt UGOS diese in viele Fällen entweder nach einem Neustart oder beim Aufruf der entsprechenden Webseite (auch ohne dort etwas zu speichern.

In manchen Fällen liegt in den Verzeichnissen (unterhalb von /etc) dann auch eine JSON Datei von UGOS, diese bestimmt dann die eigentliche Eintrage in den Config Dateien des Dienstes, aber auch hier ist es nicht durchgehend.

Mal abwarten wie sich UGREEN dazu äußert.

VG Jerry

Tommes · March 29, 2025 at 7:37 PM

Hey Jerry,

danke für deine Antwort. Ich würde mich freuen, wenn du die Antwort des Supports zu diesem Verhalten mit mir teilen würdest. Das würde mich nämlich wirklich sehr interessieren.

Das UGREEN innerhalb des Debian-Systems eigene Wege geht, habe ich bereits festgestellt. Ich hatte heute Morgen versucht, mir eine .bashrc ins Home Verteichnis zu stellen, da ich gerne so einen „fancy“ Promt verwende. Aber Pustekuchen. In der /etc/profile sowie in allen anderen globalen Dateien gibt es keinen Verweis auf die persönliche .bashrc o.ä. nur root hat solch eine Datei, in der jegliche Änderung jedoch nichts bewirkt haben. Ich habs dann irgendwann sein gelassen und wollte nicht groß in den globalen Dateien rumfuchteln. Aber daran sieht man, das Debian nicht gleich Debian ist und jeder sein eigenes Süppchen kocht. Das ich zwar ein wenig schade, dient letztendlich aber wohl der Systemsicherheit.

Tommes

Jerry · March 29, 2025 at 7:43 PM

Hi Tommes,

diesem Thema gehe ich auch noch auf die Spur, aber leider fehlte mir bisher die Zeit dazu.

Noch warte ich auf meine Toshiba MG11 Platten, die im Moment schwierig zu bekommen sind. Seit drei Wochen warte ich schon ...

Im Moment läft meine DXP nur mit NVMEs und einer 10GB SFP+ PCI Karte.
Aber diese Tests stehen bei mir noch aus.

Über beides werde ich Dir berichten:

Antwort von UGREEN und
meine Erfahrungen zu den Login Scripten.

VG Jerry

ds106 · March 29, 2025 at 9:30 PM

/home hat bei mir 755, die User Verzeichnisse dann 770, auch nach Neustart.

.profile im home Verzeichnis werden abgearbeitet, zumindest bei administrativen Accounts.

Tommes · March 30, 2025 at 8:22 AM

Moin!

Okay, im Home-Verzeichnis meines Admin-Users wird die .profile tatsächlich abgearbeitet. Da habe ich mich gestern wohl zu sehr auf die .bashrc fixiert, das ich dieses Detail übersehen habe. Gleiches gilt für den Root-User, in dessen Verzeichnis ebenfalls die .profile abgearbeitet wird, die wiederum die .bashrc aufruft. Jetzt sieht mein Prompt wieder gewohnt chic aus.

Quote from ds106

/home hat bei mir 755, die User Verzeichnisse dann 770, auch nach Neustart.

Das ist bei mir definitiv nicht so, da nach einem Neustart die Home-Verzeichnisse wieder auf 777 zurückgesetzt werden, egal was ich zuvor eingestellt hatte. Also bin ich nochmal zurück zu der eingangs verlinkten Anleitung "Use public key authentication for ssh instead of password". Nachdem ich die Rechte der Datei /usr/local/bin/check_and_fix_ssh_permissions.sh auf 755 und die Rechte der Datei /etc/systemd/system/ssh-permission-monitor.service auf 644 geändert hatte, bekam ich auch keine Fehlermeldung mehr beim überprüfen des Servies mit sudo systemctl status ssh-permission-monitor.service. Nachdem der Service dann augenscheinlich fehlerfrei lief habe ich die DXP2800 neu gestartet und siehe da, die Rechte des Home-Verzeichnis meines Admin-Users wurden auf 700 festgelegt, ebenso wie die des Verzeichnisses .ssh. Die authorized_keys erhielt die Rechte 600, also genauso wie es sein soll.

Blöd ist jetzt nur, das die Rechte der id_rsa als auch die id_rsa.pub nach einem Neustart überschrieben und zurück auf 777 gesetzt wurden. Daher muss man das Script /usr/local/bin/check_and_fix_ssh_permissions.sh wohl noch ein wenig erweitern.

Unterm Strich kann ich mich jetzt auch nach einem Neustart passwortlos mit der DXP2800 per SSH als Admin-User aufschalten. Das hätte ich mir zwar einfacher vorgestellt, aber naja... hab's ja hinbekommen.

Tommes

Jerry · March 30, 2025 at 10:39 AM

Guten Morgen zusammen,

Tommes:

vielen Dank für Deinen Link und die Doku. Das hätte mir der UGREEN Support ja auch mitteilen können .
Aber dennoch bin wirklich sehr zufrieden mit dem Support, da wird das daran auch nichts ändern.

Ich werde mir die service Datei mal ansehen und umschreiben, so dass man diese User Spezifisch aufrufen kann und berichte dann.

Zum Thema Login Prozess habe ich zwei Möglichkeiten probiert und beide funktionieren und sind "Reboot-fähig":

1. Ändern der Datei /etc/profile

Nach dem export PATH Eintrag folgenden Block einfügen:

Code

# if no .profile in user homedir
if [ ! -f "$HOME/.profile" ]; then
   echo "no .profile"
   #/usr/bin/cp -f /etc/skel/.profile "$HOME/.profile"
fi

2. Im User-Home eine Datei .bash_profile mit folgendem Inhalt anlegen:

Code

# if running bash
if [ -n "$BASH_VERSION" ]; then
   # include .bashrc if it exists
   if [ -f "$HOME/.bashrc" ]; then
       . "$HOME/.bashrc"
   fi
fi

Beides Funktioniert und danach wird die Datei ~/-bashrc beim Login ausgeführt.

ds106:

Ich muss Tommes Recht geben, auch bei mir werden die Rechte der Home Dirs immer wieder auf 777 geändert.
Auch die Rechte am Verzeichnis .ssh und der darin befindlichen Datei authorized_keys werden geändert.

Viele Grüße Jerry

Tommes · March 30, 2025 at 11:09 AM

In der angesprochenen Doku war unten ein Link auf ein GitHub Repo. Ich habe dort mal einen issue platziert, *klick*. Das du dir den Service anschauen und benutzerspezifisch erweitern möchtest, finde ich gut und bin schon gespannt wie ein Flitzebogen, was dabei herauskommt.

Änderungen in der /etc/profile wollte ich eigentlich vermeiden, da diese zwar zunächst einen Reboot überleben würde, ein Systemupdate aber wohl nur bedingt, wenn überhaupt. Daher wollte ich mich auf die Nutzerspezifischen Dateien beschränken. Mein Administrator hat jetzt eine .profile in seinem Home-Ordner liegen, die beim Systembenutzer root bereits angelegt war und schon über Inhalte verfügte. Ich habe in beiden .profile Dateien meine persönliche PS1 Variable hinterlegt, die ebenfalls einen Neustart überleben. Zumindest sollte die .profile meines Administrators auch ein Systemupdate überleben, wohingegen ich mir beim Systembenutzer root nicht ganz sicher bin.

Was ich nur noch nicht ganz begriffen habe ist, in welcher Datei sich der Verweis auf die persönliche .profile befindet. Sollte dieser Verweis normalerweise nicht in der /etc/profile stehen?

Jerry · March 30, 2025 at 11:39 AM

Hallo zusammen,

ich habe jetzt die Dateien (Scrip und systemd service) von https://guide.ugreen.community/ugos/tweak/ssh_public_key/ angepasst:

Datei /usr/local/bin/check_and_fix_ssh_permissions.sh:

Code

sudo vi /usr/local/bin/check_and_fix_ssh_permissions.sh

mit dem Inhalt:

Bash

#!/bin/bash
# file:
# - /usr/local/bin/check_and_fix_ssh_permissions.sh
# source:
# - https://guide.ugreen.community/ugos/tweak/ssh_public_key/
# - https://raw.githubusercontent.com/UGREEN-NASync/community-guide/refs/heads/main/docs/ugos/tweak/ssh_public_key/check_and_fix_ssh_permissions.sh
# modify doku see here:
# - https://ugreen-forum.de/forum/thread/578-fragliche-rechte-der-benutzer-home-ordner/

# User's home directory
USER="$1"
HOME_DIR="/home/$USER"
SSH_DIR="$HOME_DIR/.ssh"
AUTHORIZED_KEYS="$SSH_DIR/authorized_keys"
# Add further files if necessary

# Function to set permissions
set_permissions() {
    echo "Checking permissions..."

    if [ "$(sudo runuser -l $USER -c "stat -c '%a' $HOME_DIR")" != "700" ]; then
        echo "Setting permissions for $HOME_DIR to 700"
        sudo chmod 700 "$HOME_DIR"
    fi

    if [ "$(sudo runuser -l $USER -c "stat -c '%a' $SSH_DIR")" != "700" ]; then
        echo "Setting permissions for $SSH_DIR to 700"
        sudo chmod 700 "$SSH_DIR"
    fi

    if [ "$(sudo runuser -l $USER -c "stat -c '%a' $AUTHORIZED_KEYS")" != "600" ]; then
        echo "Setting permissions for $AUTHORIZED_KEYS to 600"
        sudo chmod 600 "$AUTHORIZED_KEYS"
    fi
    
    # Add further actions if necessary
}

# Initial permissions check
set_permissions

# Monitor for changes in permissions
while inotifywait -e attrib "$HOME_DIR" "$SSH_DIR" "$AUTHORIZED_KEYS"; do
    set_permissions
done

Display More

danach Ausführungsberechtigung setzen

Code

sudo chmod +x /usr/local/bin/check_and_fix_ssh_permissions.sh

und die systemd service Datei /etc/systemd/system/ssh-permission-monitor@.service erstellen:

> Achtung im Dateinamen muss das "@" Zeichen enthalten sein!

Code

sudo vi /etc/systemd/system/ssh-permission-monitor@.service

mit dem Inhalt:

Code

# file:
# - /etc/systemd/system/ssh-permission-monitor@.service
# source:
# - https://guide.ugreen.community/ugos/tweak/ssh_public_key/
# - https://github.com/UGREEN-NASync/community-guide/blob/main/docs/ugos/tweak/ssh_public_key/ssh-permission-monitor.service
# modify doku see here:
# - https://ugreen-forum.de/forum/thread/578-fragliche-rechte-der-benutzer-home-ordner/

[Unit]
Description=Monitor and enforce permissions home directory and .ssh for user %I
After=network.target


[Service]
ExecStart=/usr/local/bin/check_and_fix_ssh_permissions.sh %i
Restart=always
User=root
ExecStartPre=/bin/bash -c 'while ! systemctl is-active ssh || ! [ -d /home/%i ]; do echo "Waiting for ssh and /home/%i ... "; sleep 5; done'


[Install]
WantedBy=multi-user.target

Display More

Nun dem systemd nur noch Mitteilen, dass er die service files neu einliest:

Code

sudo systemctl daemon-reload

und den Dienst aktivieren und starten:

Code

sudo systemctl enable --now ssh-permission-monitor@<dein Benutzername>

zum Schluss nochmal den Status prüfen mit

Code

sudo systemctl status ssh-permission-monitor@<dein Benutzername>

fertig

Viele Grüße

Tommes · March 30, 2025 at 12:06 PM

Sach dat doch, das dir (oder euch) das GitHub Repo gehört. Da hätt ich mir den Issue und die Übersetzung ja sparen können

Ich hab mein Laptop vorhin zugeklappt und werde deine Anpassungen erst später übernehmen und testen. Bis hierhin aber schon mal vielen Dank für deine Unterstützung. Ich habe in meiner /usr/local/bin/check_and_fix_ssh_permissions.sh noch zwei Einträge für die id_rsa und id_rsa.pub eingefügt, sodass diese ebenfalls wieder die richtigen Rechte nach einem Reboot erhalten. Aber da ist natürlich sehr individuell, da nicht jeder seine Schlüssel so nennt, wie vorgeschlagen. Außerdem verwendet ja auch nicht jeder einen RSA Schlüssel. Heute nimmt man ja eher einen Ed25519 Schlüssel. Egal…

Jerry · March 30, 2025 at 12:12 PM

Quote from Tommes

Sach dat doch, das dir (oder euch) das GitHub Repo gehört. Da hätt ich mir den Issue und die Übersetzung ja sparen können

nein, ich habe nur einen Kommentar eingefügt in Deinen Issue

Ich werde jetzt auch Wochenende machen.
Hab noch einen schönen Sonntag ...

Participate now!