WIndows 10 Freigabe mounten

Hinweis: In dem Thema WIndows 10 Freigabe mounten gibt es 21 Antworten auf 3 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
    Zitat von Juliane

    Dann hättest du dir das auch sparen können und dein Passwort weiter in der /etc/fstab lassen können

    Also mein Beweggrund war, dass ich in meinem Passwort ein Komma hatte und das konnte ich so nicht lassen, weil es zu den bereits beschriebenen Fehlern führte (ausserdem missfiel mir der Eintrag als plain text).


    Die FSTAB kann ich mit user Rechten öffnen, die in ETC gespeicherte Passwort Datei jedoch nicht, weil ich die Rechte auf root definiert habe.
    Eine in einem verschlüsselten Home-Verzeichnis gespeicherte Passwort-Datei wäre jedoch jederzeit einsehbar, solange der User angemeldet ist.

    Das finde ich auch nicht so toll. Aber da ich Anfänger bin, lasse ich mich gerne eines besseren belehren.

    Für den Inhalt des Beitrages 287467 haftet ausdrücklich der jeweilige Autor: Ganymedy

    Zitat von Ganymedy

    Aber da ich Anfänger bin, lasse ich mich gerne eines besseren belehren.

    Ich möchte dich nicht belehren.

    Wenn es für dich so gut ist, wie du es eingerichtet hast, dann ist doch alles in Ordnung.


    Zitat von Ganymedy

    Eine in einem verschlüsselten Home-Verzeichnis gespeicherte Passwort-Datei wäre jedoch jederzeit einsehbar, solange der User angemeldet ist.

    :?:


    Ich bin mir nicht sicher, worauf du hinaus willst.

    Eine Datei, die du unter /etc speicherst ist auch jederzeit einsehbar.


    Zitat von Ganymedy

    die in ETC gespeicherte Passwort Datei jedoch nicht, weil ich die Rechte auf root definiert habe.

    Aha. Und warum hast du die Rechte in deinem /home so definiert, dass sie außer root auch andere lesen können?


    Die Dateien in meinem /home können die anderen User nicht lesen. Auch nicht, wenn ich angemeldet bin.



    Um ganz sicher zu gehen, darfst du das Passwort der Windowsfreigabe überhaupt nicht speichern und solltest vor dem mounten eine gesicherte Verbindung zum Windowsserver aufbauen. Dann das Passwort über diese Verbindung von Hand mitgeben.


    Wenn du root nicht traust, wird es schwierig.

    Wenn du selber root bist, einfach das Rootpasswort und dein Nutzerpasswort geheim halten.

    Wenn mehrere Leute bei dir/euch Rootrechte haben und du diesen nicht traust, würde ich mir für geheimste Dinge einen zusätzlichen Rechner (keine virtuelle Maschine) anschaffen.

    Für den Inhalt des Beitrages 287468 haftet ausdrücklich der jeweilige Autor: Juliane

    Mahlzeit,


    Zitat von Juliane

    Aha. Und warum hast du die Rechte in deinem /home so definiert, dass sie außer root auch andere lesen können?


    Die Dateien in meinem /home können die anderen User nicht lesen. Auch nicht, wenn ich angemeldet bin.


    So nicht ganz richtig.

    Standardmäßig kann root und der User in dem Home des Users alles lesen, schreiben und ausführen.


    Sobald ein fremder User in der Gruppe "users" ist, kann er auch Dateien lesen, schreiben, ausführen /Verzeichnisse öffnen, die als Gruppe dem User "users" zugeordnet sind und auch die entsprechenden Rechte haben: r, w, oder x.


    Alle anderen User dürfen nur das, was in den Rechten zu others eingetragen ist.


    Auf gut deutsch:

    Die Rechte der Dateien/Verzeichnisse regeln, wer etwas darf oder nicht. Wenn Du in Deinem Home tatsächlich sehr private Verzeichnisse und Dateien hast, dann müssen die auf rwx --- --- gesetzt sein. Ausprobieren.


    Siehe mal die Rechte der .bash_history und .bashrc


    Herzlichst, Gisela

    Für den Inhalt des Beitrages 287469 haftet ausdrücklich der jeweilige Autor: giff

    Zitat von giff

    Standardmäßig kann root und der User in dem Home des Users alles lesen, schreiben und ausführen.

    Ja. Ich weiß.

    Aber wenn man Rechte in /etc anpassen kann, kann man das auch in /home.


    Ganymedy scheint sich ja mit dem Rechtesystem auseinandergesetzt zu haben, wie er schreibt.

    Zitat von giff

    Siehe mal die Rechte der .bash_history und .bashrc

    Eine .bashrc habe ich nicht im /home.


    Ansonsten:


    Code
    ich@Desktop:~> ls -al .bash_history
-rw------- 1 ich users 37179  5. Jan 14:25 .bash_history


    Was ist daran nicht ganz richtig?

    Mein /home darf nur ich lesen. (Und root selbstverständlich.)



    Und meine credentials:


    Code
    ich@Desktop:~> ls -al .smbcredentials
-rw------- 1 ich users 53 15. Okt 2019  .smbcredentials
ich@Desktop:~>

    Einmal editiert, zuletzt von Juliane ()

    Für den Inhalt des Beitrages 287470 haftet ausdrücklich der jeweilige Autor: Juliane

    Hallo,


    Sind wir uns ja völlig einig. :)

    Man muss das nur wissen. In meinem Home werden neue Verzeichnisse oder Dateien ziemlich erratisch angelegt (ich habe jedenfalls noch kein System erkennen können). .bash_history ist zum Beispiel - als ich kürzlich mal nachgesehen habe - auf rw-r--r-- gesetzt gewesen, bashrc auf rw-------.


    Also einfach kontrollieren, ob die Datei, welche man sicher verwahrt haben möchte, wirklich nur vom User gelesen und geschrieben werden darf. Dann sollte das in Ordnung sein.


    Herzlichst, Gisela

    Für den Inhalt des Beitrages 287471 haftet ausdrücklich der jeweilige Autor: giff

    Zitat von giff

    Sind wir uns ja völlig einig.

    Natürlich. Ich habe auch nichts anderes erwartet. ;)



    Mir ist nur das "belehren" sauer aufgestoßen.


    Ich halte mich eben lieber an die Hinweise aus den offiziellen Quellen (zum Beispiel Manpages und den Hinweisen der Entwickler).

    Und obwohl ich mich schon viele Jahre mit smb/cifs beschäftige, habe ich noch keinen ernsthaften Hinweis gefunden, dass die .smbcredentials nicht ins /home gehören.

    Das habe ich hier zum ersten mal gelesen.

    Für den Inhalt des Beitrages 287472 haftet ausdrücklich der jeweilige Autor: Juliane

    Das von Dir vorgeschlagene Vorgehen war das Userhome.

    1. Ist das Standardmäßig für alle in der Gruppe users lesbar. Und schon daher keine Ablage für PWs im plaintext. Wenn Du das bei Dir anders eingestellt hast ist das gut, aber keine Grundlage für eine allgemeine Vorgehensweise.

    2. Wenn die Freigabe über die fstab erfolgt ist davon aus zu gehen, dass sie für alle User ist. Hat also nichts in einem Userhome verloren, sondern da wo allgemeine Konfigurationen zu finden sind. Wenn nämlich aus irgendeinem Grund der User gelöscht wird, kompromittiert, verstorben, was weis ich, dann wird der share plötzlich nicht mehr gemounted. Ein Userhome ist halt kein Ort für Systemweite Angelegenheiten.

    3. Ist die Gefahr, dass sich jemand Userrecht verschafft ist grösser wie bei Rootrechten. Wenn jemand unbefugtes Rootrechte auf einem System hatte muss sowieso alles komplett neu aufgesetzt werden. Beim User halt nur der User. Womit wir wieder bei 2. wären.


    Aber wenn es wirklich sicher sein soll, dann muss man sowieso anders vorgehen, und das ganze nicht über eine fstab auf einer unverschlüsselten Rootpartition mounten.

    Für den Inhalt des Beitrages 287484 haftet ausdrücklich der jeweilige Autor: Der Schaer

    Zitat von Der Schaer

    Das von Dir vorgeschlagene Vorgehen war das Userhome.

    Natürlich.

    Welches Sonst?


    Zitat von Der Schaer

    1. Ist das Standardmäßig für alle in der Gruppe users lesbar.

    Was ist schon "standartmäßig"?

    Standardmäßig wird auch keine Windows10-Freigabe eingebunden.


    Wenn es einem User egal ist, dass sein home von allen anderen Usern gelesen werden kann, warum sollte es ihm dann nicht egal sein, dass ausgerechnet das Passwort der Windowsfreigabe nicht gelesen werden kann?


    Ein wenig sollte man sich schon mit seinem System beschäftigen, wenn man gesteigerten Wert auf Sicherheit legt.

    Dazu gehört auch, dass man die gewünschten Rechte anpasst.

    Auf einem rein privaten Experimentierlaptop ist das nicht unbedingt erforderlich.


    Mein Home können nicht alle anderen User lesen. So ist es bei mir Standard.

    Zitat von Der Schaer

    2. Wenn die Freigabe über die fstab erfolgt ist davon aus zu gehen, dass sie für alle User ist. Hat also nichts in einem Userhome verloren, sondern da wo allgemeine Konfigurationen zu finden sind.

    Entschuldige bitte, aber du scheinst wirklich nicht zu wissen, worum es überhaupt geht, bzw. was die .smbcredentials überhaupt ist, wozu sie dient.

    Einen Lesehinweis habe ich dazu schon oben gegeben.


    In den credentials stehen genau die Dinge, die nicht für alle User des Systems sind.

    Das ist die Konfiguration von genau einem (1) User. Und Konfigurationen eines (1) Users gehören ins /home dieses Users. Nirgendwo anders hin!


    Der User kann ja zum Beispiel sein Passwort auch ändern wollen oder müssen.

    In seinem /home kann er dass alleine. In /etc nicht.


    Zitat von Der Schaer

    3. Ist die Gefahr, dass sich jemand Userrecht verschafft ist grösser wie bei Rootrechten.

    Inwiefern?


    Bei einem gepflegten, aktuellen System mit guten Passwörtern sollte die Gefahr in etwa gleich sein.


    Zitat von Der Schaer

    Wenn jemand unbefugtes Rootrechte auf einem System hatte muss sowieso alles komplett neu aufgesetzt werden..


    Das stimmt soweit.


    Zitat von Der Schaer

    Beim User halt nur der User.

    Das kann man so sehen. Muss man aber nicht.

    Hier kommt es auf die genauen Umstände an, wie der Angreifer zu den Rechten des Users gekommen ist.


    Sollte dieser User auch die Möglichkeit haben, selber root zu werden, wäre ich da schon vorsichtiger.

    Ein "echter" root, würde die credentials der User zum Beispiel nicht unter /etc schreiben. ;)



    Aber das führt jetzt wirklich zu weit.

    Für grundlegende Fragen der Systemsicherheit wäre ein eigener Thread besser. In diesem ist das schon zu OT.



    Der Threadersteller ist damit zufrieden, seine credentials in /etc zu haben.

    Das ist der Vorteil von Linux. Jeder wie er mag.

    Damit ist dieses Problem gelöst und ich bin raus.

    Für den Inhalt des Beitrages 287486 haftet ausdrücklich der jeweilige Autor: Juliane

    Ja, ich bin mit meiner Lösung im Moment zufrieden. Eine Lösung nur diese Passwort-Datei verschlüsselt abzuspeichern und das diese beim Startvorgang automatisch entschlüsselt wird, gibt es wohl nicht ?!?


    Es sind im privaten Haushalt einige PC's und Notebook's vorhanden. Einzige User sind meine Frau und ich. An den Linux PC (ist ein Multiboot-Rechner, z. Test mit noch 2 anderen Linux-OS und Windows 10) wird sich meine Frau nicht setzen, zumindest solange nicht, wie ich mich bei Linux noch mehr oder weniger im Experimentierstation befinde.


    Ich dachte eher an die Möglichkeit eines Trojaners, der unbemerkt die Passwort-Datei ausspionieren könnte und da wäre dieser ja bei einer Datei, die nur mit Root-Rechten geöffnet werden kann, schon eher ausgesperrt. Ich möchte jedoch betonen, dass ich in über 40 Jahren noch nie einen Trojaner auf meinen PC's hatte, also im Grunde da schon weiß was ich tue, also auch in Bezug auf das Internet.


    Sollte ich noch einen VirenScanner installieren, wenn ja welchen ?

    Opensuse Tumbleweed gefällt mir grundsätzlich sehr gut, obwohl ich auf Grund meiner Unwissenheit und immer wieder auftretenden Schwierigkeiten schon mal laut Fluche (da will und muss ich jetzt aber mal durch).


    So auch jetzt. Ich habe mir RDP eingerichtet und nach der ersten Remote-Anmeldung von einem Windows-Rechner bekomme ich nur den Willkomenbildschirm von OpenSuse (ja, habe ich noch nicht ausgeschaltet) und ansonsten nur einen schwarzen Bildschirm. Vor 2 Jahren hatte ich glaube ich auf einem Mageia-Notebook (existiert noch und RDP-Zugriff funktioniert) das gleiche Problem. Aber ich glaube fast, dass würde jetzt in einen anderen Thread gehören.

    Für den Inhalt des Beitrages 287487 haftet ausdrücklich der jeweilige Autor: Ganymedy

    Habe folgendes ausgeführt:


    echo "startlxde" > ~/.Xclients

    chmod +x ~/.Xclients

    sudo systemctl restart xrdp.service


    Immer noch keine Änderung. Dann habe ich mich am OpenSuse abgemeldet und Remote neu angemeldet, Ergebnis schwarzer Bildschirm.


    Dann beim OpenSuse neu angemeldet, siehe da jetzt habe ich auf meinem Windows den kompletten OpenSuse-Desktop.

    Jedoch ist jetzt der Destop am OpenSuse-Remote einen schwarzen Bildschirm. Kurios, oder ?!?

    Für den Inhalt des Beitrages 287491 haftet ausdrücklich der jeweilige Autor: Ganymedy