[Warum wir die Maschine so aufsetzen…]
Nach der Installation des Minimal-Images von Debian 10 – Buster – loggen wir uns zum ersten mal in unser neues System ein.
Als Erstes müssen wir unseren SSH-Server auf “Schlüssel/Schloss” umstellen, da momentan ein “root”-Zugang mit “Passwort” eingestellt ist.
Danach ändern wir ein paar Systemeinstellungen und installieren “Docker”, weil wir den für alle unsere Folge-Tutorials brauchen werden… Legen wir los!
Normalerweise arbeite ich ja unter einem gesonderten Benutzeraccount. Für diese Tutorials ist es aber einfacher, das direkt als “root” zu machen. Durch das “Schlüssel/Schloss”-Verfahren bei SSH und einem geänderten SSH-Port fühle ich mich da einigermaßen sicher… Ich überlasse es jedem einzelnen, hier abzuwägen, ob er auch unter “root” arbeitet, oder sich einen Benutzer zulegt und dann jedes Mal mit “sudo” die nötigen Berechtigungen erlangt.
Jetzt loggen wir uns mit “root” und dem von Netcup eingerichteten Passwort über SSH auf Port 22 in den Server ein…
SSH-Server absichern / einrichten
Schauen wir uns mal um… Mit einem
ls -la
Bekommen wir folgende Ausgabe:
drwx------ 5 root root 4096 Aug 26 17:43 . drwxr-xr-x 18 root root 4096 Aug 25 17:26 .. -rw------- 1 root root 2129 Aug 26 11:01 .bash_history -rw-r--r-- 1 root root 1921 Aug 26 10:28 .bashrc drwx------ 3 root root 4096 Aug 26 10:54 .gnupg drwxr-xr-x 3 root root 4096 Aug 26 09:56 .local -rw-r--r-- 1 root root 148 Aug 17 2015 .profile drwx------ 2 root root 4096 Aug 26 10:08 .ssh
Wir sehen, dass unser “.ssh”-Verzeichnis schon angelegt ist. Das werden wir auch gleich benutzen…
Zur Erstellung des Schlüsselpaars und der genaueren Erklärung des Vorgangs verweise ich auf die folgenden Tutorials:
- Schlüsselpaare erstellen mit puttygen
- SSH absichern – vom Passwort zum Schlüssel
Den öffentlichen Schlüsselteil legen wir in der “authorized_keys”-Datei auf dem Server im “.ssh”-Verzeichnis ab:
nano ~/.ssh/authorized_keys ### Schlüssel per Copy/Paste hier her kopieren ssh-rsa AAAAB3NzaC1yc2EAAAABJQAABAEAmQneFHXbCt3MerYO9a5xfSCA7/0qasiMugCTYpJm19WV9tmN.........
Mit einem “Strg+x” und “y” speichern wir die Datei ab. Jetzt ändern wir noch die Zugriffsberechtigung:
chmod 0600 ~/.ssh/authorized_keys
Damit bekommt nur noch “root” Zugriff und niemand sonst darf diese Datei öffnen.
Gut, im nächsten Schritt verschieben wir die Konfigurationsdatei von sshd – unserem SSH-Server – und legen eine neue mit unseren geänderten Werten an. Hervorzuheben ist die geänderte Port-Nummer, auf die wir dann achten müssen, wenn wir uns mit dem Client verbinden…
mv /etc/ssh/sshd_config /etc/ssh/sshd_config_orig nano /etc/ssh/sshd_config Port 44422 PubkeyAuthentication yes PasswordAuthentication no ChallengeResponseAuthentication no PermitRootLogin prohibit-password UsePAM yes X11Forwarding yes PrintMotd yes AcceptEnv LANG LC_* Subsystem sftp /usr/lib/openssh/sftp-server
Jetzt starten wir den SSH-Server neu:
systemctl restart ssh
Wichtig!
Wir *müssen* jetzt die SSH-Verbindung offen lassen und uns *zusätzlich* neu mit dem Schlüssel auf Port 44422 verbinden. Erst, wenn diese Verbindung steht, dürfen wir die alte zu machen. Sonst sperren wir uns im schlimmsten Fall selbst aus!
Wenn die Verbindung funktioniert, beenden wir die alte Sitzung mit “Strg+d” oder wir schreiben “exit” ins Terminal.
Vielen Dank für dieses sehr gut verständliche Tutorial! Es wird dem erklärten Anspruch (alle Schritte von A-Z erläutern) gerecht.
Ich bin gerade noch in der Entschlussphase, habe es also bislang nur theoretisch nachgespielt. Dabei ist mir die Frage gekommen, warum die Entscheidung bei einem Versionen-basierten System wie Debian (nicht rolling-release wie Arch Linux, das ich privat verwende), was ja für einen Server eine sehr richtige Wahl ist, bei der Partitionierung eine einzelne große Partition gewählt werden soll, anstatt dass eine Partition für / (root) und eine weitere für /home und /var erstellt wird? Sollte dann mal ein Versions-Upgrade von Buster auf Bullseye durchzuführen sein, bleibt bei getrennten Partitionen die zweite Partition vom Upgrade unangetastet. Gut, die ganzen Dotfiles sollte man vorher trotzdem sichern, wenn die Einstellungen hinterher wieder gleich sein sollen. Wie siehst Du das?
Nochmals vielen Dank!
Tilmann
Hallo Tilmann,
danke für Deinen Beitrag!
Hmm… Du hast recht, ich muss dringend im Vorspann meine Server-Situation näher erklären. Daraus ergibt sich dann, warum ich das so mache, wie ich es mache:
Mit Arch hatte ich ein traumatisches Erlebnis. Server Purge. Alles hin. Ganz normal Updates gezogen, installiert, Start – Kaputt. Ein Verschlüsselungsmodul hat sich da getauscht, ich konnte nicht mehr entschlüsseln und aus die Maus.
Debian und Ubuntu haben ja gute 5 Jahre Laufzeit, in denen die Version Support erfährt. Und danach steht bei mir sowieso ein neuer Server an, weil die Hardware sich in der Zeit dramatisch weiterentwickelt hat und man fürs gleiche Geld die dreifache Leistung bekommt – oder halt für einen ähnlichen Server weniger zahlen muss.
Warum ich selten die ganze Support-Zeit ausgereizt hab, war schlicht die Tatsache, dass irgendwann eine Bibliothek des Kernsystems veraltet und nicht mehr gepatcht wird. PHP 5.6 war damals so ein Fall. Da muss man dann auf ein aktuelles Betriebssystem zwangsumsteigen.
Aber genau hier kommt das Docker-Prinzip ins Spiel! Und aus dem Grund ist mir die Umgebung vom Host auf einmal nicht mehr wichtig. So lange das System noch Sicherheitsupdates bekommt, bin ich glücklich. PHP ist in den Containern aktuell. Genau wie die Datenbank und der Webserver.
Für mich macht es daher keinen Sinn, die Verzeichnisse in Partitionen zu unterteilen, weil ich sowieso kein Update des Betriebssystems machen werde. Am Laufzeitende stirbt es zusammen mit dem Server. Und ein neuer Server wird geboren, der dann wieder fünf Jahre halten wird. So Gott will :)
Wenn jemand einen anderen Update-Zyklus fährt oder die Partitionen entsprechend anlegen möchte, kann er das natürlich gerne machen. Aber für meinen Fall macht es, wie dargelegt, halt keinen Sinn.
Beste Grüße
Peter.
Guten Abend, Peter,
danke sehr für die Erklärungen. Wieder mal sehr verständlich (anders als meine verschachtelten Sätze…). Ich plane nicht, Arch für den Server zu nehmen, dafür ist Debian tatsächlich besser geeignet. Und ich hatte den langen Support für die Server-Version ausgeblendet, das ist natürlich in Kombination mit der technischen Weiterentwicklung ein echtes Argument.
Da ich bisher mit Docker nicht gearbeitet hatte, war mir auch nicht bewusst, dass die darin enthaltenen Komponenten unabhängig vom zugrundeliegenden Basissystem aktuell gehalten werden. Mir war nur bewusst, dass sich die unterschiedlichen Docker-Container nicht wechselseitig beeinflussen. Gutes Konzept.
Danke + Gruß
Tilmann
Moin Peter
da ich win nur auf einem Noti habe und seit letzen November linuxmint benütze, habe ich Probleme die Schlüssel von Putty zu übernehmen.
In der Linux-Konsole komme ich vor der Absicherung des Ports problemlos rein.
Dann aber abgesichert erscheint direkt nach dem Befehl:
ssh root@192.168.1.130 -p 44422 die Antwort
root@192.168.1.130: Permission denied (publickey).
Wie muss ich das in der Linux-Konsole händeln, damit es klappt?
Hallo Jakob,
Du musst dem ssh-Befehl auch den Schlüssel an die Hand geben.
Wenn Du Deine Schlüssel im .ssh Ordner von Root abgelegt hast, sollte der Befehl wie folgt heißen:
ssh -i ~/.ssh/id_rsa[bzw-wie-du-deinen-schlüssel-genannt-hast] -p 44422 root@192.168.1.130
Beste Grüße
Peter.
Hallo Peter
Danke für die Angaben. Ich habe aber im root-Ordner nur ~/.ssh/authorized_keys
Gruss Jakob
Du erstellst ja irgendwo das Schlüssel-Schloss-Paar. absichern.
Die Datei, die dabei raus kommt, die musst Du in das .ssh Verzeichnis legen. Und mit chmod 600
Ich habe mir auf einem VPS einen Teil Deiner Installation, also Traefik, Nextcloud und WordPress installiert. Ich wundere mich aber warum Du an keiner Stelle eine Firewall einrichtest??
Ich habe mir dann UFW so eingerichtet, wie ich es für andere Linux Server auch getan hätte, bin dann aber darüber gestolpert, dass Docker die Regeln der UFW außer Kraft setzt und die UFW somit nicht wirklich die Docker Container schützt.
Von Extern konnte ich per Telnet server.mydomain.de 49156 direkt auf meinen Nextcloud Server zugreifen unter Umgehung von traefik.
Tante Google sagt mir dazu, dass dies ein bekanntes Problem ist, aber eine Dummylösung noch nicht wirklich vorhanden. Was ist Deine Meinung? Brauche ich bei Deinem Setup keine Firewall?
Gruß
Norbert
Hallo Norbert,
wie ich im Tutorial geschrieben habe, verwendete ich früher eine Shorewall, um Docker nach außen zu schließen. Was aber alles andere als “gut” funktioniert hat.
Sicherheit ist durchaus wichtig. Aber was hilft es, wenn der Container direkt von außen erreichbar ist? Das ist auch nichts anderes, als wenn er über Traefik durchgereicht würde. Eine Sicherheitslücke in der Anwendung kann auf die eine wie auf die andere Weise ausgenutzt werden. Die Nextcloud blockt eine Verbindung über “IP:Port” ab, weil diese Verbindung nicht als “vertrauensvolle Domain” konfiguriert ist. “Subdomain.Domain:Port” lässt die Verbindung nicht zu, weil kein SSL-Tunnel aufgebaut werden kann.
WordPress das Gleiche in gelb.
Die Datenbank wäre eventuell gefährlich. Aber die wird nur auf das Loopback-Device auf dem Host gelegt und nicht geroutet.
Klar wäre mir eine Firewall auf dem Server lieber. Aber ich hab kein vernünftiges Vorgehen dafür gefunden. Und alle anderen Tutorials, die ich besucht habe, lassen Docker auch so auf dem Server laufen.
Solltest Du über eine Anleitung stolpern, wie man eine Firewall in das Setup integriert bekommt, wäre ich Dir für einen Hinweis sehr dankbar…
Beste Grüße
Peter.
Kleiner Vertipper gefunden: Benutzer zulegt und dann jedes Mal mit „sodo“ die nötigen Berechtigungen erlangt.
Soll wohl nicht “sodo”, sondern “sudo” heißen.
Das ist absolut korrekt, da hab ich mich verhaut! Vielen Dank für den Hinweis…
Ist echt einer meiner “Standard-Vertipper” :/
es menschelt …. schön
Vielen Dank für die Howtos, tolle Arbeit und sehr versändlich.
… aber ;-) :
Warum installierts du noch den NTP-Server? Die Maschine wird doch mit dem Systemd-Timesync aktuell gehalten. Ist das dann nicht Doppelt, da ja auch der ntp die Urzeit stellen kann?
Hallo Sven,
danke für Deine Rückmeldung!
Einen Server hatte ich, da lief die Uhrzeit wirklich nicht synchron, was allerlei seltsame Fehler provoziert hat.
Seit ich zusätzlich den ntp (oder ganz neu: Chrony) installiert hab, hatte ich keine Probleme mehr.
Beste Grüße
Peter.
Moin Peter,
dann lieber Chrony anstelle von ntp, da Chrony keine Ports nach außen öffnet. und dann kann man auch den systemd-timesyncd abschalten.
viele Ostergrüße
Sven
Hast Recht, Sven, da bau ich das Tutorial um an der Stelle…
Wünsch Dir auch frohe Ostern :)
Hab die gesamte Anleitung schon zum zweiten mal zur Hand.
Funktioniert richtig smart :)
Danke
Nice, Herzlichen Dank, bis auf den Hostnamen ändern, (werde ich machen wenn ich es brauche) hat alles wunderbar Funktioniert, Vielen Vielen Dank
etz muss ich nur noch CSGO zum laufen bringen mit Docker, dann ist alles Perfekt :D
Hallo Rainer,
vielen Dank für das Lob!
Hoffe, dass deine restliche Installation auch noch einwandfrei läuft :)
Liebe Grüße
Peter.
Hi, ich hab ein Problem mit der Blauen Schrift, meine Augen sind nicht mehr die Besten, kannst du Bitte die Blaue Farbe in etwas Blaueres ersetzen?
müsste ja :
PS1=’${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ ‘ hier sein oder ?
Wenn ich nun die Blaue mit Cyan auswechseln möchte, muss ich da denn die 34m mit 36m ersetzen oder?
Gute Frage. Wahrscheinlich überschreibt mein MobaXterm das Schema. Bei mir sieht der farbige Prompt so aus: Color Prompt
Beim puTTY gibt es auch Einstellungen für Farbe und zwar bei Window – Colours.
Ich meine, dass der Hund hier begraben ist…