Anfängerfragen - Linux Neuling? Hier ist der richtige Platz für deine Fragen (2)

  • Ersteller Gelöschtes Mitglied 45455
  • Erstellt am
Sorry, ich hab da gestern was durcheinander gebracht. Vorweg: "ausführen" war hier der falsche Begriff im Kontext mit cat, da ich cat gar nicht meinte.
Ich versteh gerade selbst nicht was ich genau gemeint habe, da ich gerade nichts hinbekomme...

Aber: wenn ich ./dateiname.txt ausgebe, dann gibt der mir den Inhalt im Terminal wieder, sofern ich die Berechtigung dafür habe.

Ich würde ja gerne ausprobieren ob source für .txt-Daten überhaupt funktioniert, bzw. probiere es gerade an einer script aus, aber bei mir kommt gerade nur noch "usr/bin/bash: Defekter Interpreter: Datei oder Verzeichnis nicht gefunden" ?! Wieso spuckt der das aus bzw. wie repariere ich das wieder?


edit:
So, jetzt komm ich wieder rein :d Also nochmal: Source vs. ./

Ich bin mir ziemlich sicher das ich gestern ein script mit source ausführen konnte, aber nicht mit ./ weil mir die Rechte gefehlt haben.
Allerdings kommt bei mir eben jetzt die Meldung mit dem Defekten Interpreter.

@fax668 wie meinst du das mit schauen? Das der da nicht's ausführt? Afaik ist doch gerade ./ und source zum ausführen (?).
Und war das nicht irgendwie so, dass source das script mit sudo ausführt?
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Urgh, leg dir bitte mal ein gutes Linux Buch zu oder arbeite ein paar Online Tutorials durch. Das geht ja durcheinander wie Kraut und Rüben. :hmm:

"usr/bin/bash: Defekter Interpreter: Datei oder Verzeichnis nicht gefunden" ?! Wieso spuckt der das aus bzw. wie repariere ich das wieder?
Du hast "usr/bin/bash" geschrieben anstatt "/usr/bin/bash". Man beachte den führenden Schrägstrich.

So, jetzt komm ich wieder rein :d Also nochmal: Source vs. ./
Bash kennt zwei Befehle, die beide das gleiche tun: "source" und "." (ohne Schrägstrich). Danach folgt ein Leerzeichen und dann der Name der Datei, die eingelesen und ausgeführt werden soll. In der Datei stehen dann ganz normale Befehle, so wie man sie auch am Bash Prompt eintippen würde. Die Bash startet mit source bzw. "." keinen extra Prozess, weshalb die Datei nur die Leseberechtigung und nicht die Berechtigung zum Ausführen braucht.

Du verwechselst den Befehl "." offensichtlich mit "./". "./" ist Bestandteil eines Pfadnamens. Verzeichnisnamen werden ja bekanntlich wie folgt aufgebaut: "/Wurzelverzeichnis/Unterverzeichnis/Unterunterverzeichnis/Dateiname". Wenn du jetzt nicht jedesmal den kompletten Pfad wiederholen willst, sondern einfach nur auf eine Datei aus dem aktuellen Arbeitsverzeichnis verweisen willst, dann tippst du "./Dateiname". "." steht dabei für das aktuelle Arbeitsverzeichnis und danach muss zwingend ein Schrägstrich und kein Leerzeichen folgen.

Und war das nicht irgendwie so, dass source das script mit sudo ausführt?
source hat mit sudo nichts zu tun.
 
Aber: wenn ich ./dateiname.txt ausgebe, dann gibt der mir den Inhalt im Terminal wieder, sofern ich die Berechtigung dafür habe.
Nein!
UNIX Terminalbefehle sind immer wie folgt aufgebaut
Code:
befehl option1 option2 …
Wenn man nur
Code:
./dateiname.txt
eintippt, dann wird versucht "./dateiname.txt" auszuführen. Da "./dateiname.txt" wahrscheinlich kein "x" Flag gesetzt hat, wird wahrscheinlich
Code:
bash: ./dateiname.txt: Keine Berechtigung
ausgegeben.

Lege mal in eine Datei "print_home.sh" an mit folgendem Inhalt
Code:
#!/bin/sh
ls -lh $HOME
Dann setze mit "chmod x print_home.sh" das "x" Flag für die Datei. Dann kann man mit "./print_home.sh" die Datei ausführen. Skripte kann man schreiben, in dem man den Shebang "#!" als erstes in die Datei schreibt, direkt gefolgt vom Shell-Interpreter. Für Skripte nutzt man meistens nur die Bourne-Shell (sh). Bei Linux ist das die bash in einem speziellem Bourne-Modus, auf einem UNIX ist das eine eigene Shell. Man kann natürlich auch andere Shells nutzen, aber sh oder bash sind auf Linux das sinnvollste. Alternativ kann man natürlich eine ausgewachsene Skript-Sprache nutzen (Python, Perl, Tcl/Tk, …).


Ich würde ja gerne ausprobieren ob source für .txt-Daten überhaupt funktioniert, bzw. probiere es gerade an einer script aus, aber bei mir kommt gerade nur noch "usr/bin/bash: Defekter Interpreter: Datei oder Verzeichnis nicht gefunden" ?! Wieso spuckt der das aus bzw. wie repariere ich das wieder?
"usr/bin/bash" ist eine relative Pfadangabe, weil der führende "/" fehlt.
 
Was bedeutet x Flag? Recht zum ausführen?
Das habe ich mittlerweile (mit chmod) angepasst und nun passt es auch wieder :-]
Auch das mit dem Skript (übe es eigtl. nur mit ".sh ").

Ums Verständis:
Das ./ gebe ich ein um Skripte auszuführen. Hab's jetzt nicht ausprobiert aber könnte ich auch Text-Daten ausgeben, sofern sie #!/usr/bin/bash beinhaltet?

Dann die zweite Frage:
Ich habe eine Textdatei erstellt mit 7 Zeilen:

Dies ist die erste Zeile
dies ist die zweite Zeile
darauf folgt die dritte Zeile
anschließend die vierte
und da das so Spaß macht
machen wir hieraus insgesamt
7 Zeilen :-)

Dann habe ich eine weitere Zeile hinzugefügt mit:
echo "Dies ist eine weitere Zeile" >> Textdatei.

soweit so gut.
Danach wollte ich die ersten beiden Zeilen von oben wieder unten - also nach "Dies ist eine weitere Zeil" einfügen, mein Befehl:
head n-2 Textdatei >> Textdatei

Allerdings ist das der Inhalt des Textes nun:

Dies ist die erste Zeile
dies ist die zweite Zeile
darauf folgt die dritte Zeile
anschließend die vierte
und da das so Spaß macht
machen wir hieraus insgesamt
7 Zeilen :-)
Dies ist eine weitere Zeile
==> Textdatei <==
Dies ist die erste Zeile
dies ist die zweite Zeile
darauf folgt die dritte Zeile
anschließend die vierte
und da das so Spaß macht
machen wir hieraus insgesamt
7 Zeilen :-)
Dies ist eine weitere Zeile
Dies ist die erste Zeile
dies ist die zweite Zeile


Was ich nicht verstehe ist, wieso der statt nur die ersten beiden Zeilen, erst einmal den kompletten Text rein schriebt und anschließend die ersten beiden Zeilen.
 
Was bedeutet x Flag? Recht zum ausführen?

Ja.

Das ./ gebe ich ein um Skripte auszuführen. Hab's jetzt nicht ausprobiert aber könnte ich auch Text-Daten ausgeben, sofern sie #!/usr/bin/bash beinhaltet?

Nein! Pass auf. Das erste Wort, das du in die Shell eingibst, ist IMMER ein Programm. Wenn du also "./script.sh" eingibst, dann versuchst du die Datei auszuführen. Immer. Sie wird niemals ausgegeben, sondern immer ausgeführt. Ohne Ausnahme. Wenn du willst, dass die Datei ausgegeben wird, dann musst du als erstes Wort deines Befehls ein Programm angeben, was das kann, z.B. "cat", also "cat script.sh".

Die Tatsache, dass du vor den Dateinamen zum Ausführen ein "./" setzen musst, liegt daran, dass die Bash ausschließlich in den Systempfaden für Programme nachschaut, bzw. um genauer zu sein in den Pfaden, die in der Variable "$PATH" definiert sind. Wenn du ein Programm starten möchtest, welches nicht in einem Ordner in $PATH ist, dann muss ein Slash im Namen vorkommen. Und das einfachste, sich dann auf ein Programm im aktuellen Verzeichnis zu beziehen, ist einfach ein "./" voranzustellen.

Aber woher weiß das System wie das Script auszuführen ist bzw. dass das ein Shell-Script ist? Das macht es daran fest, indem erst geprüft wird, ob die Datei Maschinencode oder lesbarer Code ist. Ist sie Maschinencode, wird sie halt ausgeführt und gut ist. Ist es allerdings kein Maschinencode, was dein Shell-Script natürlich nicht ist, wird nach der sogenannten Shebang geschaut. Die Shebang ist eine Zeile ganz oben in der Datei, die mit "#!" beginnt und dann den absoluten (!!!) Pfad zum Programm enthält, mit dem der Code ausgeführt werden kann. Lautet deine erste Zeile also "#!/usr/bin/bash", weist du dem System an, diese Datei mit dem Programm "/usr/bin/bash" auszuführen, was Sinn macht, da das ja ein Bash-Script ist. Würdest du ein Python-Script schreiben, würde die Shebang "#!/usr/bin/python" lauten. Enthält die Datei allerdings keine Shebang, musst du das Programm bereits in der Shell angeben, indem du nicht mehr "./script.sh" schreibst, sondern "bash script.sh" oder "python script.sh". Enthält die Datei weder eine Shebang noch gibst du das Programm in der Shell an, wird ein nicht-Maschinencode-Programm IMMER mit der aktuellen Shell ausgeführt, also meistens der Bash. Bei einem Bash-Script geht das gut, bei einem Python-Script nicht. Dann wirft dir die Bash nämlich haufenweise Fehlermeldungen entgegen, weil sie mit Python-Code nichts anfangen kann.

Was ich nicht verstehe ist, wieso der statt nur die ersten beiden Zeilen, erst einmal den kompletten Text rein schriebt und anschließend die ersten beiden Zeilen.

Ganz einfach. Du musst zwischen ">" und ">>" unterscheiden. Ersteres überschreibt den gesamten Inhalt der Datei mit der Ausgabe links vom ">". Das ">>" jedoch hängt die Ausgabe links an das Ende der Datei an. Wie du schon richtig erkannt hast, gibt dir "head -n2 Textdatei" die ersten beiden Zeilen einer Datei zurück. Es ist "-n2", nicht "n-2". Das ist eine Option. Optionen beginnen immer mit einem Strich. Diese ersten beiden Zeilen wirfst du dann mit ">>" an das Ende der Datei ran. Möchtest du also den gesamten Inhalt das Datei durch die ersten beiden Zeilen ersetzen, würde der Befehl "head -n2 Datei > Datei" lauten, also nur ein ">".
 
Oh verdammt, mir ist das gar nicht mit n-2 aufgefallen -.-'

Ja, ich meinte eigtl. auch schon ausführen und nicht eine Textdatei mit cat im Terminal ausgeben :)

Danke für die Einführung zu bash und ./ :wink:


edit:
Wie könnt ich's umgekehrt machen? Also einige Zeilen an den Anfang eines Dokuments einzufügen? Wenn möglich ohne sed und ohne awk.
Was mir gerade einfallen würde:
1) Vorhandende Datei umzubenennen
2) echo 'Text eingabe' > EigentlicherDatei (also vorhandener Datei von oben)
3) die umbenannte Datei >> EigentlicherDatei

Gibt's da noch andere Wege wie ich mit Kommando's dahin gelange?
 
Zuletzt bearbeitet:
Ich bin letztens mit meinem Nextcloud-VPS umgezogen und hab ein Problem. Durch das Hin-und Herkopieren haben die Dateien auf dem Server und meine lokales Dateien unterschiedliche Zeitstempel,
d.h. Nextcloud will meine sämtlichen Daten vom Server runterladen, da sie einen aktuelleren Zeitstempel haben als meine lokalen Dateien.

Gibts eine Möglichkeit, die Zeitstempel abzugleichen? Sind immerhin 80GB von der ganzen Familie.

Hab per davfs meine Dateien schon lokal gemountet, wäre da per rsync was zu machen?

Danke
 
1) Vorhandende Datei umzubenennen
2) echo 'Text eingabe' > EigentlicherDatei (also vorhandener Datei von oben)
3) die umbenannte Datei >> EigentlicherDatei

So würde ich es auch machen, wenn sed und awk nicht vorhanden wären. Aber ich glaube das ist heutzutage kein Problem mehr. sed ist gerade für solche Anwendungszwecke gedacht, also kann man es auch ruhig dafür nutzen.
 
learning by mitlesing ;-)
 
Weiß eigentlich irgendwer in welchem Zusammenhang gucharmap und gnome-characters stehen? Soll das Letzte vielleicht das Erste ablösen? gnome-characters kategorisiert Emojis und zeigt Schriften in verschiedenen Schriftarten an. Dafür zeigt gucharmap deutlich mehr Zeichen aus allen möglichen Schriftsystemen an. Haben irgendwie beide ihre Vor- und Nachteile, aber gnome-characters wirkt moderner.
 
Wenn man sich die von gucharmap abhängigen Pakete ansieht, dann wird das vermutlich nicht so schnell ausgemustert werden, falls du dich fragst, ob es sich lohnt sich daran zu gewöhnen :) (für Gnome aber wohl tendentiell eher als für Mate..)

Aber die selben Devs arbeiten daran.. also wird es wohl ersetzt werden, sobald die abhängigen umgestellt wurden..
 
Zuletzt bearbeitet:
Naja, Maintainers != Devs. Das sind nur die, die für Arch die PKGBUILD schreiben und regelmäßig updaten. ^^
 
So ,seitdem kein Displaylink mehr läuft, ist auch Ruhe im Karton was Freezes angeht:banana: Aus unerfindlichen Gründen geht jetzt allerdings mein Drucker nicht mehr?!
Ich wollte sowieso mal mein System frisch machen, aus Sicherheitsgründen.

Gibt es eigentlich noch sicherere Linuxe als Ubuntu (kostenlos sollte es aber sein), oder nehmen die sich da nicht viel?
 
Gibt es eigentlich noch sicherere Linuxe als Ubuntu (kostenlos sollte es aber sein), oder nehmen die sich da nicht viel?

Definitiv. Es gibt beispielsweise Tails. Wenn Du danach suchst, kommst Du zwar auf eine NSA-Selektorliste, aber egal - ich bin da sowieso schon oft genug drauf :rofl:
Oder was zum Beispiel in Verbindung mit Libreboot gerne genutzt wird, ist Trisquel. Das ist quasi ein Ubuntu ohne Software, die ihren Quelltext nicht öffentlich präsentiert. Es basiert auf dem Linux-Libre-Kernel, der ebenfalls ohne Firmware von Hardwareherstellern auskommt. Wenn man beides zusammen einsetzt, bedeutet das, dass der ganze PC dann mit Open Source läuft. Das Problem ist nur, dass Libreboot nur auf älteren PCs läuft, aber wenn nirgendwo mehr "finstere Programmteile" sind, in die man nicht hineinschauen kann, ist es natürlich schon ein klarer Vorteil.

Ubuntu ist meiner Meinung nach einfach das praktischste Linux für den täglichen Einsatz und für Linux-Einsteiger super geeignet, weil es von Multimedia über Zocken bis zu professionellen Anwendungen oder Serverprogrammen alles abdeckt. Wenn es um Security geht, kann man sich fast unendlich einschränken, um noch mehr Sicherheit zu erhalten.
Ich persönlich finde z.B. ein Libreboot Notebook mit Trisquel für Arbeiten, die keinen schnellen Rechner erfordern, noch absolut verkraftbar. Trotzdem, für einen langjährigen Windowsnutzer, ist bereits der kleine Schritt, weg von Windows auf Ubuntu oder vergleichbare Linuxdistributionen, sicherheitsmäßig ein sehr großer Schritt.
 
Ich bin letztens mit meinem Nextcloud-VPS umgezogen und hab ein Problem. Durch das Hin-und Herkopieren haben die Dateien auf dem Server und meine lokales Dateien unterschiedliche Zeitstempel,
d.h. Nextcloud will meine sämtlichen Daten vom Server runterladen, da sie einen aktuelleren Zeitstempel haben als meine lokalen Dateien.

Gibts eine Möglichkeit, die Zeitstempel abzugleichen? Sind immerhin 80GB von der ganzen Familie.

Hab per davfs meine Dateien schon lokal gemountet, wäre da per rsync was zu machen?

Danke

Noch jemand einen Tip für mich?
 
Danke dir, Overclocker! Mir geht es vor allem um die Sicherheit von einzelnen Dateien. Da hab ich nun einen sehr speziellen Wunsch.

-eine .txt-Datei enthält sensible Daten
-ich will diese (mit einem selbstgewählten Schlüssel) crypten
-das gecryptete Ergebnis muss jedoch immer noch les- , tipp- und druckbare Zeichen ergeben, und sollte am besten in txt-Format bleiben!
-an der Datei müssen nach dem decrypten easy Änderungen möglich sein, nach denen es erneut (mit selbem Schlüssel) gecryptet wird.

Ich habe es mal mit "gpg -c" probiert. Leider kommt dann so ein Mist raus:
)4fç-aâoÓÈŽÕŽ…;wè*rMŽw‰Þ:rolleyes:
Und die Endung geht auf ".txt.gpg" - was natürlich Mist ist - das weckt doch erst die Begehrlichkeit, es zu decrypten zu wollen um an wertvolle Information zu kommen:stupid:
 
Ich habe es mal mit "gpg -c" probiert. Leider kommt dann so ein Mist raus:
)4fç-aâoÓÈŽÕŽ…;wè*rMŽw‰Þ:rolleyes:
Und die Endung geht auf ".txt.gpg" - was natürlich Mist ist - das weckt doch erst die Begehrlichkeit, es zu decrypten zu wollen um an wertvolle Information zu kommen:stupid:

Versuch es mal mit "gpg --armor -c". Und die Endung ist absolut kein Grund zur Besorgnis.
 
Hm, die Datei anschließend wieder umbenennen wäre ja nicht so schwer ?!?
Die Endungen dienen halt dem Zweck immer direkt und automatisch die passende Anwendung zuordnen zu können. Wenn Du sie manuell änderst (gpg --> txt) ist das unter Linux nicht dramatisch, Windows ist da manchmal pingelig.
Dann hast Du halt weiter "normale" TXTs für den Editor und "unnormale" TXTs für gpg - zum Entschlüsseln musst Du das halt auch wieder händisch händisch zuweisen.

Und was meinst Du mit "Mist"? Sollte die verschlüsselte Datei Deiner Meinung nach immer noch lesbaren Klartext enthalten?
Dann musst Du Dir eine eigene Chiffre mit Wortsubstitutionen bauen - das ist aber (a) limitiert, weil nicht alles übersetzt werden kann, sondern nur das was in Deinem Wörterbuch steht, (b) limitiert in den Übersetzungen, dadurch vergleichsweise unsicher und (c) eher ungewöhnlich, dass Dein Anwendungsfall so speziell sein soll
 
Ich kann den anderen nur zustimmen. GPG ist die korrekte Anwendung, um Dateien zu verschlüsseln. Aber man kann vermuten, dass sie verschlüsselt ist, wenn sie nicht komplette Zufallsdaten enthält - spätestens, wenn man sie öffnen möchte.

Anders geht das leider nicht mit der gleichen Sicherheitsstufe.
 
Versuch es mal mit "gpg --armor -c". Und die Endung ist absolut kein Grund zur Besorgnis.

Sehr gut, danke für die schnelle Antwort! Das kommt meinen Vorstellungen schon sehr nahe. Neue Fragen:
1. Wenn ich also einen Ausdruck davon habe (von der gecrypteten Datei, txt.asc), könnte ich diesen im Falle eines Datenverlustes abtippen, und nach Eingabe der korrekten Phrase wieder das Original vor mir sehen?
2. Das Ver- /Entschlüsselungsverfahren mit gpg --armor -c wird auch in zukünftigen Linux-Versionen genau so funktionieren (also mir aus der selben txt.asc das selbe Original zurückbringen)?
3. AES256 soll ja sehr sicher (unknackbar) sein. Könnte man die Datei auch in einer Cloud ablegen, ohne Bedenken zu haben? Das würde gegen ein anderes Risiko (Platte raucht ab) schützen.
4. Das System hinterlegt meinen eingegebenen Schlüssel ja nirgends, oder?!
5. Wenn ich eine sehr kurze Phrase verwende, ist dann AES128 nicht genauso sicher wie AES256? Wenn ein Char 8 Bit hat, müsste AES128 ja bis 16er Länge der Passphrase voll abdecken, bzw. die höheren AES keinen Zusatznutzen bringen?!
 
1. Ja, dafür ist es unter anderem gedacht.
2. Unter aller Voraussicht, ja. Sonst hätten wir alle ein gewisses Problem :d
3. Theoretisch. Aber darüber wird häufig ein wenig (zu) euphorisch geschrieben. Wichtig ist, dass der tatsächliche Schlüssel wirklich gut geschützt ist, und nicht nur mit einem Billig-Passwort "geschützt" an einem leicht zugänglichen Ort abgelegt wird. Sonst kann man per Brute Force dieses Kennwort herausbekommen und damit natürlich dann die Datei entschlüsseln.
4. Es könnte den Schlüssel schon für z.B. die Dauer der Terminalsitzung oder darüberhinaus speichern, je nachdem, was Du eingestellt hast. Ich glaube, normalerweise wird ein eingegebenes Passwort für SSH-Zertifikate beispielsweise bei den meisten Distributionen automatisch nach der ersten Eingabe für den Rest der Sitzung gespeichert.
5. Du erzeugst bei AES256 einen 256 Bit langen Schlüssel. Der Schlüssel verschlüsselt und entschlüsselt die Nachricht. Der wird dann höchstens selbst wieder per Passwort geschützt, weil er ja auf dem Rechner gespeichert ist und sonst von jedem abgerufen werden könnte. Beim RSA-Key von GnuPG ist das ähnlich, nur dass dort ein 4096 Bit langer Schlüssel erzeugt wird, wobei es eben den privaten und öffentlichen gibt, während bei AES die Ent- und Verschlüsselung mit dem gleichen Key passiert, was dazu führt, dass man ihn nicht veröffentlichen kann, während bei RSA über einen öffentlichen Schlüssel kommuniziert werden kann.

Ein kleiner Tipp noch von mir: Nicht alles willst Du verschlüsseln ;) - Man kann leider nicht ausschließen, dass einem mal früher als erwartet etwas zustößt und dann möchte man eben doch, dass jemand an bestimmte Dinge noch ran kommt. Also nicht vor lauter Eifer plötzlich alle wichtigen Daten so verschlüsseln, dass ihre Nutzbarkeit komplett von Dir alleine abhängt.
 
Zuletzt bearbeitet:
Ich bin letztens mit meinem Nextcloud-VPS umgezogen und hab ein Problem. Durch das Hin-und Herkopieren haben die Dateien auf dem Server und meine lokales Dateien unterschiedliche Zeitstempel,
d.h. Nextcloud will meine sämtlichen Daten vom Server runterladen, da sie einen aktuelleren Zeitstempel haben als meine lokalen Dateien.

Gibts eine Möglichkeit, die Zeitstempel abzugleichen? Sind immerhin 80GB von der ganzen Familie.

Hab per davfs meine Dateien schon lokal gemountet, wäre da per rsync was zu machen?

Danke
Ja, das geht, mit find und touch. Du gehst in das Datenverzeichnis deiner neuen Nextcloudinstallation und führst dort folgenden Befehl aus:
Code:
find -exec touch -r /Pfad/zum/alten/Nextcloud-Datenverzeichnis/{} {} \;
 
Zu 5, das Passwort was du eingibst ist nicht direkt der Schlüssel. Das ist quasi die Grundlage wie man den richtigen symmetrischen Schlüssel kommt ( Hash oder sowas).
Und dieser ist bei AES256 eben immer 256bit lang. Egal was du eingibst.
 
Ein kleiner Tipp noch von mir: Nicht alles willst Du verschlüsseln ;) - Man kann leider nicht ausschließen, dass einem mal früher als erwartet etwas zustößt und dann möchte man eben doch, dass jemand an bestimmte Dinge noch ran kommt. Also nicht vor lauter Eifer plötzlich alle wichtigen Daten so verschlüsseln, dass ihre Nutzbarkeit komplett von Dir alleine abhängt.
Ich will grundsätzlich alle persönlichen Daten verschlüsseln, wieso auch nicht? Es gibt im Falle des Falles einige denkbare Wege, den Leuten, die dann Zugriff auf die Daten haben sollen, diesen zu ermöglichen.
 
Ich will grundsätzlich alle persönlichen Daten verschlüsseln, wieso auch nicht? Es gibt im Falle des Falles einige denkbare Wege, den Leuten, die dann Zugriff auf die Daten haben sollen, diesen zu ermöglichen.

Richtig, aber es gibt halt auch Leute, die verschlüsseln alles mit einem zufälligen Schlüssel, sodass es bombensicher ist, und geben ihn niemandem weiter, noch schreiben sie ihn irgendwo auf. Das macht natürlich möglicherweise auch mal Sinn, aber ich wollte nur darauf hingewiesen haben, dass das auch zum Problem werden kann.
 
1. Ja, dafür ist es unter anderem gedacht.
2. Unter aller Voraussicht, ja. Sonst hätten wir alle ein gewisses Problem :d
3. Theoretisch. Aber darüber wird häufig ein wenig (zu) euphorisch geschrieben. Wichtig ist, dass der tatsächliche Schlüssel wirklich gut geschützt ist, und nicht nur mit einem Billig-Passwort "geschützt" an einem leicht zugänglichen Ort abgelegt wird. Sonst kann man per Brute Force dieses Kennwort herausbekommen und damit natürlich dann die Datei entschlüsseln.
4. Es könnte den Schlüssel schon für z.B. die Dauer der Terminalsitzung oder darüberhinaus speichern, je nachdem, was Du eingestellt hast. Ich glaube, normalerweise wird ein eingegebenes Passwort für SSH-Zertifikate beispielsweise bei den meisten Distributionen automatisch nach der ersten Eingabe für den Rest der Sitzung gespeichert.
5. Du erzeugst bei AES256 einen 256 Bit langen Schlüssel. Der Schlüssel verschlüsselt und entschlüsselt die Nachricht. Der wird dann höchstens selbst wieder per Passwort geschützt, weil er ja auf dem Rechner gespeichert ist und sonst von jedem abgerufen werden könnte. Beim RSA-Key von GnuPG ist das ähnlich, nur dass dort ein 4096 Bit langer Schlüssel erzeugt wird, wobei es eben den privaten und öffentlichen gibt, während bei AES die Ent- und Verschlüsselung mit dem gleichen Key passiert, was dazu führt, dass man ihn nicht veröffentlichen kann, während bei RSA über einen öffentlichen Schlüssel kommuniziert werden kann.

Ein kleiner Tipp noch von mir: Nicht alles willst Du verschlüsseln ;) - Man kann leider nicht ausschließen, dass einem mal früher als erwartet etwas zustößt und dann möchte man eben doch, dass jemand an bestimmte Dinge noch ran kommt. Also nicht vor lauter Eifer plötzlich alle wichtigen Daten so verschlüsseln, dass ihre Nutzbarkeit komplett von Dir alleine abhängt.

Sehr gut, vielen Dank dir!

Zu 5. noch eine Frage, ich hab das noch nicht ganz verstanden:
Die Passphrase, die ich manuell eingegeben habe, genügt aber, um die Datei auch auf einem fremden/frisch aufgesetzten Linux zu entschlüsseln?
Also ich muss die txt.asc gut speichern, und die Passphrase gut merken, sonst nichts?!

Weil du erst schreibst: die Passphrase ist für Sitzungsdauer gespeichert, dann: der 256-Bit Schlüssel ist auf dem Rechner gespeichert (wo? ) ?
Ich will mich eben auf keinen Fall selbst aussperren :d

Hier steht auch noch was von Hashing... muss ich auch hashen, oder ist das irrelevant?
 
Weil du erst schreibst: die Passphrase ist für Sitzungsdauer gespeichert, dann: der 256-Bit Schlüssel ist auf dem Rechner gespeichert (wo? ) ?
Normalerweise in einer Datei. Bei einigen Kryptosachen kann man die privaten Schlüssel auch im TPM Modul ablegen, so kann niemand den kopieren. Das setzt zwingend voraus, dass man Kopien aufhebt an sicherer Stelle. Bei einem kurzem Schlüssel kannst Du diesen auch auf Papier ausdrucken und so archivieren.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh