Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
SSH Keys auf USB Stick
115 views
Skip to first unread message
Markus Müller
Jan 2, 2016, 3:20:03 PM1/2/16
to
Hallo Liste,
ich habe meinen SSH-Key auf meinem FAT32 formatierem USB-Stick gespeichert.
Nun bekomme ich folgende Fehlermeldung, wenn ich mich mit Key einloggen
möchte:
WARNING: UNPROTECTED PRIVATE KEY FILE! @
Permissions 0644 for '/media/KeyManagmen/KeePass/tmp/test' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Der Versuch, die Rechte zu ändern scheiterte, diese werden anscheinend
von FAT32 nicht übernommen.
Gibt es generell ein Rechteproblem auf FAT32 ?
Wie löst Ihr dieses Problem ?
Wie löst Ihr das Problem mit den Rechten, wenn ihr euch von einem
fremdem Rechner einloggen wollt, der nicht eueren Usernamen verwendet ??
ggf. auch auf anderen OSes ?
Markus
ich habe meinen SSH-Key auf meinem FAT32 formatierem USB-Stick gespeichert.
Nun bekomme ich folgende Fehlermeldung, wenn ich mich mit Key einloggen
möchte:
WARNING: UNPROTECTED PRIVATE KEY FILE! @
Permissions 0644 for '/media/KeyManagmen/KeePass/tmp/test' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Der Versuch, die Rechte zu ändern scheiterte, diese werden anscheinend
von FAT32 nicht übernommen.
Gibt es generell ein Rechteproblem auf FAT32 ?
Wie löst Ihr dieses Problem ?
Wie löst Ihr das Problem mit den Rechten, wenn ihr euch von einem
fremdem Rechner einloggen wollt, der nicht eueren Usernamen verwendet ??
ggf. auch auf anderen OSes ?
Markus
Stefan Baur
Jan 2, 2016, 3:20:03 PM1/2/16
to
Am 02.01.2016 um 21:10 schrieb Markus Müller:
> ich habe meinen SSH-Key auf meinem FAT32 formatierem USB-Stick gespeichert.
> Nun bekomme ich folgende Fehlermeldung, wenn ich mich mit Key einloggen
> möchte:
> WARNING: UNPROTECTED PRIVATE KEY FILE! @
>
> Permissions 0644 for '/media/KeyManagmen/KeePass/tmp/test' are too open.
> It is required that your private key files are NOT accessible by others.
> This private key will be ignored.
...und das zu recht.
> ich habe meinen SSH-Key auf meinem FAT32 formatierem USB-Stick gespeichert.
> Nun bekomme ich folgende Fehlermeldung, wenn ich mich mit Key einloggen
> möchte:
> WARNING: UNPROTECTED PRIVATE KEY FILE! @
>
> Permissions 0644 for '/media/KeyManagmen/KeePass/tmp/test' are too open.
> It is required that your private key files are NOT accessible by others.
> This private key will be ignored.
> Der Versuch, die Rechte zu ändern scheiterte, diese werden anscheinend
> von FAT32 nicht übernommen.
> Gibt es generell ein Rechteproblem auf FAT32 ?
FAT32 kommt aus der DOS-Welt. Da gibt es nur einen Benutzer und der ist
das, was unter Unix root ist.
Alles andere (GUI, Rechtemodell, Multiuserfähigkeit) ist später mit
Windows aufgepfropft worden und setzt seitens des Dateisystems NTFS voraus.
> Wie löst Ihr dieses Problem ?
> Wie löst Ihr das Problem mit den Rechten, wenn ihr euch von einem
> fremdem Rechner einloggen wollt, der nicht eueren Usernamen verwendet ??
> ggf. auch auf anderen OSes ?
bootfähig und pack' ein portables Mini-Linux darauf.
Bei einem fremden, schon gebooteten Rechner kannst Du sowieso nicht
wissen, ob er irgendwie kompromittiert wurde und Deine Schlüsseldatei
abgeschnorchelt und Deine Passworteingabe mitgeloggt wird.
Gruß
Stefan
Bjoern Meier
Jan 2, 2016, 3:40:02 PM1/2/16
to
Markus Müller <m...@regioways.de> schrieb am Sa., 2. Jan. 2016 um 21:11 Uhr:
Wie löst Ihr dieses Problem ?
RechteProblem in FAT32 der war gut ;)
Cryptcontainer? Keepas-Datenbank. Something like that?
Gruß,
Björn
Christoph Seitz
Jan 2, 2016, 3:50:02 PM1/2/16
to
Hi Markus,
FAT32 selber kann keine Rechte speichern, da es keine Rechte
unterstützt. Du kannst allerdings beim Mounten per Optionen die Rechte
im Linux-Dateibaum setzen (umask,uid,gid). Also beim mounten oder in der
fstab umask=077 als zusätzliche Option angeben und die Meldung sollte
weg gehen.
BTW: Grundsätzlich spricht gegen FAT32 auch nichts, da es das beste
"portable" Dateisystem zwischen Windows, Linux und OS X ist.
Gruß,
Christoph
Am 02.01.2016 um 21:10 schrieb Markus Müller:
FAT32 selber kann keine Rechte speichern, da es keine Rechte
unterstützt. Du kannst allerdings beim Mounten per Optionen die Rechte
im Linux-Dateibaum setzen (umask,uid,gid). Also beim mounten oder in der
fstab umask=077 als zusätzliche Option angeben und die Meldung sollte
weg gehen.
BTW: Grundsätzlich spricht gegen FAT32 auch nichts, da es das beste
"portable" Dateisystem zwischen Windows, Linux und OS X ist.
Gruß,
Christoph
Am 02.01.2016 um 21:10 schrieb Markus Müller:
Martin Steigerwald
Jan 3, 2016, 5:40:03 AM1/3/16
to
Hi Christoph,
Am Samstag, 2. Januar 2016, 21:47:22 CET schrieb Christoph Seitz:
> BTW: Grundsätzlich spricht gegen FAT32 auch nichts, da es das beste
> "portable" Dateisystem zwischen Windows, Linux und OS X ist.
Ja, und das finde ich ziemlich traurig. Weil FAT32 aus meiner Sicht nicht in
das 21. Jahrhundert gehört. Und im Grunde genommen ziemlich Schrott ist. Der
einzige Vorteil: Es ist ziemlich einfach gehalten.
Aber ich denke nicht, dass es an Linux liegt. Nur so lange Apple *und*
Microsoft sich da nicht bewegen, und niemand anderes ein Ein-Klick-
Installations-Dateisystem macht, das auf eben auch auf Mac OS X und Microsoft
läuft, bleibt das wohl so.
Sowas wie F2FS für alle Plattformen wäre was. Eventuell könnte man noch mit
UDF wegkommen, da dies auch schreibbar ist. Allerdings ist es weder für
Festplatten noch SSDs designt worden.
Ciao,
--
Martin
Am Samstag, 2. Januar 2016, 21:47:22 CET schrieb Christoph Seitz:
> BTW: Grundsätzlich spricht gegen FAT32 auch nichts, da es das beste
> "portable" Dateisystem zwischen Windows, Linux und OS X ist.
das 21. Jahrhundert gehört. Und im Grunde genommen ziemlich Schrott ist. Der
einzige Vorteil: Es ist ziemlich einfach gehalten.
Aber ich denke nicht, dass es an Linux liegt. Nur so lange Apple *und*
Microsoft sich da nicht bewegen, und niemand anderes ein Ein-Klick-
Installations-Dateisystem macht, das auf eben auch auf Mac OS X und Microsoft
läuft, bleibt das wohl so.
Sowas wie F2FS für alle Plattformen wäre was. Eventuell könnte man noch mit
UDF wegkommen, da dies auch schreibbar ist. Allerdings ist es weder für
Festplatten noch SSDs designt worden.
Ciao,
--
Martin
Sebastian Suchanek
Jan 3, 2016, 6:20:02 AM1/3/16
to
Am 03.01.2016 um 11:34 schrieb Martin Steigerwald:
> Am Samstag, 2. Januar 2016, 21:47:22 CET schrieb Christoph Seitz:
>>
>> BTW: Grundsätzlich spricht gegen FAT32 auch nichts, da es das beste
>> "portable" Dateisystem zwischen Windows, Linux und OS X ist.
>
> Ja, und das finde ich ziemlich traurig. Weil FAT32 aus meiner Sicht nicht in
> das 21. Jahrhundert gehört. Und im Grunde genommen ziemlich Schrott ist. Der
> einzige Vorteil: Es ist ziemlich einfach gehalten.
> [...]
> Am Samstag, 2. Januar 2016, 21:47:22 CET schrieb Christoph Seitz:
>>
>> BTW: Grundsätzlich spricht gegen FAT32 auch nichts, da es das beste
>> "portable" Dateisystem zwischen Windows, Linux und OS X ist.
>
> Ja, und das finde ich ziemlich traurig. Weil FAT32 aus meiner Sicht nicht in
> das 21. Jahrhundert gehört. Und im Grunde genommen ziemlich Schrott ist. Der
> einzige Vorteil: Es ist ziemlich einfach gehalten.
Und genau diese Einfachheit (natürlich neben der weitverbreiteten
Unterstützung) prädestiniert FAT32 dafür, auch in Kameras, Telefonen,
Fernsehern usw. implementiert zu werden.
Und da der Aufhänger ja die (fehlende) Rechteverwaltung von FAT32 war:
Solange das Ziel ein möglichst unkomplizierter Datenaustausch zwischen
Geräten jeglicher Provenienz ist, steht eine ausgefeilte
Rechteverwaltung dem Ziel doch eher im Weg. Das fängt ja schon damit an,
dass User- und Usergroup-IDs über Systemgrenzen hinweg ja nicht
konsistent sind.
Tschüs,
Sebastian
Martin Steigerwald
Jan 3, 2016, 6:30:03 AM1/3/16
to
Einschränkungen von FAT32 als Austausch-Dateisystem. Aber keine Dateien größer
4 GiB ist heutzutage schon herb.
--
Martin
Sebastian Suchanek
Jan 3, 2016, 9:30:02 AM1/3/16
to
Am 03.01.2016 um 12:23 schrieb Martin Steigerwald:
> [...]
Tschüs,
Sebastian
> [...]
> Die fehlende Rechte-Verwaltung ist aus meiner Sicht eines der kleinsten
> Einschränkungen von FAT32 als Austausch-Dateisystem. Aber keine Dateien größer
> 4 GiB ist heutzutage schon herb.
OK, da gehe ich mit. :-)
> Einschränkungen von FAT32 als Austausch-Dateisystem. Aber keine Dateien größer
> 4 GiB ist heutzutage schon herb.
Tschüs,
Sebastian
Juergen Christoffel
Jan 3, 2016, 10:20:03 AM1/3/16
to
On Sat, Jan 02, 2016 at 09:10:59PM +0100, Markus Müller wrote:
> [Vertrauliche Daten auf FAt32]
kann man sich im Dutzend vorkonfigurieren und bei Bedarf aktivieren. Sogar
auf IP- oder Netzbereiche zugriffsbeschränkt. Das lässt sich unter
unixoiden Systemen auch noch mit wenig Aufwand scripten.
Und wie schon von jemand gesagt: man kann Sticks auch mit ext[34]
formatieren. Auch eine FAT32-Partition und eine EXT-Partition funktionieren
nebeneinander. Und ExFat (leider mal wieder proprietär) ist unter Linux,
OSX und Windows nutzbar.
Un dann gibt es Container, um die Schlüssel etwas sicherer zu
transportieren: in einem tar- oder zip-File, besser noch kryptografisch
gesichert, z.B. mittels "gpg -e" oder "openssl enc" oder
TrueCrypt-Container (bzw. VeraCrypt als Nachfolger). Die passen auch auf
FAT32 und die meisten lassen sich dann unter den gängigen OS-Versionen
lesen. Ja, selbst openssl gibt es für Windows.
Dann habe ich vor kurzem tcplay kennengelernt, aber noch nicht ernsthaft
genutzt. Dazu sagt "apt-cache show tcplay"
The tcplay utility provides full support for creating and opening/mapping
TrueCrypt-compatible volumes. It supports the following commands, each with
a set of options detailed further below: [...]
Gruss, JC
--
I don't care about bloat because it's inefficient. I care about it
because it makes the web inaccessible. Keeping the Web simple keeps it
awesome.
-- Maciej Ceglowski, http://idlewords.com/talks/website_obesity.htm
> [Vertrauliche Daten auf FAt32]
>Wie löst Ihr dieses Problem ?
>
>Wie löst Ihr das Problem mit den Rechten, wenn ihr euch von einem
>fremdem Rechner einloggen wollt, der nicht eueren Usernamen verwendet ??
>ggf. auch auf anderen OSes ?
Private SSH-Keys auf fremden Rechnern: nur separate, temporäre Keys. Die
>
>Wie löst Ihr das Problem mit den Rechten, wenn ihr euch von einem
>fremdem Rechner einloggen wollt, der nicht eueren Usernamen verwendet ??
>ggf. auch auf anderen OSes ?
kann man sich im Dutzend vorkonfigurieren und bei Bedarf aktivieren. Sogar
auf IP- oder Netzbereiche zugriffsbeschränkt. Das lässt sich unter
unixoiden Systemen auch noch mit wenig Aufwand scripten.
Und wie schon von jemand gesagt: man kann Sticks auch mit ext[34]
formatieren. Auch eine FAT32-Partition und eine EXT-Partition funktionieren
nebeneinander. Und ExFat (leider mal wieder proprietär) ist unter Linux,
OSX und Windows nutzbar.
Un dann gibt es Container, um die Schlüssel etwas sicherer zu
transportieren: in einem tar- oder zip-File, besser noch kryptografisch
gesichert, z.B. mittels "gpg -e" oder "openssl enc" oder
TrueCrypt-Container (bzw. VeraCrypt als Nachfolger). Die passen auch auf
FAT32 und die meisten lassen sich dann unter den gängigen OS-Versionen
lesen. Ja, selbst openssl gibt es für Windows.
Dann habe ich vor kurzem tcplay kennengelernt, aber noch nicht ernsthaft
genutzt. Dazu sagt "apt-cache show tcplay"
The tcplay utility provides full support for creating and opening/mapping
TrueCrypt-compatible volumes. It supports the following commands, each with
a set of options detailed further below: [...]
Gruss, JC
--
I don't care about bloat because it's inefficient. I care about it
because it makes the web inaccessible. Keeping the Web simple keeps it
awesome.
-- Maciej Ceglowski, http://idlewords.com/talks/website_obesity.htm
Markus Müller
Jan 3, 2016, 12:40:03 PM1/3/16
to
/ fremden Systemen bei den Keys ??
Juergen Christoffel
Jan 5, 2016, 4:30:03 PM1/5/16
to
On Sun, Jan 03, 2016 at 06:30:06PM +0100, Markus Müller wrote:
> [...]
der Manualpage zu ssh, insbesondere des Abschnitts zur Option "-l" ...
--jc
--
"Lesen erspart Ueberraschungen!" Hermann Heimpel, Historiker
> [...]
>Wie löse ich das Problem mit unterschiedlichen Benutzernamen auf anderen
>/ fremden Systemen bei den Keys ??
Durch lesen? Manchmal auch als RTFM abgekürzt ;-) Zum Beispiel durch Lesen
>/ fremden Systemen bei den Keys ??
der Manualpage zu ssh, insbesondere des Abschnitts zur Option "-l" ...
--jc
--
"Lesen erspart Ueberraschungen!" Hermann Heimpel, Historiker
0 new messages