Dieses Tutorial ist VALID.

Bitte lies Dir den Disclaimer durch, bevor Du eine Anleitung umsetzt...

Haftungsausschluss / Disclaimer

Debian 10 (Buster) Installation Teil 2 – Basissystem einrichten

[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:

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.

Anzeige *

25 Kommentare zu „Debian 10 (Buster) Installation Teil 2 – Basissystem einrichten“

  1. Guten Tag Peter,
    ich versuche gerade deinem Tutorial zu folgen. Nun bin ich aber auf ein Problem gestoßen. Ich kam bis kurz vor der Docker-Installation. Den Reboot habe ich noch mitgemacht.
    Danach klappte nichts mehr.
    – get-docker schlug fehl
    – apt update schlug fehl etc.
    Nach einer ganzen Weile verzweifelten googlens hatte ich einen Verdacht. und schaute mal in die /etc/resolv.conf:
    nameserver 2001:*:*:*:*:*:1 (natürlich zensiert wegen NSA und so :D )
    nameserver 2001:*:*:*:*:*:2
    Natürlich habe ich auch mal geschaut, wer das ist. Tatsächlich ist es mein Server-Anbieter. Trotzdem habe ich aus Frust die Datei um nameserver 8.8.8.8 ergänzt. Nun startet sudo apt update wieder. Es hängt ein Weilchen auf 0% und legt dann los. Habe ich mir mit irgendeinem Schritt da irgendwas zerschossen?
    Grüße
    Jonah

    1. Hallo Jonah,
      hmm… Normalerweise sollten da die DNS-Server von netcup drin stehen.
      Wenn er Domainnamen nicht auflösen kann, wird der Server an der Stelle Probleme haben wie beschrieben.

      Es sollte mit dem DNS-Server eigentlich dann normal laufen. Zerschossen ist hier nichts…

      Beste Grüße
      Peter.

      1. Danke für die Reaktion. Hier nur als Update:
        Scheinbar hat sich das Problem von selbst gelöst. Ich habe mich zeitgleich zu meinem ersten Comment aus dem Server ausgeloggt und hatte dann bis jetzt keine Zeit mehr. Während meiner Abwesenheit hat sich die /etc/resolv.conf wohl gedacht: „Jetzt habe ich den Nutzer genug geärgert. Beim nächsten mal tun wir so, als wäre nichts gewesen.“
        Als ich mich gerade einloggte habe ich als erstes per cat in die Datei geschaut und mich ordentlich gewundert. Mein 8.8.8.8-Eintrag ist weg, die beiden IPv6-Adressen sind jetzt IPv4 und die Namensauflösung schnurrt wie ein Kätzchen.
        btw. Bei mir steht kein netcup, sondern mein Serveranbieter, weil ich eben schon bei einem anderen Hoster Kunde bin. ;)

        1. Hmm, verrückt… Aber Ende gut – alles gut :)
          Die Anleitung ist halt auf eine Installation über netcup zugeschnitten. Mag gut sein, dass die Installationsscripts von anderen Anbietern andere Ergebnisse liefern.

  2. Tilmann Rückauer

    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

    1. Peter Fiedler

      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.

      1. Tilmann Rückauer

        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

  3. 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?

    1. 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.

      1. Du erstellst ja irgendwo das Schlüssel-Schloss-Paar.
        Die Datei, die dabei raus kommt, die musst Du in das .ssh Verzeichnis legen. Und mit chmod 600 absichern.

  4. Norbert Schmidt

    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

    1. 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.

  5. Kleiner Vertipper gefunden: Benutzer zulegt und dann jedes Mal mit „sodo“ die nötigen Berechtigungen erlangt.
    Soll wohl nicht „sodo“, sondern „sudo“ heißen.

    1. Das ist absolut korrekt, da hab ich mich verhaut! Vielen Dank für den Hinweis…
      Ist echt einer meiner „Standard-Vertipper“ :/

  6. 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?

    1. Peter Fiedler

      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.

      1. 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

  7. 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

    1. Hallo Rainer,
      vielen Dank für das Lob!
      Hoffe, dass deine restliche Installation auch noch einwandfrei läuft :)
      Liebe Grüße
      Peter.

      1. 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?

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Verwendung
von Cookies

Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen zu Cookies erhalten Sie in unserer Datenschutzerklärung.

Scroll to Top