SSH Schlüsselzugriff durch ändern des Passwortes

[weshalb]

Hallo,

ich beschäftige mich gerade damit, das System etwas sicherer zu machen. Sich über Keyfiles anzumelden ist da eine gute Wahl, aber:

• der normale User hat den Key innerhalb seines Ordners, worüber ich dann auf die Shell komme und an Rootrechte gelange

• Jeder Angreifer mit physischem Zugriff auf das System, kann jedem User beim booten über das init=/bin/bash Prozedere ein neues Passowrt vergeben, womit er automatisch auch wiederum Zugriff auf den SSH Zugang hat

Heißt das, es wäre das Sicherste, den key selbst dann immer mit einem Passwort zu versehen? Ich würde es trotzdem besser finden, das init=/bin/bash Prozedere beim booten generell zu verbieten.

Geht das?

vielen Dank für Antworten

[eggy]

Dann steckst halt nen USB-Stick rein und bootest nen Livesystem von da. Solange die Platte nicht verschlüsselt ist, brauchst Du Dir um Bootloader und Co keine Gedanken machen, reine Zeitverschwendung.

Und SSH-Keys sollte man generell nicht ohne Passphrase ablegen.

[uname]

Man muss auch immer bedenken, dass man noch an das System kommen will, wenn man sich mal ausgesperrt hat. Gleiches gilt natürlich für das Backup. Wie schützt du das Backup?

[weshalb]

Dann steckst halt nen USB-Stick rein und bootest nen Livesystem von da. Solange die Platte nicht verschlüsselt ist, brauchst Du Dir um Bootloader und Co keine Gedanken machen, reine Zeitverschwendung.

Und SSH-Keys sollte man generell nicht ohne Passphrase ablegen.

Du meinst, dass soll für den SSH Zugang im laufenden Betrieb machen? Stelle ich mir kompliziert vor. Wobei, das System ist verschlüsselt, wo liegt da nun der Unterschied?

Man muss auch immer bedenken, dass man noch an das System kommen will, wenn man sich mal ausgesperrt hat. Gleiches gilt natürlich für das Backup. Wie schützt du das Backup?

Das wäre definitiv die nächste Baustelle. Um Backups beispielsweise auf ein anderes System zu schieben, benutze ich derzeit SSH-Keys ohne Abfrage, einfach aus dem Grund, da das sonst nicht klappt.

[MSfree]

Um Backups beispielsweise auf ein anderes System zu schieben...

Um Backups irgendwo hin zu schieben, braucht es am Backupsystem irgendwelche Freigaben, sei es Samba, NFS oder auch SSH. Das sind aber potentielle Schwachstellen, über die eine Verschlüsselungsschadsoftware auch Backups zerstören kann.

Ich würde an deiner Stelle darüber nachdenken, diesen Prozeß umzukehren und die Backups zu ziehen. Laß lieber das Backupsystem die Backups von Quellrechner holen. Das reduziert die Angriffsfläche des Backupsystems deutlich und erschwert Schadsoftware, Schaden am Backup anzurichten.

[eggy]

Du meinst, dass soll für den SSH Zugang im laufenden Betrieb machen? Stelle ich mir kompliziert vor. Wobei, das System ist verschlüsselt, wo liegt da nun der Unterschied?

Nein. Das war anders gemeint.

Ich hatte angenommen, dass Dein System nicht verschlüsselt sei, und Du Dir Sorgen machst, dass man durch entsprechende Parameter Zugriff auf die Keys bekommt, und Du deswegen die Möglichkeit diese Parameter zu nutzen ausschalten wolltest.
Daher meine Antwort, solange das System nicht verschlüsselt ist, kannst Du via Livesystem eh auf die Daten auf der Platte zugreifen. Also wenn die Keys unverschlüsselt auf dem Datenträger liegen, dann ist es auch völlig egal, wie sich dort jemand Zugriff verschafft.

Und dagegen, dass die Keys, falls sie doch mal in falsche Hände kommen, genutzt werden, schützt man sich durch ausreichend umfangreiche Passphrasen

[weshalb]

Ok, doch die Möglichkeit, den Usern und auch Root einfach neue Passwörter geben zu können, finde ich schon hart. Sowas müßte man unterbinden können, auch auf die Gefahr hin, sich selbst auszusperren.

Denn theoretisch spielt es somit dann auch keine Rolle mehr, wie stark mein Passwort ist.

Gut, lange Passphrasen für ssh key's sehe ich schon ein, doch gerade beim häufigen Arbeiten damit dann wieder nervig.

Den Mittelweg scheint es jedenfalls nicht zu geben.

[eggy]

Doch den gibt es, nennt sich ssh-agent, siehe "man ssh-add".

[fossonly]

Ok, doch die Möglichkeit, den Usern und auch Root einfach neue Passwörter geben zu können, finde ich schon hart. Sowas müßte man unterbinden können, auch auf die Gefahr hin, sich selbst auszusperren.

Denn theoretisch spielt es somit dann auch keine Rolle mehr, wie stark mein Passwort ist.

Seltsame Argumentation. Zumal es jedem frei steht seinem System via BIOS ein Passwort zu verpassen. Auch für grub selbst kann ein Passwort vergeben werden. Und wer sein System inkl. /boot (essentiell wichtig) verschlüsselt, dem kann es so hoch wie breit sein was via grub an Kernel-Parametern übergeben wird, wenn das Passwort zur Entschlüsselung der Festplatte schlicht fehlt. Darüber hinaus ist das im Ernstfall überaus praktisch, via grub Passwörter zurücksetzen zu können, schliesslich gibt es genug Möglichkeiten das abzusichern. Deine Sorgen sind somit unbegründet, wenn Du deine Möglichkeiten nutzt.

[weshalb]

@fossonly

Ok, dazu habe ich eine Frage. Beim installieren habe ich LVM mit Verschlüsselung angewählt. Ist damit ./boot dann ebenfalls automatisch verschlüsselt bzw. wie bekomme ich das raus?

[bluestar]

Ok, dazu habe ich eine Frage. Beim installieren habe ich LVM mit Verschlüsselung angewählt. Ist damit ./boot dann ebenfalls automatisch verschlüsselt bzw. wie bekomme ich das raus?

Soweit ich mich entsinne, wird /boot bei der Installation nicht standardmäßig mit verschlüsselt. Poste einfach mal die Ausgabe von

Code: Alles auswählen

mount | grep boot

[weshalb]

Ok, dazu habe ich eine Frage. Beim installieren habe ich LVM mit Verschlüsselung angewählt. Ist damit ./boot dann ebenfalls automatisch verschlüsselt bzw. wie bekomme ich das raus?

Soweit ich mich entsinne, wird /boot bei der Installation nicht standardmäßig mit verschlüsselt. Poste einfach mal die Ausgabe von

Code: Alles auswählen

mount | grep boot

Code: Alles auswählen

mount | grep boot
/dev/sda2 on /boot type ext2 (rw,relatime)
/dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)

[bluestar]

Code: Alles auswählen

mount | grep boot
/dev/sda2 on /boot type ext2 (rw,relatime)
/dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)

Dein /boot ist unverschlüsselt.

[weshalb]

Danke bluestar, das konnte ich mir schon fast denken. Irgendwo habe ich gelesen, dass das wohl auch gar nicht anders geht?

Ich werde mich mehr einlesen müssen, um zu sehen, was geht.

Ziel ist es, ein abgeschottetes System aufzubauen, welches durch physischen Eingriff nicht kompromittiert werden kann.

[eggy]

Halte ich für unmöglich.
Sobald Dir jemand das Keyboard austauscht, hat er Deine Passphrasen.
Und irgendwann muss jeder mal schlafen

[weshalb]

Halte ich für unmöglich.
Sobald Dir jemand das Keyboard austauscht, hat er Deine Passphrasen.
Und irgendwann muss jeder mal schlafen

Du verdirbst einem aber auch alles.

[bluestar]

Ziel ist es, ein abgeschottetes System aufzubauen, welches durch physischen Eingriff nicht kompromittiert werden kann.

Dann solltest du auf jeden Fall ein HSM und einen Safe zur Lagerung dessen verwenden

[MSfree]

Dann solltest du auf jeden Fall ein HSM ... verwenden

Meinst du wirklich, das ein HSM dagegen hilft, und warum sollte man den in einem Tresor lagern?

*SCNR*