Ubuntu Installation auf Netcup

Migration2021 2. Aug. 2021

Nun hat es mich doch noch gepackt:

Gerade den Beitrag mit der RancherOS Abkündigung fertig geschrieben, möchte ich nun auch Ubuntu direkt auf dem Server mit RancherOS installieren, absichern und dann Kubernetes versuchen zu installieren. Den Weg dahin versuche ich hier wieder zu beschreiben.

Installation auf Netcup

So eine Installation eines Betriebssystems wird immer über das CustomerControlPanel von Netcup angestoßen.

Dort eingeloggt, klicke ich direkt auf SCP (Server Control Panel) und befinde mich nun hier:

Serverauswahl
Serverauswahl

Ihr verzeiht mir sicherlich, das ich da ein paar Dinge geschwärzt habe. Im vorhergehenden Artikel habe ich immer von Server1 (RancherOS) und Server2 (Ubuntu) geredet. Im Bild ist der Server in der ersten Zeile Server1 und in der zweiten Zeile Server2. Um natürlich das RancherOS zu ersetzen, klicke ich nun Zeile 1 an.

Allgemeines zum Server
Allgemeines zum Server

Um ein neues Betriebssystem aufzuspielen, klicke ich nun auf Medien und wähle oben rechts Images.

Betriebssystemauswahl
Betriebssystemauswahl

Nun kann ich das Betriebssystem Ubuntu 20.04 auswählen und nehme die Form minimal

Ähm, jetzt hätte ich euch natürlich gerne noch ein Abschlussbild präsentiert, aber da hatte ich wohl zu schnell geklickt. Ich hatte aber ausgewählt, das es eine große Partition wird und das mir eine Abschlussmail zugeschickt wird. Naja dann hoffe ich mal, das alles gut läuft.

Absicherung der Ubuntu 20.04 Installation

Es hat natürlich alles funktioniert. Erstmal durchatmen und dann die nächsten Schritte überdenken:

  • ssh öffentlichen Schlüssel hinterlegen
  • ssh Konfiguration absichern
  • Firewall installieren
  • Docker installieren
  • alte Daten via SCP zurückspielen

ssh öffentlichen Schlüssel hinterlegen

Das habe ich ja schon ausreichend im ersten Beitrag beschrieben. Es gibt einen öffentlichen und einen privaten Teil in einem SSH Schlüsselpaar und nun hinterlege ich meinen öffentlichen Teil auf dem frisch installierten Server.

Für so etwas gibt es ein Helferlein ssh-copy-id.

Bevor ich das aber benutzen kann, muss ich mir erstmal einen Nutzer anlegen.

adduser user
# Adding user `user' ...
# Adding new group `user' (1000) ...
# Adding new user `user' (1000) with group `user' ...
# Creating home directory `/home/user' ...
# Copying files from `/etc/skel' ...
# New password:
# Retype new password:
# passwd: password updated successfully
# Changing the user information for user
# Enter the new value, or press ENTER for the default
# 	Full Name []:
# 	Room Number []:
# 	Work Phone []:
#	Home Phone []:
#	Other []:
# Is the information correct? [Y/n] y

Am besten öffne ich nun eine zweite Shell und lasse die Shell mit dem root Nutzer offen.

Nun kann ich mein Helferlein auf dem Laptop benutzen:

ssh-copy-id user@ip                                                                                                                              
# /usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/Users/user/.ssh/id_rsa.pub"
# /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
# /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
# user@ip's password:

# Number of key(s) added:        1

# Now try logging into the machine, with:   "ssh 'user@ip'"
# and check to make sure that only the key(s) you wanted were added.

Um das ganze zu validieren, tippe ich nun in der Konsole die folgende Befehlszeile ein:

ssh 'user@ip'. Dort wird nun direkt der private Schlüssel genommen und mit den öffentlichem Teil auf dem Server validiert. Wenn alles funktioniert, darf ich mich nun ohne Passwort einloggen:

Funktioniert

ssh Konfiguration absichern

Nun könnte ich mich via Passwort einloggen und noch viel schlimmer auch der Root Nutzer dürfte sich per Passwort einloggen. Der Nutzername root ist also für die AngreiferInnen bekannt und nun müsste die AngreiferInnen nur noch das Passwort ausprobieren und glaubt mir, das passiert schneller als man denkt. Die Konfiguration sollte also abgesichert werden.

Die Konfiguration für den SSH Daemon befindet sich unter /etc/ssh/sshd_config. Diese Datei kann man nun mit sudo und einen Editor (vi/nano) öffnen.

sudo vi /etc/ssh/sshd_config
# [sudo] password for user:
# user is not in the sudoers file.  This incident will be reported.

Upsi, was ist da denn passiert? Naja, mein Nutzer habe ich zwar angelegt, aber dem System noch nicht bekannt gegeben, das dieser sich auch mehr Rechte holen dürfte.

Fix also zum root Nutzer zurückgewechselt und dem user mehr Rechte geben.

usermod -aG sudo user

Und nun wieder zurück zu dem anderen Terminal und den obigen Fehler erneut ausführen.

Puh, geht immernoch nicht und ich bekomme immernoch den Fehler. Aber hey, ich muss natürlich die Shell neustarten. Also ausloggen und wieder via SSH einloggen. Ha, und nun funktioniert der Befehl.

Nun kann ich mich der ssh Konfiguration voll und ganz widmen. Als Vorlage für alle Änderungen nehme ich den folgenden Artikel:

https://www.digitalocean.com/community/tutorials/how-to-harden-openssh-on-ubuntu-18-04-de

DigitalOcean ist generell immer eine gute Quelle für Dokumentationen rund um Server etc.

Also Erstes wird der Login des root Nutzers gesperrt. Er könnte sich also nicht mehr einloggen, aber man sich via sudo -s als Root Nutzer bewegen.

PermitRootLogin no

Als Nächstes werden die Anmeldeversuche begrenzt. Nachdem diese ausgeschöpft sind, wird die Anmeldesitzung gesperrt.

MaxAuthTries 3

Nun wird noch die Anmeldefrist begrenzt. In dieser Zeit muss die Anmeldung erfolgreich abgeschlossen werden. Der Wert wird hier in Sekunden angegeben.

LoginGraceTime 20

Da ich nun einen öffentlichen und privaten Schlüssel für das Anmelden benutze, kann ich auch direkt die Passwort Anmeldung deaktivieren.

PasswordAuthentication no

Auch leere Passwörter sollten natürlich verhindert werden. Aber das ist hier nur die Kür.

PermitEmptyPasswords no

Ein SSH Server kann auch durch mehrere Verfahren angesprochen werden und wenn ich diese nicht nutze, kann ich sie auch direkt deaktivieren.

ChallengeResponseAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no

Auch werde ich niemals den X11 Bildschirm über SSH anzeigen wollen und kann damit auch diese Option deaktivieren.

X11Forwarding no

Über SSH gibt es auch die Möglichkeit Ports und damit Anwendungen weiterzuleiten. Das will ich aber erstmal nicht und so werden auch diese Optionen von mir deaktiviert.

AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no

Nun kann ich die angepasste Konfigurationsdatei speichern und das Ganze validieren. Damit die Einstellungen übernommen werden, starte ich den sshd Service neu: sudo service sshd reload

Um mich nicht auszusperren, mach ich wieder eine eigene Shell auf. Die Sitzung mit dem root Nutzer lasse ich weiterhin offen. Sie wäre quasi mein Rettungsanker.

Nun probiere ich wieder den Login mit ssh 'user@ip' …. und es funktioniert noch alles. Perfekt

2 Punkte abgehakt, 3 Punkte noch zu tun…

Firewall installieren

Das wird ein sehr kleiner Abschnitt, da hier nur wenige Befehle benutzt werden. Bevor ich das Ganze aber mache, schaue ich erstmal ob alle Softwarepakete aktuell sind.

sudo apt-get update && sudo apt-get upgrade
# [sudo] password for user:
# Hit:1 http://de.archive.ubuntu.com/ubuntu focal InRelease
# Hit:2 http://de.archive.ubuntu.com/ubuntu focal-updates InRelease
# Hit:3 http://de.archive.ubuntu.com/ubuntu focal-backports InRelease
# Get:4 http://security.ubuntu.com/ubuntu focal-security InRelease [114 kB]
# Fetched 114 kB in 1s (122 kB/s)
# Reading package lists... Done
# Reading package lists... Done
# Building dependency tree
# Reading state information... Done
# Calculating upgrade... Done
# 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Alles frisch und fluffig.

sudo ufw status
Status: inactive

UFW bedeutet uncomplicated firewall und das ist genau das Ziel: keine hohe Komplexität beim Thema Firewall. Aber bislang ist sie inaktiv und schützt noch gar nichts.

sudo ufw allow ssh # ssh erlauben
sudo ufw allow http # http oder Port 80 erlauben
sudo ufw allow https # https oder Port 443 erlauben
sudo ufw allow kubernetes # ich versuche mal etwas
# ERROR: Could not find a profile matching 'kubernetes' tja schade, aber einen versuch habe ich noch
sudo ufw allow kubectl
# ERROR: Could not find a profile matching 'kubectl' tja meh

Die Ports für Kubernetes öffne ich dann einfach später. Ist jetzt nicht ganz so wichtig.

Nun muss ich die Firewall nur noch aktivieren und dann die Verbindung via ssh wieder kontrollieren.

sudo ufw enable
# Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
# Firewall is active and enabled on system startup

…. und alles funktioniert noch. Wie man sich per ssh verbindet, habe ich ja bereits mehrmals gezeigt. Ich habe natürlich auch hier wieder eine eigenes Terminal benutzt.

Damit ist die Firewall auch aufgebaut und ich komme zu Docker.

Docker installieren

Ich räume nun erstmal die ganzen Terminals auf. Es waren doch gerade viele Sitzungen offen und so viele brauche ich nun nicht mehr. Ich habe alles verifiziert und doppelt kontrolliert.

Ich öffne also eine Sitzung mit meinen Nutzer user und mache erstmal alles ohne den root Kontext. Für die Installation usw. brauche ich aber natürlich wieder root.

Es gibt sehr viele Anleitungen für die Installation von Docker und ich werde die folgende benutzen:

https://docs.docker.com/engine/install/ubuntu/

Nacheinander werde ich die nachstehenden Befehle ausführen. Sie sind natürlich in aktuellere Form auf der Dokumentationsseite zu finden.

sudo apt-get remove docker docker-engine docker.io containerd runc
# Reading package lists... Done
# Building dependency tree
# Reading state information... Done
# E: Unable to locate package docker-engine --> upsi das Paket kennt der Server nicht, nochmal
sudo apt-get remove docker docker.io containerd runc
# Reading package lists... Done
# Building dependency tree
# Reading state information... Done
# Package 'docker' is not installed, so not removed
# Package 'containerd' is not installed, so not removed
# Package 'runc' is not installed, so not removed
# Package 'docker.io' is not installed, so not removed
# 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

sudo apt-get update
# erstmal die vorhandenen Paketquellen updaten
sudo apt-get install \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg \
    lsb-release
# erstmal die Grundpakete nachinstallieren
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
# offiziellen Schlüssel für das Docker Repo hinzugefügt
echo \
  "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
# Paketquelle hinzugefügt
sudo apt-get update
# Erneutes Update
sudo apt-get install docker-ce docker-ce-cli containerd.io
# Docker Installation abgeschlossen

Damit der normale Nutzer auch docker Befehle absetzen kann, muss er zu der richtigen Gruppe hinzugefügt werden.

sudo groupadd docker
# groupadd: group 'docker' already exists
sudo usermod -aG docker $USER

Nun muss ich mich einmal ausloggen und wieder via ssh einloggen und schon kann ich alles mit docker machen.

docker run hello-world
# Unable to find image 'hello-world:latest' locally
# latest: Pulling from library/hello-world
# b8dfde127a29: Pull complete
# Digest: sha256:9f6ad537c5132bcce57f7a0a20e317228d382c3cd61edae14650eec68b2b345c
# Status: Downloaded newer image for hello-world:latest

# Hello from Docker!
# This message shows that your installation appears to be working correctly.

# To generate this message, Docker took the following steps:
#  1. The Docker client contacted the Docker daemon.
#  2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
#     (amd64)
#  3. The Docker daemon created a new container from that image which runs the
#     executable that produces the output you are currently reading.
#  4. The Docker daemon streamed that output to the Docker client, which sent it
#     to your terminal.

# To try something more ambitious, you can run an Ubuntu container with:
#  $ docker run -it ubuntu bash

# Share images, automate workflows, and more with a free Docker ID:
#  https://hub.docker.com/

# For more examples and ideas, visit:
#  https://docs.docker.com/get-started/

4 von 5 Aufgaben geschafft und nun überführe ich mal die alten Dateien. Diese hatte ich ja auf Server2 gespeichert und genau diese werde ich via SCP wieder zurückspielen.

Alte Daten via SCP zurückspielen

Dafür hinterlege ich wieder den öffentlichen Schlüssel von Server2 auf Server1. Wie das funktioniert lest ihr einfach im ersten Beitrag nach.

ssh user@server1
# @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
# @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
# @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
# IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
# Someone could be eavesdropping on you right now (man-in-the-middle attack)!
# It is also possible that a host key has just been changed.
# The fingerprint for the ECDSA key sent by the remote host is
# SHA256...
# Please contact your system administrator.
# Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
# Offending ECDSA key in /home/user/.ssh/known_hosts:2
#   remove with:
#   ssh-keygen -f "/home/user/.ssh/known_hosts" -R "ip"
# ECDSA host key for ip has changed and you have requested strict checking.
# Host key verification failed. 

Upsi, was ist denn hier passiert? Naja ganz klar. Ich habe in der Zwischenzeit das Betriebssystem von Server1 geändert und nun beschwert sich Server2, das sich die Signatur von Server1 geändert hat. Da ich aber den Grund kenne, kann ich die alte Signatur löschen und von Server1 eine neue anfordern.

ssh-keygen -f "/home/user/.ssh/known_hosts" -R "ip"
# Host ip found: line 2
# /home/user/.ssh/known_hosts updated.
# Original contents retained as /home/user/.ssh/known_hosts.old

Und nun probiere ich es erneut.

ssh user@server1
# The authenticity of host 'ip (ip)' can't be established.
# ECDSA key fingerprint is SHA256 ....
# Are you sure you want to continue connecting (yes/no/[fingerprint])?

SSH Verbindung steht wieder und nun nehme ich wieder SCP um die Daten diesmal aber wieder zurück zu spielen.

scp backup.tar.gz user@server1:/home/user/
# backup.tar.gz                                                      1%  644MB 109.2MB/s   09:25 ETA

Das dauert jetzt auch wieder:

Ein Moment um das Ganze Revue passieren zu lassen

  • Ubuntu wurde auf einem Netcup Server installiert
  • Docker wurde installiert
  • Ports wurde mit einer Firewall abgesichert
  • SSH wurde abgesichert und lässt nun nur noch PubKey Authentication zu
  • Software ist aktuell
  • … und die alten Daten wurden zurückgespielt

Damit wäre ich auch hier durch. Als nächste widme ich mich Kubernetes und Rancher. Hoffentlich unterstützt mich letzteres. Das beschreibe ich aber im nächsten Beitrag. Ha, Cliffhanger und so.

Disclaimer: Ich habe weiter oben Bilder von der Netcup Administrationsoberfläche gezeigt. Die Rechte liegen hier natürlich klar bei Netcup.

Tags

Tim Friedrich

Hausherr des Blogs, - an mir kommst du hier nicht vorbei! Daher ein fröhliches Hallo und herzliches Willkommen im Blog.

Großartig! Das Abonnement wurde erfolgreich abgeschlossen.
Großartig! Schließen Sie als Nächstes die Kaufabwicklung ab, um vollen Zugriff zu erhalten.
Willkommen zurück! Sie haben sich erfolgreich angemeldet.
Erfolg! Ihr Konto ist vollständig aktiviert, Sie haben jetzt Zugang zu allen Inhalten.