❌

Lese-Ansicht

Ubuntu-Server-Update von 24.04 auf 26.04

Über Ubuntu 26.04 habe ich hier schon berichtet. Heute habe ich meinen ersten Ubuntu-Server von Version 24.04 auf 26.04 aktualisiert. Es ist eigentlich recht gut gegangen. Dieser Beitrag fasst die wichtigsten Erkenntnisse zusammen.

  • MySQL-Passwörter
  • Dovecot-Konfiguration (Update 2.3 -> 2.4)
  • SSH-Server-Konfiguration
  • Externe und obsolete Pakete aufräumen

Grundsätzliche Vorgehensweise

Logischerweise sollten Sie zuerst ein Backup machen. Mein System ist eine virtuelle Maschine (KVM), ich habe also ein Backup des Images gemacht (LVM-Snapshot im laufenden Betrieb). Wäre irgendetwas total schief gegangen, hätte ich den ganzen Server blitzschnell in den alten Zustand zurückversetzen können.

Wichtig: Falls Sie Nextcloud verwenden, aktualisieren Sie die Nextcloud-Version zuerst und führen Sie das Ubuntu-Update erst danach durch. Andernfalls kann es Ihnen passieren, dass Nextcloud danach nicht mehr startet (Fehlermeldung: This version of Nextcloud is not compatible with PHP>=8.5. You are currently running 8.5.4). Es ist ziemlich mühsam, aus dieser Falle wieder herauszukommen, weil die üblichen Update-Mechanismen PHP voraussetzen!

Am Zielsystem habe ich dann ein letztes Update durchgeführt und dann do-release-upgrade gestartet. Der erste Lauf scheiterte an alten MySQL-Passwörtern. Nachdem ich diese umgestellt hatte (Details folgen gleich), lief do-release-upgrade ziemlich problemlos durch.

Bei sämtlichen Rückfragen, ob ich meine geänderten Konfigurationsdateien behalten oder lieber die neuen Konfigurationsdateien verwenden möchte, habe ich mich für meine alten Konfigurationsdateien entschieden. (Die Entscheidung ist nicht ganz einfach: Die neuen Konfigurationsdateien enthalten in der Regel bessere/neuere Einstellungen, die vorzuziehen wären. Umgekehrt will ich aber auch nicht die in der Vergangenheit vorgenommenen Änderungen verlieren.)

Danach ein Reboot, nach 30 Sekunden war ein neuer SSH-Login möglich. Sehr gut!

Jetzt begannen die Aufräumarbeiten. Es gab zwei Hauptprobleme:

  • Dovecot funktionierte nicht mehr (das war zu erwarten).
  • PHP auch nicht (das kam überraschend).

Vor dem Ubuntu-Update: MySQL-Passwörter

Mit Ubuntu 26.04 kommt MySQL 8.4. Diese Version des Datenbank-Servers unterstützt standardmäßig keine mysql_native_password-Passwörter mehr. Das ist an sich vernünftig, die Passwörter werden nach einem unsicheren Verfahren verschlüsselt. Es gibt zwei Lösungen: Eine besteht darin, das nicht mehr empfohlene Plugin mysql_native_password doch wieder zu aktivieren. (In Version 9 wird das aber nicht mehr gehen.) Die andere besteht darin, für alle betroffenen Benutzer ein neues Passwort mit dem Verfahren caching_sha2_password einzurichten, im Wesentlichen so:

ALTER USER name@localhost IDENTIFIED WITH caching_sha2_password BY 'topsecret';

Ich habe mich für diese Variante entschieden, zumal es ohnedies nur wenige betroffene Accounts gab. Zwei bereiteten mir allerdings Kopfzerbrechen. Welche Passwörter sollte ich für die (in der Vergangenheit) automatisch eingerichteten Accounts 'debian-sys-maint'@localhost und mysql.session@localhost verwenden? Eine kurze Recherche ergab, dass sich das Passwort für ersteren Account (eine Debian/Ubuntu-Spezialität) in /etc/mysql/debian.cnf befindet. Der zweite Account ist MySQL-intern. Es muss existieren, ist aber nicht für einen Login gedacht. Jedes zufällige Passwort ist OK.

Das eigentliche Update habe ich NACH den MySQL-Änderungen gestartet.

Nach dem Ubuntu-Update: PHP

Nach dem Update liefen Apache und der MySQL-Server auf Anhieb, nur PHP wollte nicht. Die Fehlermeldung im Apache-Log lautete:

(2)No such file or directory: AH02454: FCGI: attempt to connect to Unix domain socket /run/php/php8.3-fpm.sock (localhost:8000) failed

Der Fehler war leicht zu finden: Ich verwende PHP mit dem FastCGI Process Manager (FPM). Die PHP-Version wurde auf 8.5 aktualisiert, aber die Konfiguration verwies weiter auf die FPM-8.3-Version. Abhilfe:

apt install php-fpm
systemctl enable --now php8.5-fpm
a2disconf php8.3-fpm
a2enconf php8.5-fpm
systemctl restart apache2

Warum der Upgrade-Prozess sich um diese Details nicht gekümmert hat, kann ich nicht sagen. Möglicherweise hatte ich unter Ubuntu 24.04 irgendeine Abweichung von der Default-Konfiguration durchgeführt und die Konfigurationsdateien wurden deswegen nicht aktualisiert.

Ein letzter Hinweis zu PHP: Mit PHP 8.5 werden neue Konfigurationsdateien nach /etc/php/8.5 installiert. In meinem Fall (FPM) ist die Datei /etc/php/8.5/fpm/php.ini relevant. Änderungen, die in der Vergangenheit in der 8.3er-Version von php.ini vorgenommen wurden, müssen jetzt in der 8.5er-Version wiederholt werden. (In meinem Fall war vor allem memory_limit = 512M wichtig, damit Nextcloud ordentlich läuft. Der Defaultwert 128M ist zu klein.)

Dovecot

Dovecot (ein IMAP-Server) macht mit Ubuntu 26.04 einen Versionssprung von 2.3 auf 2.4. Das klingt unspektakulär, aber tatsächlich hat Dovecot mit der neuen Version die Syntax der Konfigurationsdateien grundlegend geändert. Solange die Dateien nicht angepasst werden und insbesondere die Anweisungen dovecot_config_version = 2.4.0 sowie dovecot_storage_version = 2.4.0 an den Beginn von /etc/dovecot.conf eingebaut werden, startet der Dienst nicht.

Upgrading Dovecot CE from 2.3 to 2.4 enthält eine umfassende Migrationsanleitung. Die simple Übernahme der neuen Konfigurationsdateien ist (in meinem Fall) unmöglich, weil ich diverse eigene Anpassungen vorgenommen habe. Schon vor dem Ubuntu-Update habe ich deswegen sicherheitshalber ein Backup des alten Konfigurationsverzeichnisses /etc/dovecot durchgeführt.

Die manuelle Migration erschien mir recht mühsam. Also habe ich Claude Code SSH-Zugriff auf meinen Server gegeben (für einen normalen Account, nicht für root) und habe den folgenden Prompt formuliert:

you can ssh to example.com (no root); go to /etc/dovecot and look at the config files; these are partially from 2.3 and must be updated to 2.4 (see also https://doc.dovecot.org/main/installation/upgrade/2.3-to-2.4.html); explain me what to change, don’t try to do it yourself; summarize your findings locally (not on example.com) into dovecot-migration-plan.md

Diesen Plan habe ich anschließend manuell umgesetzt. Anbei eine Kurzfassung:

Dovecot 2.3 -> 2.4: config changes

dovecot.conf

  Add these as the very first settings:

    dovecot_config_version = 2.4.0
    dovecot_storage_version = 2.4.0

  Remove the empty "dict { }" block.

conf.d/10-auth.conf

  Old: auth_username_format = %Ln
  New: auth_username_format = %{user | username | lower}

conf.d/auth-system.conf.ext

  passdb and userdb blocks need a name:

    passdb pam {
    }
    userdb passwd {
    }

conf.d/10-mail.conf

  mail_location is gone:

    mail_driver = maildir
    mail_path = ~/Maildir

conf.d/10-master.conf

  Old: user = $default_internal_user
  New: user = $SET:default_internal_user

conf.d/10-ssl.conf

  New setting names, no more "<" before file names:

    ssl = yes
    ssl_server_cert_file = /etc/letsencrypt/live/
                           example.com/fullchain.pem
    ssl_server_key_file  = /etc/letsencrypt/live/
                           example.com/privkey.pem
    ssl_server_dh_file   = /etc/dovecot/dh.pem
    ssl_server_prefer_ciphers = server

  (Each path belongs on one line; it is split here only
  for readability.)

  ssl_server_prefer_ciphers accepts "client" or "server";
  "yes" is a fatal error. The DH file is only needed for
  non-ECC key exchange and can be omitted.

conf.d/20-lmtp.conf

  "mail_plugins = $mail_plugins sieve" no longer works:

    protocol lmtp {
      postmaster_address = postmaster@example.com
      mail_plugins {
        sieve = yes
      }
    }

conf.d/90-sieve.conf

  The plugin { } block is gone. Use named script blocks:

    sieve_script personal {
      driver = file
      path = ~/sieve
      active_path = ~/.dovecot.sieve
    }
    sieve_script after {
      type = after
      driver = file
      path = /etc/dovecot/sieve-after
    }

  Recompile global sieve scripts (as root):

    sievec /etc/dovecot/sieve-after/spam-to-folder.sieve

  Users' own scripts are recompiled automatically.

Protocols

  2.4 enables no protocols by default. On Debian they come
  from /usr/share/dovecot/protocols.d, i.e. one file per
  installed package (imapd, lmtpd, managesieved, ...).

Testing

  doveconf -n          # must run without errors
  systemctl restart dovecot
  journalctl -u dovecot -n 50

  Then check IMAP login, LMTP delivery from Postfix, SMTP
  auth via the Postfix SASL socket and sieve filtering.

Eine halbe Stunde später konnte ich in Thunderbird meine Mails wieder abrufen.

Update Configuration File (UCF)

Eine Debian/Ubuntu-Pakete verwenden das Verfahren Update Configuration File (UCF). Bei diesen Paketen wird parallel zur unverändert belassenen Konfigurationsdateien die neue Version der Konfigurationsdatei mit der Kennung *.ucf-dist angelegt. Das ist praktisch, weil Sie unkompliziert danach suchen können:

find /etc -name '*.ucf-dist'

Leider wird UCF nur von ausgewählten Paketen verwendet (auf jeden Fall: apt, dovecot und ssh).

SSH-Server

Der SSH-Server (openssh-server 10.2) läuft zwar auf Anhieb (alles andere wäre ja eine Katastrophe), aber journalctl -u ssh liefert diverse Warnungen:

sshd: rexec line 16: Deprecated option UsePrivilegeSeparation
sshd: rexec line 19: Deprecated option KeyRegenerationInterval
sshd: rexec line 20: Deprecated option ServerKeyBits
sshd: rexec line 31: Deprecated option RSAAuthentication
sshd: rexec line 38: Deprecated option RhostsRSAAuthentication

Also habe ich auch diese Datei etwas aufgeräumt, wobei Claude Code einige weitere Verbesserungsvorschläge gemacht hat (ChallengeResponseAuthentication -> KbdInteractiveAuthentication, PermitRootLogin without-password -> PermitRootLogin prohibit-password, HostKey /etc/ssh/ssh_host_dsa_key entfernen).

Docker

In Ubuntu 24.04 hatte ich Docker-Pakete direkt aus dem Docker-Repo installiert. Die alten Pakete wurden unverändert belassen, Docker funktionierte weiter. Allerdings wurde im Rahmen des Updates die Docker-Paketquelle deaktiviert (siehe /etc/apt/sources.list.d/*.disabled), d.h. ich würde keine Updates mehr erhalten. Ich habe daher die folgende Datei docker.sources neu eingerichtet:

Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: resolute
Components: stable
Architectures: amd64
Signed-By: /etc/apt/keyrings/docker.asc

apt update und apt list --upgradable zeigt jetzt zu Ubuntu 26.04 passende Docker-Pakete an, die ich mit apt dist-upgrade installierte. Ein kurzer Test mit docker ps zeigt, dass alle Docker-Container wie geplant laufen.

Obsolete Pakete entfernen

Das Kommando

apt list '?obsolete'

liefert eine Liste von Paketen, die aus früheren Ubuntu-Versionen stammen (zu meiner Schande bis zurück nach 14.04) und zu denen es keine aktive Paketquellen mehr gibt (z.T. uralte Kernel-Versionen). Höchste Zeit, auch hier aufzuräumen. Ich habe Claude Code um eine Analyse gebeten.

find obsolete packages and access which can be safely removed

In der Folge habe ich die meisten betreffenden Pakete mit apt purge entfernt.

Quellen/Links

  •  

SSH-Server mit 2FA-Login

Der SSH-Dienst ist ein natürliches Angriffsziel jedes Servers. Klassische Abwehrmaßnahmen zielen darauf aus, den root-Login zu sperren (das sollte eine Selbstverständlichkeit sein) und mit Fail2ban wiederholte Login-Versuche zu blockieren. Eine weitere Sicherheitsmaßnahme besteht darin, den Passwort-Login mit einer Zwei-Faktor-Authentifizierung (2FA) zu verbinden. Am einfachsten gelingt das server-seitig mit dem Programm google-authenticator. Zusätzlich zum Passwort muss nun ein One-time Password (OTP) angegeben werden, das mit einer entsprechenden App generiert wird. Es gibt mehrere geeignete Apps, unter anderem Google Authenticator und Authy (beide kostenlos und werbefrei).

Es gibt verschiedene Konfigurationsoptionen. Ziel dieser Anleitung ist es, parallel zwei Authentifizierungsvarianten anzubieten:

  • mit SSH-Schlüssel (ohne 2FA)
  • mit Passwort und One-time Password (also mit 2FA)
Links die App »Google Authenticator«, rechts »Authy«

Grundlagen: sshd-Konfiguration

Vorweg einige Worte zu Konfiguration des SSH-Servers. Diese erfolgt durch die folgenden Dateien:

/etc/ssh/sshd_config
/etc/ssh/sshd_config.d/*.conf
/etc/crypto-policies/back-ends/opensshserver.config  (nur RHEL)

Verwechseln Sie sshd_config nicht mit ssh_config (ohne d) für die Konfiguration des SSH-Clients, also für die Programme ssh und scp! opensshserver.config legt fest, welche Verschlüsselungsalgorithmen erlaubt sind.

Beachten Sie, dass bei Optionen, die in den sshd-Konfigurationsdateien mehrfach eingestellt sind, der erste Eintrag gilt (nicht der letzte)! Das gilt auch für Einstellungen, die am Beginn von sshd_config mit Include aus dem Unterverzeichnis /etc/ssh/sshd_config.d/ gelesen werden und die somit Vorrang gegenüber sshd_config haben.

Werfen Sie bei Konfigurationsproblemen unbedingt auch einen Blick in das oft übersehene sshd_config.d-Verzeichnis und vermeiden Sie Mehrfacheinträge für ein Schlüsselwort!

Weil die Dateien aus /etc/ssh/sshd_config.d/ Vorrang gegenüber sshd_config haben, besteht eine Konfigurationsstrategie darin, sshd_config gar nicht anzurühren und stattdessen alle eigenen Einstellungen in einer eigenen Datei (z.B. sshd_config.d/00-myown.conf) zu speichern. 00 am Beginn des Dateinamens stellt sicher, dass die Datei vor allen anderen Konfigurationsdateien gelesen wird.

Überprüfen Sie bei Konfigurationsproblemen mit sshd -T, ob die Konfiguration Fehler enthält. Wenn es keine Konflikte gibt, liefert sshd -T eine Auflistung aller aktuell gültigen Einstellungen. Die Optionen werden dabei in Kleinbuchstaben angezeigt. Mit grep -i können Sie die für Sie relevante Einstellung suchen:

sshd -T | grep -i permitro

  permitrootlogin yes

Änderungen an sshd_config werden erst wirksam, wenn der SSH-Server die Konfiguration neu einliest. Dazu führen Sie das folgende Kommando aus:

systemctl reload sshd       # RHEL
systemctl reload ssh        # Debian, Ubuntu

google-authenticator einrichten

Google Authenticator bezeichnet zwei unterschiedliche Programme: einerseits die App, die sowohl für iOS als auch für Android verfügbar ist, andererseits ein Linux-Kommando, um die 2FA auf einem Linux-Server einzurichten. Während der Code für die Smartphone-Apps nicht öffentlich ist, handelt es sich bei dem Linux-Kommando um Open-Source-Code. Das resultierende Paket steht für RHEL-Distributionen in der EPEL-Paketquelle zur Verfügung, bei Ubuntu in universe.

dnf install google-authenticator qrencode   # RHEL + EPEL
apt install libpam-google-authenticator     # Debian, Ubuntu

Nach der Installation führen Sie für den Account, als der Sie sich später via SSH anmelden möchten (also nicht für root), das Programm google-authenticator aus. Nachdem Sie den im Terminal angezeigten QR-Code gescannt haben, sollten Sie zur Kontrolle sofort das erste OTP eingeben. Sämtliche Rückfragen können Sie mit y beantworten. Die Rückfragen entfallen, wenn Sie das Kommando mit den Optionen -t -d -f -r 3 -R 30 -W ausführen. Das Programm richtet die Datei .google-authenticator im Heimatverzeichnis ein.

user$ google-authenticator
  Do you want authentication tokens to be time-based (y/n)
  Enter code from app (-1 to skip): nnnnnn
  Do you want me to update your .google_authenticator file? (y/n)
  Do you want to disallow multiple uses of the same
    authentication token? (y/n)
  ...
Zum Einrichten wird das Kommando »google-authenticator« im Terminal ausgeführt. Den QR-Code scannen Sie dann mit der OTP-App Ihrer Wahl ein. (Keine Angst, der hier sichtbare QR-Code stammt nicht von einem öffentlich zugänglichen Server. Er wurde vielmehr testweise in einer virtuellen Maschine erzeugt.)

SSH-Server-Konfiguration

Das nächste Listing zeigt die erforderlichen sshd-Einstellungen. Mit der Methode keyboard-interactive wird PAM für die Authentifizierung verwendet, wobei auch eine mehrstufige Kommunikation erlaubt ist. Die ebenfalls erforderliche Einstellung UsePAM yes gilt bei den meisten Linux-Distributionen standardmäßig. Am besten speichern Sie die folgenden Zeilen in der neuen Datei /etc/ssh/sshd_config.d/00-2fa.conf. Diese wird am Beginn der sshd-Konfiguration gelesen und hat damit Vorrang gegenüber anderen Einstellungen.

# Datei /etc/ssh/sshd_config.d/00-2fa.conf
UsePAM                           yes
PasswordAuthentication           yes
PubkeyAuthentication             yes
ChallengeResponseAuthentication  yes
# Authentifizierung wahlweise nur per SSH-Key oder
# mit Passwort + OTP
AuthenticationMethods            publickey keyboard-interactive

PAM-Konfiguration

Der zweite Teil der Konfiguration erfolgt in /etc/pam.d/sshd. Am Ende dieser Datei fügen Sie eine Zeile hinzu, die zusätzlich zu allen anderen Regeln, also zusätzlich zur korrekten Angabe des Account-Passworts, die erfolgreiche Authentifizierung durch das Google-Authenticator-Modul verlangt:

# am Ende von /etc/pam.d/sshd (Debian, Ubuntu)
...
# Authenticator-Zifferncode zwingend erforderlich
auth required pam_google_authenticator.so

Alternativ ist auch die folgende Einstellung mit dem zusätzlichen Schlüsselwort nullok denkbar. Damit akzeptieren Sie einen Login ohne 2FA für Accounts, bei denen Google Authenticator noch nicht eingerichtet wurde. Sicherheitstechnisch ist das natürlich nicht optimal — aber es vereinfacht das Einrichten neuer Accounts ganz wesentlich.

# am Ende von /etc/pam.d/sshd (Debian, Ubuntu)
...
# Authenticator-Zifferncode nur erforderlich, wenn 
# Google Authenticator für den Account eingerichtet wurde
auth required pam_google_authenticator.so nullok

Wenn Sie RHEL oder einen Klon verwenden, sieht die PAM-Konfiguration ein wenig anders aus. SELinux verbietet dem SSH-Server Zugriff auf Dateien außerhalb des .ssh-Verzeichnisses. Deswegen müssen Sie die Datei .google-authenticator vom Home-Verzeichnis in das Unterverzeichnis .ssh verschieben. restorecon stellt sicher, dass der SELinux-Kontext für alle Dateien im .ssh-Verzeichnis korrekt ist.

user$ mv .google-authenticator .ssh/    (nur unter RHEL!)
user$ restorecon .ssh

In der Zeile auth required übergeben Sie nun als zusätzliche Option den geänderten Ort von .google-authenticator. Falls Sie die nullok-Option verwenden möchten, fügen Sie dieses Schlüsselwort ganz am Ende hinzu.

# am Ende von /etc/pam.d/sshd (RHEL & Co.)
...
auth required pam_google_authenticator.so secret=/home/${USER}/.ssh/.google_authenticator

Test und Fehlersuche

Passen Sie auf, dass Sie sich nicht aus Ihrem Server aussperren! Probieren Sie das Verfahren zuerst in einer virtuellen Maschine aus, nicht auf einem realen Server!

Vergessen Sie nicht, die durchgeführten Änderungen zu aktivieren. Vor ersten Tests ist es zweckmäßig, eine SSH-Verbindung offen zu lassen, damit Sie bei Problemen die Einstellungen korrigieren können.

sshd -T                   # Syntaxtest
systemctl reload sshd     # RHEL
systemctl reload ssh      # Debian + Ubuntu

Bei meinen Tests hat sich die Google-Authenticator-Konfiguration speziell unter RHEL als ziemlich zickig erwiesen. Beim Debugging können Sie client-seitig mit ssh -v, server-seitig mit journalctl -u sshd nach Fehlermeldungen suchen.

Die Anwendung von Google Authenticator setzt voraus, dass die Uhrzeit auf dem Server korrekt eingestellt ist. Die One-Time-Passwords gelten nur in einem 90-Sekunden-Fenster! Das sollten Sie insbesondere bei Tests in virtuellen Maschinen beachten, wo diese Bedingung mitunter nicht erfüllt ist (z.B. wenn die virtuelle Maschine pausiert wurde). Stellen Sie die Zeit anschließend neu ein, oder starten Sie die virtuelle Maschine neu!

Was ist, wenn das Smartphone verlorengeht?

Für den Fall, dass das Smartphone und damit die zweite Authentifizierungsquelle verlorengeht, zeigt das Kommando google-authenticator bei der Ausführung fünf Ziffernfolgen an, die Sie einmalig für einen Login verwendet können. Diese Codes müssen Sie notieren und an einem sicheren Ort aufbewahren — dann gibt es im Notfall einen »Plan B«. (Die Codes sind auch in der Datei .google_authenticator enthalten. Auf diese Datei können Sie aber natürlich nicht mehr zugreifen, wenn Sie keine Login-Möglichkeit mehr haben.)

Die App Google Authenticator synchronisiert die 2FA-Konfiguration automatisch mit Ihrem Google-Konto. Die 2FA-Konfiguration kann daher auf einem neuen Smartphone rasch wieder hergestellt werden. Schon eher bereitet Sorge, dass nur die Kenntnis der Google-Kontodaten ausreichen, um Zugang zur 2FA-Konfiguration zu erhalten. Die Cloud-Synchronisation kann in den Einstellungen gestoppt werden.

Auch Authy kann die 2FA-Konfiguration auf einem Server der Firma Twilio speichern und mit einem weiteren Gerät synchronisieren. Anders als bei Google werden Ihre 2FA-Daten immerhin mit einem von Ihnen zu wählenden Passwort verschlüsselt. Mangels Quellcode lässt sich aber nicht kontrollieren, wie sicher das Verfahren ist und ob es den Authy-Betreibern Zugriff auf Ihre Daten gewährt oder nicht. 2024 gab es eine Sicherheitspanne bei Twilio, bei der zwar anscheinend keine 2FA-Daten kompromittiert wurden, wohl aber die Telefonnummern von 35 Millionen Authy-Benutzern.

Sicherheits- und Privacy-Bedenken

Authenticator-Apps funktionieren prinzipiell rein lokal. Weder der beim Einrichten erforderliche Schlüssel bzw. QR-Code noch die ständig generierten Einmalcodes müssen auf einen Server übertragen werden. Die Apps implementieren den öffentlich standardisierten HMAC-based One-Time Password Algorithmus (OATH-HOTP).

Allerdings bieten einige OTP-Apps die Möglichkeit, die Account-Einträge über ein Cloud-Service zu sichern (siehe oben). Diese Cloud-Speicherung ist eine mögliche Sicherheitsschwachstelle.

Davon losgelöst gilt wie bei jeder App: Sie müssen der Firma vertrauen, die die App entwickelt hat. Der Code der App Google Authenticator war ursprünglich als Open-Source verfügbar, seit 2020 ist das leider nicht mehr der Fall. Wenn Sie weder Google Authenticator noch Authy vertrauen, finden Sie im Arch Linux Wiki Links zu Apps, deren Code frei verfügbar ist.

Quellen, Links

  •  
❌