Artikel mit Tag server

netplan unter Ubuntu Server 18.04 LTS konfigurieren oder entfernen

Seit einiger Zeit stellt Canonical für seine Distributionen die Netzwerkkonfiguration via netplan bereit.

Mit der Einführung der Serverversion 18.04 LTS ist diese fester Bestandteil der Long Term Support Edition.

Doch wo ist der Unterschied zur alten Konfiguration und welche Befehle werden benötigt?

netplan.iologo

netplan.io

Anders als die alten Netzwerkkonfigurationsdateien, beruht netplan auf der YAML Syntax. Außerdem werden als Renderer Networkmanager (Desktop), sowie system-networkd (Server) unterstützt.

Die Funktion ist relativ schnell erklärt: Beim Bootvorgang wird aus allen yaml Dateien  /etc/netplan/*.yaml eine Konfiguration generiert und unter /run abgelegt.

Die Konfiguration lässt sich aber auch im laufenden Betrieb anpassen.

Eine klassische Konfigurationsdatei /etc/netplan/01-netcfg.yaml mit fester IP-Adresse würde wie folgt aussehen:

system
network:
        version: 2
        renderer: networkd
        ethernets:
                eth0:
                        dhcp4: no
                        dhcp6: no
                        addresses: [192.169.1.100/16]
                        gateway4: 192.169.1.1
                        nameservers:
                                search: [itrig.lokal]
                                addresses:
                                    - "1.1.1.1"
                                    - "4.4.4.4"

Als Renderer ist in diesem Fall networkd hinterlegt, es kann aber genauso renderer: NetworkManager angegeben werden, beispielsweise bei einem Desktop Betriebssystem.

Die Notation des Subnetzes erfolgt hier im CIDR Format. Als kleine Hilfestellung hier eine Tabelle wink

Prefix   | Subnet mask IPv4 | Subnet mask IPv6
/24      | 255.255.255.0    | 11111111.11111111.11111111.00000000
/25      | 255.255.255.128  | 11111111.11111111.11111111.10000000
/26      | 255.255.255.192  | 11111111.11111111.11111111.11000000
/27      | 255.255.255.224  | 11111111.11111111.11111111.11100000
/28      | 255.255.255.240  | 11111111.11111111.11111111.11110000
/29      | 255.255.255.248  | 11111111.11111111.11111111.11111000
/30      | 255.255.255.252  | 11111111.11111111.11111111.11111100
/31      | 255.255.255.254  | 11111111.11111111.11111111.11111110
/32      | 255.255.255.255  | 11111111.11111111.11111111.11111111

Um die neue Konfiguration zu generieren und anzuwenden werden folgende Befehle verwendet.

sudo netplan generate
sudo netplan apply

Eine Kontrolle kann mit neuen

sudo netplan try

sudo netplan --debug apply

sudo netplan config show

oder alternativ auch mit alten Befehlen erfolgen.

ip a

Hier gilt zu beachten, dass netplan apply keine virtuellen Geräte wie Netzwerkbrücken oder Netzwerkbündel entfernt, auch wenn sie nicht mehr in der Netplan Konfiguration stehen.

Hier muss momentan noch mit ip link delete dev bond0 operiert werden.

netplan.io

 

/etc/network/interfaces

Zum Vergleich eine alte Konfiguration, welche unter  /etc/network/interface zu finden ist.

auto lo eth0
iface lo inet loopback
iface eth0 inet static
    address 192.168.1.100
    netmask 255.255.255.0
    network 192.168.1.0
    gateway 192.168.1.1
    #dns-nameservers 1.1.1.1 8.8.8.8
    dns-search itrig.lokal


netplan.io entfernen oder deaktivieren

Es besteht die Möglichkeit die oben beschriebene frühere Variante weiter zu verwenden. So bleibt eine alte Konfiguration beispielsweise bei einem Update von 16.04 auf 18.04 erhalten.

Bei einer Neuinstallation von 18.04 LTS kann ein Administrator ebenso auf die alte Variante schwenken, dazu muss das benötigte Paket installiert werden.

sudo apt-get install ifupdown

sudo apt -y purge netplan.io

Nun kann die Netzwerkkonfiguration unter /etc/network/interfaces abgelegt werden, sowie ein Neustart des Dienstes erfolgen.

sudo systemctl restart networking

[Update]

Zu Bedenken sind noch die DNS Settings, welche unter /etc/systemd/resolved.conf  abgelegt wurden, was sich unter Ubuntu 18.04 im Vergleich zu früher geändert hat.

Die Datei kann wie folgt modifiziert werden

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See resolved.conf(5) for details

[Resolve]
DNS=8.8.8.8 1.1.1.1 8.8.4.4
#FallbackDNS=
#Domains=
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
#Cache=yes
#DNSStubListener=yes

Nun den Dienst neu starten und die DNS Server überprüfen

sudo systemctl restart systemd-resolved.service
sudo systemd-resolve --status

Alternativ kann auch das resolv Paket installiert werden.

sudo apt install resolvconf

Danach kann die Datei /etc/resolvconf/resolv.conf.d/head editiert und angepasst werden.

# Make edits to /etc/resolvconf/resolv.conf.d/head.
nameserver 1.1.1.1 
nameserver 8.8.8.8
sudo service resolvconf restart

Nun sollten die Netzwerkeinstellungen wieder der von Ubuntu 16.04 LTS oder 14.04 LTS entsprechen.

Ubuntu Server 18.04 LTS - Was ist der Unterschied zwischen der „live" und der "alternative" Version?

Mit dem Ubuntu LTS Server 18.04 wurde eine neue Langzeitversion der bekannten Distribution veröffentlicht.

Das Release wurde mit einem neuen Installer mit dem Namen Subiquity versehen und es wurden viele weitere Änderungen und Neuerungen gemacht. Die kompletten Release Notes zum Ubuntu Server 18.04 LTS gibt es hier.

Zusätzlich steht Ubuntu Server nun in einer Live ubuntu-18.04-live-server-amd64.iso und einer alternativen Version ubuntu-18.04-server-amd64.iso zur Verfügung. Der Standarddownload auf der Canonical Seite verweist auf das "live" Image. 

Doch worin unterscheiden sich die Versionen und warum hat man überhaupt zwei Server im Programm?

Der wesentliche Unterschied dieser Servervarianten besteht in den mitgelieferten Paketen und der damit verbundenen Ausrichtung. Wobei die live Variante auf Cloud Installationen ausgerichtet ist und die alternative Variante auf Standard Installationen. 

ubuntu-18.04-live-server-amd64

Die Cloud Variante beinhaltet beispielsweise das Paket cloud-init und den openssh-server. Beide werden mitausgeliefert und sind nach der Installation aktiv.

Das Paket cloud-init ist auf Anbieter wie DigitalOcean, Azure und Co Installationen spezialisiert (siehe Screenshot) , es läuft im Hintergrund und bezieht diverse Systemkonfigurationen über die Cloud.

Diverse Einstellungen lassen sich unter sudo /etc/cloud/cloud.cfg einsehen.

Eine interaktive Konfiguration ist ebenfalls möglich.

sudo dpkg-reconfigure cloud-init

cloud-init

Über cloud-config würden sich theoretisch wichtige Konfigurationen setzen lassen.

Die Notation ist in YAML gehalten, hier ein Beispiel:

 

#cloud-config
users:
  - name: Dr.Cloud
    ssh-authorized-keys:
      - ssh-rsa AAAAxxxxxx
    sudo: ['ALL=(ALL) NOPASSWD:ALL']
    groups: adm
    shell: /bin/bash
    write_files:
  - path: /etc/ssh/sshd_config
    content: |
         Port 22
         Protocol 2
         HostKey /etc/ssh/ssh_host_rsa_key
         HostKey /etc/ssh/ssh_host_ed25519_key
         PermitRootLogin no
         PubkeyAuthentication yes
         KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
         …


Zusätzlich werden bei der live Installation noch andere Partitionen angelegt und weitere Änderungen gemacht, welche ich hier nicht im Detail erwähnen möchte.

Wichtig sollte sein, dass Einstellungen wie Hostname oder feste IPs via Cloud Konfiguration gesetzt werden und sich klassisch via hostnamectl  nicht dauerhaft ändern lassen, ohne die Cloudabfrage zu deaktivieren oder anzupassen.

Download

ubuntu-18.04-server-amd64

Die alternative Variante verhält sich etwas anders, sowohl bei der Installation, als auch bei der Konfiguration.

Canonical schreibt dazu:

The next generation Subiquity server installer, brings the comfortable live session and speedy install of Ubuntu Desktop to server users at last.

N.B., If you require LVM, RAID, multipath, vlans, bonds, or the ability to re-using existing partitions, you will want to continue to use the alternate installer which can be downloaded from http://cdimage.ubuntu.com/releases/18.04/release/

Neben klassischem LVM ist im Vergleich zur live Version beim Standardinstaller eine Language Pack language-pack-en vorinstalliert.

Für Fernwartungen muss der SSH Server manuell installiert werden.

Eine Konfiguration des Hostnamens wird auf dem bekannten Weg via hostnamectl  vorgenommen. Wie oben bereits erwähnt, würde die live Version diesen Eintrag wieder überschreiben.

Allerdings hat sich durch netplan die IP Konfiguration ebenfalls geändert und ist nun unter /etc/netplan/01-netcfg.yaml zu finden und wie der Name erkennen lässt, im YAML Format gehalten.

logo-ubuntuDownload

Fazit

Für eine normale Serverinstallation ist die Standardvariante ausreichend, denn das cloud-init Paket und einen SSH Server sollte jeder im Bedarfsfall selbst nachinstallieren können. 

Durch gängige Automatisierung bietet sich ein Cloud Initialisierung natürlich ebenfalls an, sollte die Infrastruktur dafür schon vorhanden sein.

Es ist mir allerdings ein Rätsel, warum Canonical dies auf der Downloadseite nicht klar unterscheidet und nur kurz im Text erwähnt, anstatt gleich zwei Downloadvarianten anzubieten. So werden sich die meisten erst einmal die gepushte Cloudvariante laden, um sich danach noch einmal zu belesen bzw. das cloud-init Paket wieder entfernen oder eine andere Variante laden.
Sicher gut als Lerneffekt, aber wenig zielführend.

Canonicals offizielle Ubuntu Tutorials Sammlung

Vor ca. einem Jahr hat Canonical seine offizielle Tutorial Webseite gelauncht.

Seitdem hat sich einiges getan und es wurde eine kleine Sammlung an Anleitungen, Installationen und Tipps rund um das Ubuntu Universum aufgebaut.
Inzwischen finden sich etwa 40 Hilfestellungen für Desktop oder Server Systeme auf der Seite.

Dabei sind sowohl aktuelle Themen wie Kubernetes, aber auch Klassiker wie Apache.
Jede Anleitung kann interaktiv durchlaufen werden und zeigt die verbleibende Arbeitszeit, sowie einen geschätzten Schwierigkeitsgrad an.

Ubuntu-tutorials

Damit ist das Ende der Fahnenstange noch nicht erreicht. Denn jeder ist dazu eingeladen eigene Tutorials zu schreiben.

Ein wenig Markdown Kenntnisse, sowie etwas Git Wissen reichen aus, um eine eigene Installationsanleitung einzureichen.
Eine Einführung in diese Thematik ist vorhanden.

Das Tutorial Projekt ist Open Source und kann via Github geforkt werden.

 

Ubuntu Tutorial

ssh_scan – Sicherheits- und Konfigurationsscanner für SSH Einstellungen

Mit SSH Audit hatte ich bereits vor einiger Zeit ein Tool im Programm, welches SSH auf Einstellungen und Konfiguration testet (Artikel).

Mozilla hat mit ssh_scan ein ähnliches Tool im Portfolio. Das Tool bezieht sich auf die eigenen SSH Guidelines und prüft hinterlegte Ciphers, MACs, und Kex Algorithmen.

Laut eigener Aussage zählt zu den Vorteilen des Tools die einfache Installation ohne allzu viele Abhängigkeiten. Das Programm ist portabel, lässt sich mit eigenen Regeln konfigurieren und wirft am Ende einen Report im JSON Format aus.

Zunächst muss ssh_scan aber erst einmal den Weg auf die Festplatte finden.

Installation unter Ubuntu 16.04 LTS

Für die Installation steht neben einem ssh_scan gem Paket auch ein Docker Container zur Verfügung.

sudo apt-get install ruby gem
sudo gem install ssh_scan

oder via Docker

docker pull mozilla/ssh_scan
docker run -it mozilla/ssh_scan /app/bin/ssh_scan -t example.com

oder froM Source

git clone https://github.com/mozilla/ssh_scan.git
cd ssh_scan

gem install bundler
bundle install

./bin/ssh_scan

SSH Scan im Einsatz

Die SSH-Prüf-Anwendung ist denkbar einfach zu bedienen, es lassen sich einzelne Host scannen, ganze Ranges oder weitere Parameter angeben.

Eine IP scannen

ssh_scan -t ip-addresse

Mehrere IPs scannen

ssh_scan -t ip-addresse1,ip-addresse2,ip-addresse3

ssh_scan

Adressen aus einer Datei scannen

ssh_scan -f ip-addressen.txt

IP Adressen mit bestimmten Port scannen

ssh_scan -t ip-addresse -p 666

Eigene Policy verwenden

ssh_scan -P intermediate -t ip-addresse

In den Standardeinstellungen wird die Mozilla Modern Policy als Prüfvorlage verwendet. Es lässt sich aber mit der oben erwähnten Option P auch auf Intermediate oder andere Richtlinien prüfen.

Hier als Beispiel die Intermediate Richtlinie:

cat intermediate

# Host keys the client accepts - order here is honored by OpenSSH
HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256

Alle SSH_scan Befehle lassen sich über die Hilfe einsehen

ssh_scan -h

 

Fazit

Mozilla bietet mit ssh_scan eine praktische Methode um SSH Einstellungen zu prüfen und zu härten. Dank eigener Policies und vieler weiterer Optionen, wie Reports würde ich das Tool vorziehen, alleine weil das eingangs erwähnte SSH-Audit seit 2016 nicht mehr aktualisiert wurde.

Allerdings empfinde ich die Masse an Paketen, welche mit ruby gem auf dem System landen nicht unerheblich, da ist ein einfaches Python Script schon handlicher. 
Zusätzlich setzt ssh_scan wohl weiterhin auf NIST Kurven wie ecdh-sha2-nistp521,ecdh-sha2-nistp384 und ecdh-sha2-nistp256 welchen ich eher kritisch gegenüber stehe.

Schlussendlich sollte bei solchen Tests immer das Ergebnis genau hinterfragt werden. Das Prüfen von SSH Konfigurationen vereinfachen beide Programme dennoch merklich.

 

ssh_scan

Openfire Meetings - eigenen WebRTC Server einrichten und verwenden

Vor einiger Zeit hatte ich einem Artikel über Jitsi Meet geschrieben. Es ging darum einen eigenen WebRTC Server für  Video und Audio Chats aufzusetzen.
Die Entwickler rund um das Jitsi Projekt sind mit ihrer Lösung schon lange nicht mehr alleine, auch andere verwenden diese Module um Videochats zu implementieren, so auch der XMPP Messaging Server Openfire.

Openfire Meetings - Videochats für den XMPP Server einrichten

Openfire ist ein XMPP Server mit einfach konfigurierbarer Oberfläche, der neben dem Bereitstellen einer klassischen Jabber Chat Umgebung durch diverse Plugins erweitert werden kann. 

So kann der Server mit dem Openfire Meetings Plugin zu einem Web-RTC Server ausgebaut werden. Dieses basiert auf Jitsi Videobridge und bietet somit ähnliche Funktionalitäten wie der oben erwähnte Jitsi Meet Server.

Openfire auf Ubuntu installieren

Die Installation des Openfire Server sei hier noch einmal erwähnt, auch wenn sie bereits verblogt wurde.

wget -O openfire_3.10.2_all.deb "http://www.igniterealtime.org/downloadServlet?filename=openfire/openfire_3.10.2_all.deb"

sudo dpkg -i openfire_3.10.2_all.deb

service openfire restart

Der installierte Server kann unter http://meinServer:9090 oder unter https://meinServer:9091 aufgerufen werden.


Openfire Meeting Plugin installieren

Das nötige Plugin für interaktive Meetings wird einfach über das integrierte Menü "Plugins/Available Plugins" installiert. Danach ist es als eigener Menüpunkt in Openfire zu finden.

openfire-_Available-Plugins

Nach der Installation sollte in den Einstellungen unter "Mettings Settings" eine IP hinterlegt werden.
Umgebungen, die hinter einer Firewall eingerichtet werden, sollten zwingend die in der Konfiguration angegebenen Ports freischalten.

openfire-meeting-plugin

Openfire Meetings Chrome Erweiterung installieren

Die Openfire Meetings Browser Erweiterung, welche zurzeit nur für Chrome zur Verfügung steht, erweitert Videochats um Funktionen wie Bildschirmteilen oder Anwendungsaustausch. Die Installation erfolgt über den Chrome Webstore

openfire-chrome

Weitere nützliche Openfire Plugins

Damit der Server sich auf Gruppenchats und URL Lesezeichen versteht, kann das Client Control Plugin installiert werden. Wie der Name vermuten lässt können damit auch die erlaubten Clients im Netz reguliert werden. URL Lesezeichen bieten sich an, um eine Meetings URL im Client direkt zu hinterlegen.

Das Fastpath Plugin ist ebenfalls eine praktische Erweiterung, um den bestehenden Server für Arbeitsgruppen auszubauen. 

Für eine schnelle Nutzerumbennenung empfiehlt sich just married.

Die hier erwähnten Plugins sind für einen WebRTC Server Betrieb nicht notwendig, sondern optional.

Meeting erstellen oder beitreten

Nachdem alle Module erfolgreich installiert wurden, lässt sich der Meeting Server unter  https://meinServer:7443/ofmeet aufrufen.

Diejenigen welche sich bereits mit Jitsi Meet auseinander gesetzt haben, werden die Oberfläche bereits kennen.

ofmeet

Bestehende Räume lassen sich mit der im Vorfeld generierten ID direkt aufrufen https://meinServer:7443/ofmeet/?r=xxxxx. 

Zusätzlich besteht die Möglichkeit eine Videoübertragung von vornherein auszuschließen, hierzu muss die URL wie folgt manipuliert werden https://meinServer:7443/ofmeet/?r=xxxxx&novideo=true

Inzwischen sind weitere Funktionen wie ein Kalender mit Email Benachrichtigung verfügbar, auch ein normaler Gruppenchat mit Candy (Chats are not dead yet) ist möglich. Weitere Details dazu können auf der Openfire Meeting Seite direkt nachgelesen werden.

Fazit

Ähnlich wie Jitsi Meet stellt Openfire eine fertige Videochat Lösung bereit. Sie lässt sich einfach in eine bestehende Jabber/Xmpp Server Struktur einbinden. dank der Installation via Plugin sind keine weiteren Konfigurationen notwendig, sieht man einmal von einer eventuell vorhandenen Firewall ab. Die Kalender und Mailfunktion scheint praktisch zu sein, in meiner Teststellung konnte ich sie leider nicht testen.


Dies könnte dich auch interessieren

Openfire XMPP Server - Update oder Installation der neuen Version 3.10 unter Ubuntu oder CentOS