Passwörter und Konfig's sichern

[weshalb]

Hallo, ich suche nach einer vernünftigen Strategie, Passwörter und Konfigurationen auf meinem Debianserver su sichern.

Bisher ist es so, dass ich zu Rechner xyz eine Datei mit Name des Rechners, IP, User + Passwort, SSH Port etc. abgelegt habe, welche zusätzlich nachts gebackupt werden. Das ist natürlich eine schlechte Lösung.

Nun dachte ich an sowas wir KeePass, doch da ich teilweise mit vielen Passwörtern gleichzeitig arbeite, ist mir das auf Dauer zu umständlich. Dann dachte ich daran, dass man den Ordner mit den Konfigs verschlüsseln sollte, doch funktioniert das dann auch noch mit den Backups (sichere über Rsnapshot)? Fragen über Fragen.

Für Anregungen wäre ich sehr dankbar.

[eggy]

Wozu Passwörter sichern? Die setzt man im Bedarfsfall neu. Passworttresore sind grundsätzlich sinnvoller als ne Textdatei. Was die vielen Passworte angeht: Klingt, als wenn Du noch immer ssh mit Passwort Login erlaubst? Keine gute Idee. Stell das mal auf Keys um. Dann reicht es auch den Key zu backuppen. Und informier dich mal was nen ssh-agent kann.
Was die Konfigs angeht: etckeeper auf den Servern und das Repo entsprechend sichern wäre eine Lösung, hat man viele Maschinen bieten sich Lösungen wie Ansible an.

[MSfree]

Was die vielen Passworte angeht: Klingt, als wenn Du noch immer ssh mit Passwort Login erlaubst? Keine gute Idee. Stell das mal auf Keys um.

Meine SSH-Keys sind mit einer Passphrase gesichert. Um das Merken eines Paßwortes oder (was eigentlich das gleiche ist) einer Passphrase, kommt man also nicht herum.

SSH-Keys ohne Passphrase halte ich sogar für noch unsicherer als SSH mit Benutzer/Paßwort zu erleauben.

[DeletedUserReAsG]

SSH-Keys ohne Passphrase halte ich sogar für noch unsicherer als SSH mit Benutzer/Paßwort zu erleauben.

Definitionssache. Das typische Szenario bei SSH: Bots, die allerhand User/PW-Kombis durchprobieren. Das hat bei Verwendung eines Schlüsselpaares, auch ohne Passphrase, naturgemäß gar keine Aussicht auf Erfolg mehr.

Wenn ein Angreifer erst auf meine lokale Maschine geht, sich dort den Schlüssel schnappt und damit dann auf meine entfernte Maschine zugreift, habe ich wohl ’n erheblich größeres Problem – ob nun mit, oder ohne Passphrase.

[MSfree]

Wenn ein Angreifer erst auf meine lokale Maschine geht, sich dort den Schlüssel schnappt und damit dann auf meine entfernte Maschine zugreift, habe ich wohl ’n erheblich größeres Problem – ob nun mit, oder ohne Passphrase.

An den Schlüssel unter ~/.ssh kommt unter Umständen sogar ein Internetbrowser ran. Von da ist der Weg zum Angreifer nicht mehr sehr weit. Ist der Schlüssel mit einer Passphrase geschützt, fängt der Angreifer mit dem Schlüssel gar nichts an, ohne Passphrase hat er einen einfachen Zugang zu dem Server, für den der Schlüssel gilt.

[DeletedUserReAsG]

An den Schlüssel unter ~/.ssh kommt unter Umständen sogar ein Internetbrowser ran.

Ist ein Argument. Allerdings weiß der Angreifer dann noch nicht, wo der Schlüssel überhaupt zu welchem Usernamen passt. Wenn er es weiß, hatte er’s gezielt auf mich abgesehen – und dann hätte ich wohl ’n erheblich größeres Problem, ob nun mit, oder ohne Passphrase. Dann wäre auch die Kombi User/PW wieder sicherer, als User/Key mit Passphrase: bei Ersterem bremst der sshd Brute&Force massiv aus und protokolliert jeden Versuch.

Natürlich bietet ’ne Passphrase einen zusätzlichen Schutz, aber dennoch würde ich Schlüsselpaare ohne Passphrase sicherheitstechnisch immer noch über User/PW (oder noch schlimmer: root/PW) einordnen.

[eggy]

@msfree: Hab ich irgendwo gesagt, dass er die Keys ohne Passphrase erstellen soll? nein.
Der Vorteil von Keys ist eben auch, dass es vertretbar ist, bei vielen Keys die selbe Passphrase zu nutzen oder sogar einen Key für diverse Server. Dann hält sich der Merkaufwand in Grenzen und als Gedächnisstütze reicht nen Zettel untern Kopfkissen. Und selbst nen passphraseloser Key ist sicherer als das Klartextpasswort in ner Textdatei.

[weshalb]

Wozu Passwörter sichern? Die setzt man im Bedarfsfall neu. Passworttresore sind grundsätzlich sinnvoller als ne Textdatei. Was die vielen Passworte angeht: Klingt, als wenn Du noch immer ssh mit Passwort Login erlaubst? Keine gute Idee. Stell das mal auf Keys um. Dann reicht es auch den Key zu backuppen. Und informier dich mal was nen ssh-agent kann.
Was die Konfigs angeht: etckeeper auf den Servern und das Repo entsprechend sichern wäre eine Lösung, hat man viele Maschinen bieten sich Lösungen wie Ansible an.

Ok, Anmeldung über Key verstehe ich ja noch, doch nehmen wir mal das Beispiel> Ein Server mit zwei VM's
1 x MAILSERVER und 1 x Cloudserver, auf dem Host läuft Samba und Backup.

Da kommen eine Menge Usernamen und Passwörter zusammen, die ich irgendwo schnell abrufen und am Besten per Copy & Paste auch immer wieder irgendwo schnell verfügbar haben sollte, wenn ich etwas einrichten muss. Auch die Konfigs sind immer wichtig und ETC Keeper bedeutet, dass ich in den Konfigs irgendwo lesen muss, statt Port xyz gleich aus der ultimativen Txt Datei rauszulesen.

Wäre es da nicht eventuell besser, diese Dateien einfach nur zu verschlüsseln?

[DeletedUserReAsG]

Wäre es da nicht eventuell besser, diese Dateien einfach nur zu verschlüsseln?

Achso, du wolltest nur ’ne Bestätigung. Ja dann: kannst so machen, ist ganz toll so.

[slu]

Wir haben die Kombination KeePassXC mit YubiKey 5 NFC.

[TRex]

ich find pass ganz toll. Basiert auf git und gpg, damit kriegst du auch deine Replikation und Backup billig hin.

[weshalb]

ich find pass ganz toll. Basiert auf git und gpg, damit kriegst du auch deine Replikation und Backup billig hin.

Das gucke ich mir gleich mal an, da ich eher etwas für die command line suche.

Edit: Danke TRex, eine super Sache ist das.