Obwohl die Bekanntheit von WireGuard in den letzten Monaten stark zugenommen hat, ist das VPN-Protokoll bzw, die VPN-Software immer noch verhältnismäßig unbekannt. Ich nutze WireGuard seit einigen Monaten und möchte es nicht mehr missen. Vor allem der schnelle Verbindungsaufbau, das exzellente Roaming-Verhalten und die gute Performance haben mich überzeugt.

Was sich genau hinter WireGuard verbirgt und wie die Software arbeitet, habe ich bereits in meinem Artikel „​WireGuard – neues VPN-Protokoll mit großer Zukunft“ beschrieben. Jetzt folgt sozusagen der zweite Teil, in dem ich detailliert auf die Einrichtung unter Raspbian Buster und Android eingehe.

WireGuard Installation

Zunächst bringen wir die Paketquellen und alle Pakete auf den aktuellen Stand. Anschließend installieren wir noch die Kernel Headers.

sudo apt update
sudo apt upgrade
sudo apt install raspberrypi-kernel-headers

Nachdem dies erledigt ist, widmen wir uns der Installation von WireGuard.

echo "deb http://httpredir.debian.org/debian buster-backports main contrib non-free" | sudo tee --append /etc/apt/sources.list.d/debian-backports.list
wget -O - https://ftp-master.debian.org/keys/archive-key-$(lsb_release -sr).asc | sudo apt-key add -
sudo apt update
sudo apt install wireguard
sudo reboot

Die Installation an sich ist damit erledigt. Jetzt können wir mit der Konfiguration fortfahren.

Generierung der benötigten Schlüsselpaare

Zum Start benötigen wir jeweils einen privaten und öffentlichen Schlüssel für den Client und den Server.

Die Erstellung der Keys wird im Verzeichnis „/etc/wireguard“ durchgeführt. Damit alle Dateien bei der Erstellung direkt restriktive Berechtigungen haben, muss die umask auf 077 gesetzt werden.

sudo su
cd /etc/wireguard
umask 077
wg genkey | tee peer1_private.key | wg pubkey > peer1_public.key
wg genkey | tee server_private.key | wg pubkey > server_public.key

Mittels „ls“ prüfen wir, ob alle vier Dateien erstellt wurden:

ls
peer1_private.key  peer1_public.key  server_private.key  server_public.key

Zum Schluss können die Keys mittels „cat“ ausgegeben werden, da wir diese später sowieso benötigen.

exit
sudo cat /etc/wireguard/peer1_private.key
sudo cat /etc/wireguard/peer1_public.key
sudo cat /etc/wireguard/server_private.key
sudo cat /etc/wireguard/server_public.key

WireGuard Server Konfiguration erstellen

Im ersten Schritt aktivieren wir das IPv4 Forwarding in der Datei „/etc/sysctl.conf“. Dies kann entweder mit Entfernen der Auskommentierung der Zeile „net.ipv4.ip_forward = 1“ oder alternativ mit diesem Befehl erfolgen:

sudo perl -pi -e 's/#{1,}?net.ipv4.ip_forward ?= ?(0|1)/net.ipv4.ip_forward = 1/g' /etc/sysctl.conf

sudo reboot

Wir überprüfen den Status mit folgendem Befehl:

sysctl net.ipv4.ip_forward

Wenn das IPv4 Forwarding aktiv ist muss als Ergebnis „net.ipv4.ip_forward = 1“ zurückgegeben werden.

Jetzt erstellen wir die WireGuard-Konfiguration „/etc/wireguard/wg0.conf“. Welchen Editor ihr bevorzugt, bleibt natürlich euch überlassen.

sudo vim /etc/wireguard/wg0.conf

Folgendes Template könnt ihr als Ausgangsbasis nutzen.

[Interface]
Address = 100.64.0.1/24
ListenPort = 51820
PrivateKey = <insert server_private.key>

#replace eth0 with the interface open to the internet (e.g might be wlan0)
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

#Client1 Smartphone
[Peer]
PublicKey = <insert peer1_public.key>
AllowedIPs = 100.64.0.2/32

Neben den IP-Adressen müsst ihr den privaten Schlüssel vom Server und den öffentlichen Schlüssel vom Client ergänzen. Außerdem müsst ihr bei den iptables-Regeln evtl. die Netzwerkschnittstelle anpassen. Optional könnt ihr zudem einen anderen Port definieren. Wenn alles erledigt ist, solltest ihr die Datei unbedingt speichern.

WireGuard Client Konfiguration erstellen

Am besten erstellt ihr für jeden Client eine eigene Konfiguration.

sudo vim /etc/wireguard/peer1.conf

Folgendes Template könnt ihr als Ausgangsbasis nutzen.

[Interface]
Address = 100.64.0.2/32
DNS = 192.168.178.1
PrivateKey = <insert peer1_private.key>

#Server
[Peer]
PublicKey = <insert server_public.key>
Endpoint = t6bibneqwcjxplum.myfritz.net:51820
AllowedIPs = 0.0.0.0/0, ::/0
#PersistentkeepAlive = 25

Hier müsst ihr unter „[Interface]“ die IP-Adresse des Clients anpassen und den gewünschten DNS-Server eintragen. In meinem Beispiel verwende ich die private IP der FRITZ!Box. Wer daheim Pi-Hole im Einsatz hat, kann hier die Pi-Hole Adresse eintragen und kommt somit auch von unterwegs in den Genuss der Werbefreiheit.

Außerdem müsst ihr noch den privaten Schlüssel des Clients ergänzen.

Unter „[Peer]“ tragt ihr zunächst den öffentlichen Schlüssel des Servers ein.

Anschließend folgt die Internetadresse, unter welcher der WireGuard-Server erreichbar ist. Üblicherweise gibt es hier zwei Dinge zu beachten. Bei eurem Internetanschluss daheim, bekommt ihr mit großer Wahrscheinlichkeit eine dynamische IP-Adresse vom Provider zugewiesen. Der WireGuard-Client müsste die wechselnden IP-Adressen stets kennen, um sich zu verbinden. Als Hilfe kommt hier ein dynamischer DNS-Anbieter ins Spiel, der einen festen Domainnamen bereitstellt und dahinter automatisch die jweils aktuelle IP-Adresse zuweist. Bei Verwendung einer FRITZ!Box könnt ihr beispielsweise den Dienst „MyFRITZ!“ nutzen. Eine andere Alternative wäre FreeDNS. Der zweite Punkt ergibt sich, wenn der Raspberry Pi in eurem Heimnetzwerk steht. In diesem Fall müsst ihr an eurem Router ein Port-Forwarding einrichten (UDP 51820), sodass der WireGuard-Traffic des Clients auf den Server weitergeleitet wird.

Unter „AllowedIPs“ wird definiert, welche IP-Ranges über das WireGuard-VPN geroutet werden. Mit „0.0.0.0/0, ::/0“ wird der komplette IPv4- und IPv6-Traffic geroutet (full tunnel). Mit 192.168.178.0/24 könnt ihr z.B. nur euer Heimnetzwerk routen (split tunnel).

„PersistentKeepalive“ ist standardmäßig deaktiviert. Zunächst ein paar Hintergrundinfos um einzuordnen, ob ihr dieses Feature benötigt oder nicht. Normalerweise ist WireGuard nicht sehr gesprächig und sendet nur Daten, wenn etwas zu übertragen ist. Ansonsten verhält sich WireGuard ruhig. Wenn sich der Server hinter einem NAT oder einer Firewall befindet und der Client für eine bestimmte Zeit keine Daten zum Server sendet, entfernt der NAT-Router bzw. die Firewall den Host-Status aus der Verbindungstabelle. Falls jetzt der Server ein Paket zum Client sendet, kommt dieses nicht an, da der NAT-Router bzw. die Firewall nicht weiß, was mit dem Paket zu tun ist. Mit der Option „PersistentKeepalive“ sendet der Client alle x Sekunden ein leeres Paket, um die Verbindung aufrechtzuhalten. Ein Wert von 25 Sekunden hat sich in der Praxis bewährt und funktioniert mit einem Großteil von Firewalls und NAT-Routern.

Kurz zusammengefasst benötigt ihr dieses Feature also nur, wenn ihr vom Server euren Client erreichen möchtet, obwohl dieser seit längerer Zeit keine Pakete gesendet hat. Die meisten Benutzer werden dieses Feature nicht benötigen. Falls doch, einfach die Auskommentierung der Zeile rückgängig machen.

WireGuard Server starten

Nun können wir WireGuard auf dem Server starten. Anstatt alle einzelnen Schritte manuell mit dem „wg“-Tool durchzuführen, bedienen wir uns beim Tool „wg-quick“.

sudo wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 100.64.0.1/24 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Danach prüfen wir den Status der wg0-Schnittstelle.

sudo wg
interface: wg0
  public key: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxljP1wpITnI=
  private key: (hidden)
  listening port: 51820

peer: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxtJd9/esWN4=
  allowed ips: 100.64.0.2/32

Der Server läuft und ist für die Verbindung des Clients bereit.

WireGuard beenden funktioniert mit diesem Befehl:

sudo wg-quick down wg0

Wenn WireGuard beim Systemstart automatisch geladen werden soll, kann dies mit folgendem Befehl realisiert werden:

sudo systemctl enable wg-quick@wg0
Created symlink /etc/systemd/system/multi-user.target.wants/wg-quick@wg0.service → /lib/systemd/system/wg-quick@.service.

Der Daemon kann folgendermaßen gesteuert werden. Dabei müsst ihr allerdings darauf achten, dass ihr WireGuard zuerst beendet, sofern ihr es manuell gestartet habt.

sudo systemctl start wg-quick@wg0
sudo systemctl stop wg-quick@wg0
systemctl status wg-quick@wg0

Zum Schluss werden die Berechtigungen von „/etc/wireguard/“ und allen Dateien noch einmal korrigiert. Damit wird sichergestellt, dass nur root die entsprechenden Berechtigungen besitzt.

sudo chown -R root:root /etc/wireguard/
sudo chmod -R og-rwx /etc/wireguard/*

WireGuard Client unter Android einrichten

Die Einstellungen in der Android-App können manuell, mittels einer Datei oder mit einem QR-Code erfolgen. Die letzte Variante ist dabei am bequemsten. Hierfür muss auf dem Server der QR-Code erstellt werden.

sudo apt install qrencode

Nach dem Installieren von „qrencode“ kann der QR-Code von der Client-Konfiguration erstellt werden:

sudo cat /etc/wireguard/peer1.conf | qrencode -t ansiutf8

Auf dem Android-Gerät muss zunächst die WireGuard App via Google Play installiert werden. Daraufhin kann der erstellte QR-Code mit der App gescannt werden, um die Konfiguration zu importieren. Nachdem ein Name vergeben wurde, kann die Verbindung aktiviert werden.

Mit einem Klick auf den gerade erstellten Tunnel werden einige Infos angezeigt, unter anderem auch eine Trafficstatistik.

Auf dem Server kann ebenfalls der Status ausgegeben werden. Dort werden unter anderem alle verbundenen Clients angezeigt:

sudo wg
interface: wg0
  public key: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxljP1wpITnI=
  private key: (hidden)
  listening port: 51820

peer: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxtJd9/esWN4=
  endpoint: 11.12.13.14:53019
  allowed ips: 100.64.0.2/32
  latest handshake: 56 seconds ago
  transfer: 927.04 KiB received, 64.85 MiB sent

Der Client kann nun auch via Ping erreicht werden:

ping 100.64.0.2
PING 100.64.0.2 (100.64.0.2) 56(84) bytes of data.
64 bytes from 100.64.0.2: icmp_seq=1 ttl=64 time=95.9 ms
64 bytes from 100.64.0.2: icmp_seq=2 ttl=64 time=112.4 ms
64 bytes from 100.64.0.2: icmp_seq=3 ttl=64 time=71.7 ms

Noch zwei kleine Tipps für die Android-App. Ich importieren die Konfig vom Server immer zweimal. Einmal als „full tunnel“ mit „0.0.0.0/0, ::/0“ und einmal als „split tunnel“, lediglich mit dem Heimnetzwerk eingetragen, z.B. 192.168.178.0/24. So habt ihr volle Kontrolle und könnt je nach Situation den richtigen Tunnel nutzen.

Beim Bearbeiten eines Tunnels (Tunnel Infos anzeigen und dann rechts oben auf das Stift-Icon) könnt ihr außerdem festlegen, welche Apps keinen Traffic über den Tunnel schicken dürfen.

Troubleshooting

WireGuard ist ein Kernel-Modul, das via DKMS automatisch installiert wird, sobald das System einen neuen Kernel benutzt. In seltenen Fällen kann es jedoch passieren, dass WireGuard nicht automatisch eingebunden wird und mit dem neuen Kernel nicht mehr funktioniert.

In diesem Fall sollte zunächst geprüft werden, ob das WireGuard Modul geladen wurde:

lsmod | grep wireguard

Falls nicht kann es hilfreich sein, das Kernel-Modul neu zu konfigurieren:

sudo dpkg-reconfigure wireguard-dkms
sudo modprobe wireguard

Wenn dies keine Abhilfe schafft, könnt ihr noch folgendes ausprobieren:

sudo apt remove wireguard
sudo apt install bc libncurses5-dev
sudo apt install wireguard

Sollte dies auch keine Besserung bringen, könnt ihr alternativ das WireGuard Kernel Module und das wg Tool selber kompilieren. Davor muss aber sichergestellt sein, dass alle installierten WireGuard-Pakete deinstalliert sind!

sudo apt remove wireguard
# Toolchain installieren
sudo apt install libmnl-dev raspberrypi-kernel-headers build-essential git pkg-config
#Code laden
git clone https://git.zx2c4.com/wireguard-linux-compat
git clone https://git.zx2c4.com/wireguard-tools
# Kernel Module und das wg Tool kompilieren und installieren
make -C wireguard-linux-compat/src -j$(nproc)
sudo make -C wireguard-linux-compat/src install
make -C wireguard-tools/src -j$(nproc)
sudo make -C wireguard-tools/src install
# Neustarten und fertig
sudo reboot

Die aktuell installierte Version könnt ihr am besten via „dmesg“ herausfinden:

dmesg | grep wireguard
[   15.677458] wireguard: loading out-of-tree module taints kernel.
[   15.687104] wireguard: WireGuard 0.0.20200318 loaded. See www.wireguard.com for information.
[   15.687119] wireguard: Copyright (C) 2015-2019 Jason A. Donenfeld . All Rights Reserved.

Quellen

• https://www.wireguard.com/install/
• https://github.com/adrianmihalko/raspberrypiwireguard
• https://www.reddit.com/r/pihole/comments/bnihyz/guide_how_to_install_wireguard_on_a_raspberry_pi/
• https://emanuelduss.ch/2018/09/wireguard-vpn-road-warrior-setup/
• https://www.bachmann-lan.de/raspberry-pi-mit-wireguard-als-vpn-server-mit-wireguard/

Die wohl am häufigsten genutzte Methode zur Administration eines Raspberry Pis ist Secure Shell (SSH). In den aktuellen Raspbian Versionen ist SSH bereits integriert und muss lediglich aktiviert werden.

Im aktuellen Raspbian Buster (basiert auf Debian 10 Stable) kommt OpenSSH in Version 7.9p1 zum Einsatz. Die Standard-Konfiguration ist in puncto Sicherheit zwar in Ordnung, aber mit einigen Handgriffen lässt sich die Administrationsschnittstelle deutlich besser absichern. Damit steigt die Hürde für potenzielle Angreifer deutlich. Dies ist vor allem wichtig, wenn euer Pi aus dem Internet erreichbar ist.

Grundlagen und hilfreiche Befehle

OpenSSH besteht aus zwei Teilen: Dem Server Daemon (sshd) und dem Client (ssh). In diesem Tutorial widme ich mich ausschließlich sshd. Die Konfigurationsdatei des Servers befindet sich hier:

/etc/ssh/sshd_config

Der Status des sshd-Daemons kann mit folgendem Befehl abgefragt werden:

systemctl status ssh.service
● ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2019-11-02 08:44:33 GMT; 2 weeks 3 days ago

Damit könnt ihr sicherstellen, dass sshd automatisch startet (enabled) und gerade läuft (active (running)). Des Weiteren seht ihr auch die 10 letzten Logeinträge.

Mit folgendem Befehl könnt ihr die aktiven SSH-Sessions einsehen:

ss -n -o state established '( dport = :22 or sport = :22 )'

Bei Änderungen an der Server-Konfiguration empfehle ich diese vor dem Neustart des Dienstes zu prüfen. Damit könnt ihr Syntaxfehler und Probleme mit ungültigen Einstellungen in „/etc/ssh/sshd_config“ verhindern:

sudo sshd -t

Zum Anwenden der Änderungen empfehle ich sshd folgendermaßen neuzustarten. Mit dieser Variante besteht die größte Chance, dass offene Remote-Sessions nicht geschlossen werden.

sudo systemctl reload ssh.service

SSH-Server: Einstellungen

Wie oben bereits erwähnt lassen sich die Einstellungen in der Datei „/etc/ssh/sshd_config“ anpassen und sind nach einem Neustart von sshd aktiv. Einige Einstellungen sind bereits standardmäßig deaktiviert. Diese sind in der Config-Datei auskommentiert. Es schadet jedoch nicht diese noch einmal zu überprüfen.
Über die Protokoll-Version müssen wir uns keine Sorgen machen, da ab OpenSSH 7.0 SSH Version  1 bereits beim Kompilieren deaktiviert wird.
Standardmäßig hört der Server auf Port 22. Dieser kann geändert werden, um beispielsweise die Anzahl der Angriffe zu verringern. Einen Sicherheitsgewinn gibt es meiner Meinung nach nicht.
Wenn der Server mehrere IP-Adressen besitzt, kann über „ListenAdress“ eingeschränkt werden, auf welcher IP eine Verbindung akzeptiert werden soll.

#Port22
#ListenAddress 0.0.0.0
#ListenAddress ::

Da wir auf unserem Raspberry keine grafische Benutzeroberfläche haben, können wir das X11-Protokoll getrost deaktiviert lassen. Davon abgesehen wird vom Server ein Rückkanal zum Client geöffnet, was sicherheitstechnisch nicht ganz unbedenklich ist.

#X11Forwarding no

Mittels .rhosts-Datei kann der Zugriff von fremden Systemen lediglich anhand der IP-Adresse erlaubt werden. Dieser Zugriff ist heutzutage nicht mehr üblich und daher standardmäßig deaktiviert.

#IgnoreRhosts yes

Useraccounts ohne Passwort dürfen sich nicht via SSH anmelden. Auch diese Option ist per Default deaktiviert.

#PermitEmptyPasswords no

Eine direkte Anmeldung mit dem Account „root“ sollte in der Regel nicht erlaubt werden (PermitRootLogin no). Falls dies aus bestimmten Gründen dennoch notwendig sein sollte, ist die Option „without-password“ in Ordnung. Diese ist standardmäßig gesetzt und erlaubt eine Public-Key-Authentifizierung mit dem root Account.

#PermitRootLogin without-password

Die maximale Zahl der Anmeldeversuche pro User sind standardmäßig auf 6 gesetzt. Ich würde empfehlen den Wert weiter zu verringern, beispielsweise auf 3.

MaxAuthTries 3

Inaktive Sessions können nach einer bestimmten Zeit automatisch beendet werden. Mit „ClientAliveInterval“ wird festgelegt, nach wie vielen Sekunden Inaktivität der Server eine Nachricht an den Client sendet. „ClientAliveCountMax“ ist die Anzahl, wie oft dies der Server wiederholt, bis der Client getrennt wird. In meinem Beispiel oben wird der Client nach 15 Minuten getrennt.

ClientAliveInterval 300
#ClientAliveCountMax 3

Normalerweise erfolgt die Anmeldung am Server mit Username und Passwort. Eine bessere Alternative ist die Public-Key-Authentifizierung. Diese ist bereits standardmäßig erlaubt.

#PubkeyAuthentication yes

Zur Einrichtung muss auf dem Client zunächst ein neues Schlüsselpaar generiert werden. Wählt hier „Ed25519“, sofern nichts gravierendes dagegenspricht. Unter Windows könnt ihr dies prima mit PuTTYGen erledigen. Ab Windows 10 1809 kann dies auch direkt via PowerShell oder der Eingabeaufforderung erledigt werden. Unter Linux nutzt ihr ssh-keygen. Der Einsatz einer Passphrase ist zwar optional, aber ich empfehle ein starkes Passwort zu verwenden, um den Key vor Missbrauch zu schützen.

ssh-keygen -o -a 100 -t ed25519 -f ~/.ssh/id_ed25519

Im nächsten Schritt muss der Public Key auf dem Server eingetragen werden. PuTTYGen stellt euch den String bereit, den ihr in die „authorized_keys“ kopieren müsst.

ssh pi@192.168.10.10
mkdir ~/.ssh
chmod 700 ~/.ssh
vi ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Unter Linux geht dies mit „ssh-copy-id“ etwas einfacher.

ssh-copy-id -i ~/.ssh/id_ed25519.pub pi@192.168.10.10

Abschließend solltet ihr prüfen, ob die Anmeldung via Public-Key-Authentifizierung funktioniert. Falls ja, könnt ihr nun die Passwort-Anmeldung an eurem SSH-Server deaktivieren.

PasswordAuthentication no
#ChallengeResponseAuthentication no

SSH-Server: Cipher-Suites und Verschlüsselungsalgorithmen

Zur Prüfung, welche Cipher-Suites und Verschlüsselungsalgorithmen euer OpenSSH-Server anbietet, eignet sich das Python-Script „ssh-audit“:

cd ~
wget https://github.com/jtesta/ssh-audit/releases/download/v2.1.0/ssh-audit-2.1.0.tar.gz
tar -xvzf ssh-audit-2.1.0.tar.gz
~/ssh-audit-2.1.0/ssh-audit.py localhost

Alternativ könnt ihr auch Nmap dazu verwenden:

nmap -p22 -n -sV --script ssh2-enum-algos localhost

Schauen wir uns zunächst die Algorithmen für den Schlüsseltausch an. Falls Curve25519 nicht ausreichend ist, könnt ihr noch „diffie-hellman-group-exchange-sha256“ hinzufügen.

KexAlgorithms curve25519-sha256@libssh.org

Danach folgen die Schlüssel bzw. Algorithmen für die Authentifizierung. Hier solltet ihr alle vorhandenen Host-Schlüssel löschen und neu generieren.

cd /etc/ssh
sudo rm ssh_host_*key*
sudo ssh-keygen -t ed25519 -f ssh_host_ed25519_key -N "" < /dev/null
sudo ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key -N "" < /dev/null

Anschließend könnt ihr in eure „sshd_config“ folgendes eintragen:

HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key
HostKeyAlgorithms ssh-ed25519,ssh-rsa

Als nächstes nehmen wir uns den symmetrischen kryptographischen (Ciphers) sowie MAC (Message Authentication Code) Algorithmen an. Folgendes gilt aktuell als sicher:

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com

Prüft zur Sicherheit, dass ihr vor dem Neustart von sshd eine Verbindung habt, damit ihr euch im Notfall nicht den Zugang zu eurem Raspberry absägt.

Einen guten Artikel mit weiteren Details über die einzelnen Cipher-Suites und Verschlüsselungsalgorithmen findet ihr hier: https://stribika.github.io/2015/01/04/secure-secure-shell.html