Gitlab in Docker mit SSH Standardport

Im Docker basierten Setup von Gitlab wird ein SSH Daemon mitgeliefert, der im Normalfall aber auf einem anderen Port laufen muss wie der native SSH-Daemon vom Betriebssystem. Möchte man den SSH Daemon von Gitlab öffentlich betreiben und hat nur eine öffentliche IP-Adresse zur Verfügung gibt es verschiedene Möglichkeiten (die letzte wird hier beschrieben):

• Gitlab-SSH auf anderem Port als den des Betriebssystem lauschen lassen
• System-SSH auf anderen Port binden um 22 für Gitlab frei zu räumen
• System-SSH mit Gitlab-SSH verknüpfen (wird hier beschrieben)

Erklärung

Gitlab stellt für den eigenen SSH-Daemon ein Script bereit, das alle registrierten SSH-Keys zurückmeldet. Diese werden vom SSH-Daemon genutzt um zu prüfen, ob ein zu verbindener Klient generell zugelassen werden kann. Dieses vorgehen ist generell beim OpenSSH-Server möglich, nur weiß der des Betriebssystems nichts von Dingen die im Docker Container passieren. Der nötige Befehl wird mittels Wrapper-Script und docker exec zur Verfügung gestellt, damit der Betriebssystem-SSH-Daemon die Keys abfragen kann. Der Gitlab-Befehl erhält alle nötigen Informationen über die SSH Verbindung um diese für weitere Verarbeitungen heranziehen zu können.

Script und Konfiguration

SSH-Daemon Konfiguration

Zunächst benötigen wir einen System-Benutzer git der im Regelfall in der Distribution bereits angelegt ist. Der Pfad zum Script kann angepasst werden, falls man docker-volumes nutzt und das Script lieber wo anders liegen haben möchte (z.B. /usr/local/bin/). Im SSH-Daemon wird folgendes konfiguriert:

# File: /etc/ssh/sshd_config

Match User git
    AuthorizedKeysCommand /srv/docker/containers/gitlab/scripts/gitlab_authorized_keys
    # muss root sein, weil das gitlab_authorized_keys root:root gehoert!
    AuthorizedKeysCommandUser root

systemctl restart sshd.service

Gitlab Authorized-Keys

Dieses Script wird vom SSH-Daemon initial abgerufen um die Keys zu lesen. Es ist wichtig, dass der Pfad angepasst wird, je nachdem wo euer Gitlab seine Daten speichert. Dies kann z.B. auch ein Docker Volume sein (/var/lib/docker/volumes/ghitlab/data/.ssh/authorized_keys).

Das verwendete Script enthält folgendes:

# File /srv/docker/containers/gitlab/scripts/gitlab_authorized_keys

#!/bin/bash

# docker exec -u git gitlab cat /var/opt/gitlab/.ssh/authorized_keys
f="/srv/docker/containers/gitlab/data/.ssh/authorized_keys"

if [[ -f "${f}" ]];then
        cat /srv/docker/containers/gitlab/data/.ssh/authorized_keys
fi

In dem authorized_keys File von Gitlab stehen alle gültigen SSH Keys, allerdings wird beim Verbinden das Ausführen eines Scripts erzwungen (siehe command=…):

# File: /srv/docker/containers/gitlab/data/.ssh/authorized_keys

command="/opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell key-1",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3Nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx==

Gitlab-Shell Wrapper-Script

Somit wird unser SSH-Daemon dieses Script ausführen wollen. Deshalb legen wir unser Wrapper-Script an den gewünschten Ort (/opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell):

# File: /opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell

#!/bin/bash
docker exec -u git -i -e SSH_CONNECTION="$SSH_CONNECTION" -e SSH_ORIGINAL_COMMAND="$SSH_ORIGINAL_COMMAND" gitlab /opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell $*

Wichtig sind noch die Berechtigungen. Diese sollten noch korrigiert werden um sicherzustellen, dass nur git das Skript ausführen kann.

chown git:git /opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell
chmod 0750 /opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell

Außerdem muss der git-Benutzer noch in die Gruppe docker, damit er auf den Docker-Socket zugreifen kann (docker exec …):

usermod -a -G docker git

Test der Funktion

Mit funktionierendem Agent / SSH-Key:

git clone git@my.gitlab.server.com:repo/something.git

Sollte etwas nicht funktionieren kann im Journal nachgesehen werden:

journalctl -u sshd.service -f

Links

https://docs.gitlab.com/ce/install/docker.html

How To

• ASDF Nutzung und Beispiele
• Hardware und Details via CLI-Tools ermitteln
• Linux Betriebssystem migrieren (remote & lokal)
• ZFS auf Arch Linux installieren / updaten

Security

• LUKS Volume mit USB Keystick verknüpfen
• salted SHA512 Passwort Hashes generieren
• transparent verschlüsselte VMs mit Libvirt

Mikrotik Routeros CLI Cheatsheet

Loop

Entfernen von Kommentaren auf mehreren Objekten

:for i from=0 to=24 do={/interface/bridge/port set $i comment=""}

Supermicro noVNC ohne Browser (CURL)

Nicht immer ist ein Browser in greifbarer Nähe, oder es soll kurz schnell gehen. Um auf die noVNC Schnittstelle von Supermicro Mainboards zugreifen zu können ist die Verbindung mittels IPMI Viewer, oder JNLP (Java Network Launch Protocol) möglich.

Ist der Host nicht im selben Netzwerk wie der lokale PC, funktioniert der IPMI Viewer nicht zwingend. Dies kann zum Beispiel beim SSHuttle der Fall sein. In diesem Fall erreicht man zwar das Webinterface der IPMI-Schnittstelle, muss sich dann mittels Browser einloggen und die JNLP Datei herunterladen. Im Anschluss kann diese dann ausgeführt werden…

Soll es schneller gehen bietet sich der Download der JNLP-Datei auch mittels curl an:

IPMIHOST=YOURHOST
USER=YOURUSER
PASS=YOURPASS
COOKIE=$(mktemp)
JNLP=$(mktemp)
curl -q -s -k -c "${COOKIE}" -X POST --data "name=${USER}&pwd=${PASS}" "https://${IPMIHOST}/cgi/login.cgi" >/dev/null
curl -q -s -k -b "${COOKIE}" -o "${JNLP}" -X GET "https://${IPMIHOST}/cgi/url_redirect.cgi?url_name=ikvm&url_type=jwsk"
javaws "${JNLP}"

Zur Erklärung der “Magie”:

• die Variablen werden gesetzt und zwei temporäre Dateien erzeugt ($COOKIE & $JWSK)
• mittels HTTP POST Request wird sich eingeloggt (Daten kommen aus den Variablen $USER & $PASS). Der Inhalt des Cookies wird in die Temp-Datei ($COOKIE) geschrieben
• mit dem Cookie wird die URL aufgerufen, die eine gewünschte JNLP-Datei zurückliefert. Der Inhalt wird in die Datei ($JNLP) gespeichert.
• die JNLP Datei wird mittels Java-Webstart (javaws) ausgeführt

Links

https://www.truenas.com/community/threads/script-to-launch-supermicro-ipmi-viewer-from-shell.45275/

Supermicro Serial over LAN (SOL)

Es gibt Fälle in denen gerade keine Desktop GUI bereit steht, oder einem die Java Anwendung zu unbequem ist um die Bildschirmausgabe (noVNC) zu öffnen.
Dennoch ist es möglich den Bootprozess zu begleiten, oder sogar das BIOS aufzurufen.
Hierfür stellt Supermicro eine serielle Schnittstelle bereit, die über das Netzwerk erreicht werden kann (Serial over LAN).

Am einfachsten geschieht der Zugriff über IPMItool. Die Parameter sollten wie folgt angepasst werden:

Beispiel

ipmitool -I lanplus -H $IP_ODER_HOSTNAME -U ADMIN -P ADMIN sol activate

#verlassen der Konsole mit folgender Kombination:
<Enter>
~~

Die Tilde schreibt sich mit "ALT GR" + "+" (neben Enter)

Konfiguration Grub für Linux-Konsole

Um die Konsole von Linux verwenden zu lassen, ist es eventuell nötig dem Kernel entsprechende Parameter mitzuteilen.
Dies kann im Grub konfiguriert werden. Ein Beispiel zu Ubuntu (ggf. auch auf andere Distributionen übertragbar):

# File: /etc/default/grub

# Ausgabe auf Bildschirm und serieller Schnittstelle
GRUB_TERMINAL="console serial"

# entweder ergänzen:
GRUB_CMDLINE_LINUX="... serial=ttyS0 console=ttyS0,115200n8

# oder neuen Bereich beginnen:
GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX serial=ttyS0 console=ttyS0,115200n8"

Danach muss die GRUB-Konfiguration erstellt werden:

grub-mkconfig -o /boot/grub/grub.cfg

update-grub

Nach einem Reboot dürften Bootprozess, Grub-Menü und auch die Konsole des Betriebssystems mittels SOL anzusprechen sein.

Links

https://wiki.ubuntuusers.de/GRUB_2/Konfiguration/

Chrooted SFTP Server konfigurieren

Vorwort

Um Dateien auf und von einen Linux-Server zu laden stehen unzählbar viele Möglichkeiten zur Verfügung. In diesem Beispiel wird ein SFTP-Server konfiguriert, der:

• nur bestimmten Benutzern, oder Gruppen den Zugang erlaubt
• die Authentifizierung via Passwort, oder SSH-Schlüssel zulässt
• das Startverzeichnis (Wurzelverzeichnis) fest vorschreibt

Sollte noch kein Openssh-Server installiert sein, kann dies einfach nachgeholt werden:

sudo pacman -Syu openssh

sudo apt update && sudo apt install openssh-server

Allgemein Hinweise zur Konfiguration

Alle Einstellungen werden in der typischen Konfigurationsdatei /etc/ssh/sshd_config vorgenommen. Nach Änderungen muss der SSH-Dienst neugestartet werden um diese zu laden. Bereits hergestellt Verbindungen werden von den Anpassungen nicht beeinträchtigt, sodass man bei Fehlkonfigurationen diese wieder rückgängig machen kann!

Konfiguration

Die unten stehenden Einstellungen sollen hier etwas genauer beleuchtet werden:

# File: /etc/ssh/sshd_config

# Alle Einstellungen können bequem an das Ende der Datei gepackt werden!


# gilt nur für Benutzer der Linux-Gruppe sftpusers
# alle Benutzer teilen sich einen gemeinsamen Ordner
Match Group sftpusers
  PasswordAuthentication yes
  ChrootDirectory /srv/sftp_group_dir
  ForceCommand internal-sftp

# gilt nur für Benutzer der Linux-Gruppe individuals
# jeder Benutzer hat einen eigenen Ordner (%u wird durch Usernamen ersetzt)
Match Group individuals
  PasswordAuthentication yes
  ChrootDirectory /srv/individuals/%u
  ForceCommand internal-sftp

# gilt nur für den Benutzer myuser
Match User myuser
  PasswordAuthentication no
  ChrootDirectory /srv/sftp
  ForceCommand internal-sftp
  AllowTcpForwarding no

Sollte die gruppen-basierte Konfiguration genutzt werden, achte darauf den Konsolen-Benutzer mit dem du Einstellungen tätigst nicht zur Gruppe hinzuzufügen. Andernfalls kannst du zukünftig keine Kommandozeile mehr via SSH öffnen, denn es wird SFTP erzwungen ;)! In diesem Fall wäre ein neuer Benutzer für SFTP Verbindungen ratsam.

Damit die Verbindung generell möglich ist, darf das gewählte Chroot-Directory für den verbindenen Benutzer nicht beschreibbar sein! Damit der Benutzer aber einen Ordner zum schreiben hat, sollte ein neuer Ordner angelegt werden. Hier ein Beispiel:

# Ordner rekursiv anlegen
mkdir -p /srv/sftp_group_dir/subdir

# Besitz auf root Benutzer und Gruppe anpassen
chown root:root /srv/sftp_group_dir

# nur Benutzer und Gruppe dürfen "alles"
chmod 755 /srv/sftp_group_dir

# der Besitz des Unterordner subdir wird auf den Benutzer myuser und die Gruppe sftpusers gesetzt
chown myuser:sftpusers /srv/sftp_group_dir/subdir

# Benutzer und Gruppe dürfen "alles"
chmod 770 /srv/sftp_group_dir/subdir

Um Problemen mit Dateiberechtigungen entgegen zu wirken, können Linux-Benutzer sich die gleiche ID teilen.
Dies ist bei SFTP besonders hilfreich, denn alle Benutzer können dann unterschiedliche Namen (und Passwörter), aber identische Schreibberechtigungen haben.
Bei Zugriffen auf Dateien teilen sie sich nämlich die selbe ID.
Hat jeder Benutzer eine individuelle ID, muss darauf geachtet werden, dass die Datei- und Ordnerberechtigung korrekt konfiguriert werden.
Geschieht dies nicht, können Benutzer Dateien eventuell nicht lesen und bearbeiten.
Deshalb ist es hilfreich die identische User-ID zu verwenden.

Port Forwarding

Remote Port per Tunnel lokal binden

Per SSH kann prinzipiell jeder TCP-Port getunnelt werden, den der Remote-Host erreicht.
Hierzu wird auf dem Client ein Port lokal gebunden und jeglicher Traffic der auf diesen eingeht, durch den Tunnel zum Remote-Host geleitet.
Dieser stellt dann stellvertredend die Verbindung zum Ziel her.

Syntax

ssh -L [local_bind_address:]port:host:hostport root@remote.host

Beispiel 1

MariaDB wird über diverse lokalen IP-Adressen und Ports verfügbar gemacht. Auf dem Remote-Host host1 ist MariaDB nur lokal erreichbar (127.0.0.1:3306).
Die linke Seite entspricht der lokalen IP (oder Port) des Clients.

ssh user@host1 -L 127.0.0.1:3306:127.0.0.1:3306
ssh user@host1 -L 192.168.123.2:3306:127.0.0.1:3306 
ssh user@host1 -L 192.168.123.2:13306:127.0.0.1:3306
ssh user@host1 -L 3306:127.0.0.1:3306

Beispiel 2

Ein Webserver (HTTP/S) läuft auf web1, welcher von host1 erreicht werden kann (ein typischer Jumphost):

• IP-Adresse web1: 192.168.55.2
• IP-Adresse host1: 192.168.55.1

ssh user@host1 -L 127.0.0.1:80:192.168.55.2:80
ssh user@host1 -L 127.0.0.1:443:192.168.55.2:443

Weil die Ports 80 und 443 zu den “well-known” Ports gehören, müssen diese ggf. mit root-Rechten gebunden werden (sudo vor dem ssh Befehl).
Deswegen kann es empfehlenswert sein, diese stattdessen auf Ports größer 1024 zu binden:

ssh user@host1 -L 127.0.0.1:8080:192.168.55.2:80
ssh user@host1 -L 127.0.0.1:8443:192.168.55.2:443

SSH SOCK5 Proxy

Anwendungen können (sofern unterstützt) über einen sogenannten Sock5-Proxy mit Servern kommunizieren.
Hierbei wird der Traffic an den Remote-Host gesendet und dieser schickt die Anfrage weiter zum Ziel.

Syntax

ssh user@host1 -D [lokale_bind_address:]port

Beispiel 1

Der Sock5-Proxy bindet sich lokal auf Port 5000.

ssh user@host1 -D 127.0.0.1:5000

Beispiel 2

Lokaler Proxy, der auch von anderen Clients genutzt werden kann, sofern Sie den Host und Port erreichen können.

ssh user@host1 -D 192.168.178.2:1337

SShuttle

Gerne als “poor man’s VPN” bezeichnet, kann SShuttle (eine Python Anwendung) bestimmte Ziel-Adressen (oder Netze) über SSH tunneln. Hierzu bindet SShuttle einen lokalen Port und hinterlegt Firewall-Regeln (nftables / iptables). Hierdurch werden Pakete zum Ziel an den lokalen SShuttle Port umgeleitet (DNAT), und SShuttle leitet diese wiederum zum Remote-Host.
Dieser schickt die Pakete dann dann zum Ziel(netz). Durch diese Technik können ganze IP-Netze hinter (Jump-)Hosts erreicht werden, solange es sich um TCP-Traffic handelt.

Syntax

sshuttle [-l [ip:]port] -r [user@]sshserver[:port] <subnets...>

Beispiel 1

Die Netze 10.20.30.0, 192.168.33.0/25 und die IP-Adresse 1.1.1.1 sollen über host1 verfügbar gemacht werden:

sshuttle -r user@host1 10.20.30.0/24 192.168.33.0/25 1.1.1.1

SSH Verbindung ohne Passwort (mit Key)

Für eine erhöhte Sicherheit beim SSH-Login bietet sich die Authentifizierung mittels SSH-Schlüssel an.
Zusätzlich wird der Login mittels Passwort deaktiviert.

In dieser Anleitung wird die Generierung auf Windows und Linux (auch WSL) beschrieben und abschließend, wie der öffentliche Schlüssel auf den Server zu legen und die SSH-Konfiguration vorzunehmen ist.

SSH Schlüssel auf Windows generieren

In neueren Windows 10 Versionen steht der OpenSSH-Client bereit. Falls dieser nicht installiert ist, kann dieser installiert werden.
Hierfür nutzt man unter Einstellungen “Apps & Features”, klickt auf “Optionale Features” und installiert mittels “Feature hinzufügen” den OpenSSH-Client.

Nach der Installation stehen die Kommandozeilen-Tools zur Verfügung und die Generierung kann durchgeführt werden.
Je nach Plattform die man unterstützten möchte, kann es notwendig sein den veralteten Standard (RSA) zu verwenden.
In diesem Fall sollte man einen möglichst großen Schlüssel verwenden (4096 Bit). Gemäß der Doku empfiehlt sich das Schlüsselverfahren ecdsa zu verwenden.

ssh-keygen -t ecdsa -b 521
ssh-keygen -t rsa -b 4096
ssh-keygen -t ed25519

Hier ein komplettes Beispiel in dem der Pfad mittels Enter bestätigt und ein Passwort für den Schlüssel festgelegt wird. Das Passwort schützt den Schlüssel im Fall von Diebstahl durch Datei-Kopieren!

# .ssh Ordner im $HOME anlegen und betreten
cd
mkdir .ssh
cd .ssh

# Key generieren
C:\Users\User\.ssh>ssh-keygen -t ecdsa -b 521

Generating public/private ecdsa key pair.
Enter file in which to save the key (C:\Users\User/.ssh/id_ecdsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in C:\Users\User/.ssh/id_ecdsa.
Your public key has been saved in C:\Users\User/.ssh/id_ecdsa.pub.
The key fingerprint is:
SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx User@PC
The key's randomart image is:
+---[ECDSA 521]---+
xxxxxxxxxxxxxxx
xxxxxxxxxxxxxxx
xxxxxxxxxxxxxxx
xxxxxxxxxxxxxxx
xxxxxxxxxxxxxxx
xxxxxxxxxxxxxxx
xxxxxxxxxxxxxxx
xxxxxxxxxxxxxxx
xxxxxxxxxxxxxxx
xxxxxxxxxxxxxxx
+----[SHA256]-----+

Nach der Generierung finden sich, je nach gewähltem Verfahren zwei Dateien im Verzeichnis .ssh:

• id_$verfahren (privater Schlüssel)
• id_$verfahren.pub (öffentlicher Schlüssel)

Die *.pub Datei ist nützlich, aber nicht zwingend notwendig, da diese immer wieder aus dem privaten Schlüssel generiert werden kann:

ssh-keygen -f $privater_schlüssel -y
# <Passwort eingeben>

ecdsa-sha2-nistp521 AAAAE2VjZHNhLXNoYTItbmlzdHA1MjEAAAAIbmlzdHA1MjEAAACFBAF1mthDNIv98jiT5qF85YCd9QmvgK+bTn/VLQVRmJyC12dOSjGpcam4c5Uu9t5dEXtr1bRSW9nCC7Ro6Exla0y86AALfgrTTAFysotLuqJD5bigQN5J50qpZJwUs8wlB12NehrNvAfCQiEYvmN6Bg0RugUyHSi21jlQ4kSj6RsDMAT9Xw==

SSH Schlüssel auf Linux (oder WSL) generieren

Im Regelfall sollte die Anwendung ssh-keygen bereits installiert sein. Ist dies nicht der Fall, müssen die Pakete dafür installiert werden. Wie immer für Ubuntu / Debian und Archlinux:

pacman -Syu openssh

apt update && apt install openssh-client

Im Anschluss wird wie unter Windows der Schlüssel generiert:

ssh-keygen -t ecdsa -b 521
ssh-keygen -t rsa -b 4096
ssh-keygen -t ed25519

Mehr Informationen dazu finden sich oben in der Windows-Anleitung.
Der Ausgabe-Pfad ist ebenfalls der $Benutzer-Ordner/.ssh.

ohne Passwort, aber per Key

Der öffentliche Schlüssel muss in das Home-Verzeichnis des Users gelegt werden, als der man sich einloggen möchte. In diesem Beispiel nennt er sich “user1”.
Den Inhalt der id_$verfahren.pub legt man nun in die authorized_keys Datei (/home/user1/.ssh/authorized_keys.
Diese Datei kann eine beliebige Menge von öffentlichen Schlüsseln enthalten.
Hinter dem Schlüssel können Kommentare hinzugefügt werden.

# Auflisten der Keys
cat /home/user1/.ssh/authorized_keys

ecdsa-sha2-nistp521 AAAAE2VjZHNhLXNoYTItbmlzdHA1MjEAAAAIbmlzdHA1MjEAAACFBAF1mthDNIv98jiT5qF85YCd9QmvgK+bTn/VLQVRmJyC12dOSjGpcam4c5Uu9t5dEXtr1bRSW9nCC7Ro6Exla0y86AALfgrTTAFysotLuqJD5bigQN5J50qpZJwUs8wlB12NehrNvAfCQiEYvmN6Bg0RugUyHSi21jlQ4kSj6RsDMAT9Xw== mein kommentar zum schlüssel

Funktionstest

Beim Verwenden des Schlüssels muss dieser mit dem gewählten Kennwort geöffnet werden:

ssh user1@server.host
Enter passphrase for key 'C:\Users\User/.ssh/id_ecdsa':
Last login: Sun Apr 25 22:34:34 2021 from x.x.x.x
user1@server ~

Möchte man nicht jedes mal das Kennwort eingeben, bietet sich ein SSH Agent an.
Dieser hält solange er läuft den SSH-Schlüssel bereit.
Deshalb muss man den privaten Schlüssel nur einmalig öffnen.

ssh-agent bash
ssh-add
# <Passwort eingeben>
``´

Unter Windows kann der Agent-Dienst deaktiviert sein, in diesem Fall muss man diesen vorab mittels Powershell (als Admin) aktivieren:

```powershell
Get-Service -Name ssh-agent | Set-Service -StartupType Manual

Passwort Authentifizierung deaktivieren

Unter bearbeitet man die OpenSSH-Server-Konfiguration und startet den Dienst neu. Falls etwas fehlschlägt, auf gar keinen Fall die Konsolenverbindung trennen.
Ein Neustart bricht eine existierende Verbindung nicht ab, sodass man die Fehlkonfiguration noch reparieren kann! In diesem Beispiel verwenden wir nano (auch wenn ich vim bevorzuge).
Nach Bearbeitung beendet man diesen mit “STRG + X”, “y”, “Enter”.

nano /etc/ssh/sshd_config

# verbietet root Login mittels Passwort
# (ohne SSH Key ist dann kein root Login mehr möglich)
PermitRootLogin prohibit-password

# verbiete generell Passwort-Authentifizierung
PasswordAuthentication no

Ausnahmen für bestimmte Benutzer

Es kann hilfreich sein, einzelnen Benutzern die Authentifizierung dennoch zu erlauben:

# erlaube für Benutzer "user2" Passwort-Authentifizierung
Match User user2
  PasswordAuthentication yes
  
# erlaube allen Benutzern der Gruppe sshpass Passwort-Authentifizierung
Match Group sshpass
  PasswordAuthentication yes

SSH-Daemon neustarten

systemctl restart sshd.service

# im Fehlerfall prüfen:
systemctl status sshd.service

Links

https://www.ssh.com/academy/ssh/keygen

Lets Encrypt Zertifikat via Certbot anfragen

Zertifikate können bequem mittels Certbot angefragt werden, wobei zwischen verschiedenen Verfahren gewählt werden kann. Eine Auflistung der Plugins findet man hier: https://certbot.eff.org/docs/using.html

Folgende Möglichkeiten werden hier erklärt:

• Webroot
• Standalone
• DNS
• Manual

Benötigt man ein Wildcard-Zertifikat (*.domain.de) ist die nur die Verifikation mittels DNS möglich!

Es können bis zu 100 Hostnamen auf ein gemeinsames Zertifikat gelegt werden, welche mittels mehreren “-d”-Parametern erfolgt:

certbot ... -d domain1.de -d my.host.com -d another.host.company.com

Installation

Für Ubuntu und Archlinux stehen Pakete bereit. Liefert das Betriebssystem diese nicht, ist eine Installation auch mittels PIP (Python Package Installer) möglich:

pacman -Syu certbot

apt update && apt install certbot

Webroot

Hierbei schreibt der Certbot eine ACME Challenge Datei in den gewünschten Pfad. Eine andere Anwendung (z.B. nginx) muss diese dann auf Anfrage der Let’s Encrypt Servern ausliefern können. Ist der Inhalt der Datei korrekt, erhält man sein Zertifikat.

certbot certonly -d ${DOMAIN} --non-interactive --agree-tos --email ${MAIL} --webroot /var/www/html/

Standalone (HTTP Port)

Der Certbot bindet sich hierbei an Port 80 und kann mittels HTTP angefragt werden. Der Port kann im Fall einer vorangehenden Belegung (z.B. durch einen Webserver) konfiguriert werden. Dadurch bedingt, dass Let’s Encrypt allerdings nur Port 80 zur Prüfung heranzieht, muss ein Proxy / Webserver dann auf den entsprechenden Port weiterleiten.

Läuft kein Webserver auf dem Host, kann die Standalone Methode mit Port 80 (Standard) genutzt werden.

# direkt, ohne Proxy (nur wenn Port 80 frei ist!)
certbot certonly --standalone -d ${DOMAIN} --non-interactive --agree-tos --email ${MAIL} --http-01-port=80

# Proxy lauscht auf :80, Certbot Port 9999
certbot certonly --standalone -d ${DOMAIN} --non-interactive --agree-tos --email ${MAIL} --http-01-port=9999

Manual

Alle Schritte der Zertifikatsgenerierung können durch individuelle Skripte durchgeführt werden. In diesem Beispiel legt das Skript le-dns-hook.sh den DNS Eintrag an und le-dns-hook-cleanup.sh räumt im Anschluss den Eintrag wieder ab.

Die zu verwendeten Daten (Hostname + ACME Challenge) werden an die Skripte beim Ausführen via Environment-Variablen übergeben, wie hier dokumentiert: https://certbot.eff.org/docs/using.html#pre-and-post-validation-hooks

letsencrypt certonly --manual --preferred-challenges dns \
  --manual-auth-hook "/usr/local/bin/le-dns-hook.sh" \
  --manual-cleanup-hook "/usr/local/bin/le-dns-hook-cleanup.sh" \
  -d ${DOMAIN}

Links

https://certbot.eff.org/docs/using.html