Umgang mit SSH-Keys und Passwörtern bei mehreren Servern

  • Hi Leute, ich habe mal eine Frage:


    Wie regelt ihr das so mit den SSH-Keys und Passwörtern von verschiedenen Servern? Da ich von mehreren Geräten auf meine Server zugreife, habe ich mir einen zentralen Key generiert, mit dem ich mich bei jedem Server als normaler User anmelden kann. Passwort-Authentifizierung und Root-Login ist überall deaktiviert. Da es ja eh keinen Unterschied macht, ob ich per sudo Root-Rechte erhalte oder per su, sollte es doch auch kein Problem sein wenn das Root-Passwort dem des normalen Users entspricht, oder? Wenn ich für jeden User und Server andere Passwörter und Keys generieren würde, müsste ich ja immer eine lange Liste der Passwörter mitschleppen, die ich ja leider auch verlieren könnte...


    Wie handhabt ihr das so? Ist es sinnvoll, einen VPS 200 zu mieten und den SSH-Zugriff der anderen Servern nur noch vom VPS 200 zuzulassen?


    Und noch eine weitere Frage: Ich habe einen Server, den ich für die Backup-Speicherung der anderen Server nutze. Ist es sinnvoller, per rsync vom Backup-Server auf die anderen Server zuzugreifen, oder sollten lieber die anderen Server Zugriff auf den Backup-Server haben? Im Moment läuft meine Sicherung über ein stündliches Cronjob auf dem Backup-Server, der nur Zugriff auf die jeweiligen /var/backups/-Verzeichnisse hat.


    LG

    mfnalex

    Meine Minecraft-Plugins auf SpigotMC (Open Source): www.spigotmc.org/members/mfnalex.175238/#resources

    Discord: discord.jeff-media.com

  • Da ich von mehreren Geräten auf meine Server zugreife, habe ich mir einen zentralen Key generiert, mit dem ich mich bei jedem Server als normaler User anmelden kann.

    Idealerweise hast Du einen Key pro Gerät. Wird eines z.B. gestohlen müsstest Du aktuell Deinen Key auf allen anderen Geräten austauschen.


    Ist es sinnvoll, einen VPS 200 zu mieten und den SSH-Zugriff der anderen Servern nur noch vom VPS 200 zuzulassen?

    Ich mache es demnächst so, aber nur weil ich mir aus Sicherheitsgründen eh ein on-demand-VPN erstelle, in welchem sich meine Geräte befinden müssen um ins Internet zu gehen. Im Grunde ist ein SSH-Server mit Key-Authentifizierung auch so schon sehr gut abgesichert.


    Und noch eine weitere Frage: Ich habe einen Server, den ich für die Backup-Speicherung der anderen Server nutze. Ist es sinnvoller, per rsync vom Backup-Server auf die anderen Server zuzugreifen, oder sollten lieber die anderen Server Zugriff auf den Backup-Server haben? Im Moment läuft meine Sicherung über ein stündliches Cronjob auf dem Backup-Server, der nur Zugriff auf die jeweiligen /var/backups/-Verzeichnisse hat.

    Am sichersten ist es, wenn sich der Backup-Server auf den anderen Servern anmeldet um die Sicherung durchzuführen. Sollte ein Server kompromittiert werden könnte sich der Angreifer ja sonst auch auf den Backup-Server anmelden und die Backups löschen. Es gibt aber auch andere Wege das sicher zu gestalten. Ich nutze borg für meine Backups, und da ist eine entsprechende Vorgehensweise gut dokumentiert: https://borgbackup.readthedocs…tes.html#append-only-mode

  • Ganz knapp wie es bei mir ist:

    • SSH läuft bei mir über den gpg-Agent, damit ich meinen YubiKey benutzen kann; sprich mein PrivateKey ist am Schlüsselbund -> 3 Passwort-Versuche (bzw. 6) dann für immer unbrauchbar. Dieser Key gilt als "personengebunden" ist also überall der selbe.
      • Dann habe ich Backups-Keys je Kunde auf einer verschlüsselten Festplatte zu Hause (gelten für mich also nicht als personengebunden; deshalb je Kunde unterschiedlich)
    • Bastion-Host (das man sich über einen zentralen Server auf die anderen tunnelt) - Grund dafür ist übrigens, dass ich dort ansible benutze - der personengebundene Key ist sowieso auf jedem Server
    • backups werden "gepullt"; also vom Backup-Server "abgeholt" / angefertigt

    Was ich noch möchte ist, dass meine Server auch per VPN verbunden sind (tinc hatte ich da mehrmals gelesen), damit interne Wartungsdienste wie SSH nur noch auf das entsprechende Interface lauschen und so die Angriffsfläche weiter verringert wird.

  • [Nur meine Meinung; muss man natürlich nicht so machen!]


    Ich verwende vier verschiedene Key-Typen: Default (z.B. Desktop PC), Server (manchmal ohne Passphrase), Mobile (z.B. Smartphone) und Portable (ein altes Relikt das ich eigentlich nicht mehr brauche)


    Für jedes System und jeden (SSH) User gibt es diese Schlüssel separat. Das sind in Summe sehr viele Keyfiles (mindestens 4-8 je Server), aber da ich nicht auf jedem Gerät alle Schlüssel vorhalte, ist der Schaden bei einer Kompromittierung (eines Mobilgerätes) relativ gering. Ich kann die schnell überall entfernen und habe trotzdem noch funktionierende Schlüssel, um irgendwie auf den Server zu kommen.


    Zusätzlich bin ich so paranoid, dass die meisten meiner SSH-Zugänge nur aus einem zentralen VPN erreichbar sind. Das brauche ich sowieso für andere Zwecke auch. Fürs VPN gibt es pro Endgerät wieder eigene Zertifikate, die ich jederzeit widerrufen kann. Da es für Außenstehende eh schon zwei Barrieren gibt, logge ich mich mit Keyfiles direkt als root ein. Ich brauche somit für administrative Aufgaben kein su/sudo mehr. Das root Passwort brauche ich maximal für die VNC-Konsole, das muss ich mir nicht merken und nicht andauernd mitschleppen. Notfalls gibt es bei jedem Anbieter einen Recovery-Modus, mit dem man es temporär zurücksetzen kann.


    Bei Backups sehe ich das wie Ringelnatz – das zu sichernde System sollte keinen Zugriff auf das Backupstorage haben. Umgekehrt ist immer zu bevorzugen. Auf einem System, wo es anders nicht machbar war, habe ich es so gelöst, dass ein Cronjob am Backupserver die hochgeladenen Backups in einen Ordner verschiebt, auf den der Uploaduser keinen Zugriff mehr hat. Die neuesten Backups sind maximal ~1 Stunde "gefährdet".

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Danke für die Antworten! Werde demnächst sowieso alle Dienste von einem RS 2000 G7 auf einen RS 2000 G8 und mehrere VPS 200 verteilen, und mir dann nochmal Gedanken machen, ob ich wirklich verschiedene Keys pro Server benötige.


    Wahrscheinlich mach ich das so: Ein Key für meinen PC, einen fürs Handy, einen für den Laptop usw. Mit jedem dieser Keys kann ich mich dann zu einem zentralen Hub (VPS 200) verbinden, auf dem ein weiterer Zentral-Key liegt, mit dem ich auf die anderen Servern zugreifen kann. So bräuchte ein Angreifer dann einen meiner privaten Keys, die Passphrase und zusätzlich die Passphrase des Keys auf dem Hub. Ach ja, und das sudo-Passwort auf dem anzugreifenden Server :)

    Meine Minecraft-Plugins auf SpigotMC (Open Source): www.spigotmc.org/members/mfnalex.175238/#resources

    Discord: discord.jeff-media.com

  • Ich habe alle Passwörter und Keyfiles in einem Keepass Password Safe. Verschlüsselt mit einem sehr guten Passwort welches nur in meinem Kopf gespeichert ist.

  • Hab noch einmal eine Frage bezüglich Backups:


    Ich habe auf dem Backup-Server ein Script, dass per Rsnapshot auf backup@hauptserver zugreift. Leider kann ich damit jedoch zb nicht das /root/-Verzeichnis sichern. Welche Möglichkeiten habe ich, einen "Read-only"-User anzulegen, der zwar alle Dateien lesen, aber keine schreiben darf?

    Meine Minecraft-Plugins auf SpigotMC (Open Source): www.spigotmc.org/members/mfnalex.175238/#resources

    Discord: discord.jeff-media.com

  • Hi,


    Inwiefern es sinnvoll ist /root/ zu sichern, oder überhaupt dort Daten zu lagern mal ungeachtet:

    Um mit einem User sinnvoll Daten anderer User anzufassen kannst du dir mal bindfs anschauen.


    https://unix.stackexchange.com…8590/what-is-a-bind-mount


    Den Mount kannst du z.B. als Root ausführen und sagen, dass der einem anderen User gehört als Readonly.

    Meine (Netcup) Produkte: S 1000 G7, VPS 200 G8 Ostern 2019, IPs, Failover..

  • Danke für die Antwort. /root/ war nur ein Beispiel. Es geht unter anderem um Dateien wie z.B. /etc/shadow, die ich sichern möchte, aber nur als root lesbar sind. Die Lösung mit mount klingt interessant, muss ich mir nachher mal genauer ansehen.

    Meine Minecraft-Plugins auf SpigotMC (Open Source): www.spigotmc.org/members/mfnalex.175238/#resources

    Discord: discord.jeff-media.com

  • Ganz knapp wie es bei mir ist:

    • SSH läuft bei mir über den gpg-Agent, damit ich meinen YubiKey benutzen kann; sprich mein PrivateKey ist am Schlüsselbund -> 3 Passwort-Versuche (bzw. 6) dann für immer unbrauchbar. Dieser Key gilt als "personengebunden" ist also überall der selbe.
      • Dann habe ich Backups-Keys je Kunde auf einer verschlüsselten Festplatte zu Hause (gelten für mich also nicht als personengebunden; deshalb je Kunde unterschiedlich)
    • Bastion-Host (das man sich über einen zentralen Server auf die anderen tunnelt) - Grund dafür ist übrigens, dass ich dort ansible benutze - der personengebundene Key ist sowieso auf jedem Server
    • backups werden "gepullt"; also vom Backup-Server "abgeholt" / angefertigt

    Was ich noch möchte ist, dass meine Server auch per VPN verbunden sind (tinc hatte ich da mehrmals gelesen), damit interne Wartungsdienste wie SSH nur noch auf das entsprechende Interface lauschen und so die Angriffsfläche weiter verringert wird.

    Ich hab das Ganze sehr ähnlich gemacht - nur sind meine Backup-Keys auch wieder YubiKeys. Einen davon trage ich am Schlüsslebund, und der ist immer in meiner Nähe. die anderen beiden YubiKeys sind ohne besondere Kennzeichnung in einem Briefumschlag in Safes gelegt. Alle YubiKeys haben verschiedene PINs/PUKs. Gleichzeitig verwende ich auf allen Servern sowohl SSH Agent Forwarding als auch GPG Agent Forwarding (https://mlohr.com/gpg-agent-forwarding/). Das ermöglich mir, selbst auf Remote-Systemen z. B. Git Commits zu signieren oder Daten zu entschlüsseln, ohne, dass der Private Key jemals übers Netz gehen müsste (bzw. gehen kann, der YubiKey spuckt den nämlich nie wieder aus).

    Matthias Lohr Project Blog: https://mlohr.com/

    PGP: 0x8FC3060F80C31A0A

  • ich kopiere auf alle meine vServer, VMs ins Verzeichnis /root/.ssh den entsprechenden File,

    weiters blockiere ich den SSH per iptables von überall außer dem Netz meines ISPs; per ip6tables tatsächlich nur aus meinem Netz (HE-Tunnel),

    wobei ich das so definiere, daß meine IP tatsächlich direkt durchgeht und andere maximal eine bestimmte Anzahl

    an Verbindungsaufbaus je Zeitheit haben;


    Code
    # Enable SSH (private)
    -A INPUT -i eth0 -s #MYIP# -m tcp -p tcp --dport 22 -m state --state NEW  -j ACCEPT
    -A INPUT -i eth0 -s #BLOCKx-OF-ISP# -m limit --limit 1/min -m tcp -p tcp --dport 22 -m state --state NEW -j ACCEPT
    ...
    -A INPUT -i eth0 -m tcp -p tcp --dport 22 -m state --state NEW -j DROP


    daß jemand jetzt meinen PC hackt und so auf das Gegenstück kommt ist weniger wahrscheinlich,

    als daß mir jemand ein Auto klaut ...

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • Mh. Du erlaubst root-Zugriff per SSH? Ist zum Beispiel eine Sache, die ich auch grundsätzlich nicht mache. Man brauch etwas, was nur ich besitze (meinen private key (in Form des YubiKey) für den normalen SSH-Login) und dann etwas was nur ich kenne (mein Passwort) für ein sudo. Also root nur über so etwas wie 2FA. SSH für root offen ist - egal wie per Firewall eingeschränkt - m. E. mutig.


    Ich hab bei mir grundsätzlich root-Login per SSH deaktiviert, außerdem gibts bei mir auch für SSH kein PW-Auth, nur PublicKeyAuth...

    Matthias Lohr Project Blog: https://mlohr.com/

    PGP: 0x8FC3060F80C31A0A

  • wieso sollte ich mir das Leben schwer machen?

    ich halte es f. einen schlechten Scherz, dem root zwar die Mglkt zu nehmen sich direkt per SSH anzumelden,

    aber dafür weltweit den SSH-Dienst offen zu haben ...

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • - 2FA

    - Schutz vor eigener Dummheit


    sind 2 Faktoren, die den Zugang über einen normalen Nutzer für mich sinnvoll machen. Brauche ich root Rechte kann ich mir diese nehmen, arbeite dann aber auch bedachter. Unter dem normalen Nutzer kann ich nichts kaputt machen.

    Zum Thema SSH weltweit offen kann ich nur sagen: Port ändern. Seit ich meinen SSH überall auf nem anderen Port laufen hab ist das log für failed auths leer.

  • Wer den Port zum SSH ändert, sollte im Falle, wenn was nicht funktioniert, dies immer im Hinterkopf behalten;

    sshfs, scp, sftp als Beispiele zu nennen, die neben dem eigentlichen SSH-Terminal auch verbreitet/bekannt sind;

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • Dafür gibt es doch die ~/.ssh/config.


    Macht eigentlich auch jemand Security by Obscurity mit z.B. SMTP oder http?


    btw ich finde so was immer sehr lustig, wenn mein shodan.io Webbrowserplugin mir so was direkt anzeigt. Ich finde nur eine Begrenzung auf bekannte IP-Ranges sinnvoll. Im worst case gibt es ja immer noch die Konsole per scp.

    "Security is like an onion - the more you dig in the more you want to cry"

  • Habe das Verschieben des SSH Ports schon vor Jahren aufgegeben. Macht einfach keinen Sinn. Speziell wenn man über Internet Anschlüsse unterwegs ist, welche ne restriktive Firewall (Unternehmen, Arbeitgeber, etc) haben, ist das nur hinderlich.


    Ansonsten habe ich vor kurzem via Ansible auf allen Systemen einen separaten Admin-User, sudo, eine sudo Gruppe, ein sicheres Passwort für den Admin-User und einen SSH Key ausgerollt. Zugriff via Passwort kann ausschließlich via OpenVPN Verbindung erfolgen (Stichwort Match Address Rule in sshd_config).


    Mittelfristiger Plan ist es, Kennwort und Key alle paar Monate komfortabel austauschen zu können. Klappt soweit ganz gut.

  • Macht eigentlich auch jemand Security by Obscurity mit z.B. SMTP oder http?

    so ähnlich, mein vServer der u.a. als mein Mailserver fungiert ist nur mit IPv6 erreichbar,

    sprich der Submission Port 587 ist nur unter IPv6 erreichbar; und da auch nur f. meine eigene IPv6-Adresse per IP6tables Regel;

    analog bei Seiten, mit denen ich etwas administrier per HTTPS, ebenfalls per IP6tables Regel nur f. meine eigene IPv6-Adresse freigeschalten;

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • Bin ich der Einzige, der hauptsächlich auf das gute alte Passwort und nen geänderten SSH Port zurückgreift? Bzw. sah ich bis jetzt keinen Sinn darin, den root Login zu unterbinden. Bei Login, egal von wo erhalte ich eh ne Pushnotification direkt aufs Smartphone. Backups werden regelmäßig durchgeführt, ... zur Not nehm ich den Server einfach vom Netz :D

    Einzig und allein wegen Ansible hab ich nun mal SSH Keys eingesetzt, ... aber auch auf allen Maschinen den Gleichen - haha.

    Naja macht wohl auch nen Unterschied, was auf den Maschinen läuft. Bei mir zu 100% privates Zeug der Kategorie just4fun. Sollte davon mal was nicht erreichbar sein, ... so what. Gibt schlimmeres. Private Mails laufen über HE, das ist das Einzige worauf ich angewiesen bin :)


    Bei Kundendaten oder geschäftlichen Dingen würde ich wohl auch auf nen VPN setzen und verschieden Logins/Profile

    Meine Produkte: definitiv zu viele, RS, VPS, Domains, Webhosting, ...