Lese-Ansicht

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

  •  

Stellungnahme der OSBA zur Reform des Europäischen Vergaberechts

Die EU-Kommission plant eine Reform des EU-Vergaberechts, hierfür sollen die entsprechenden europäischen Vergabe-Richtlinien („Public Procurement Directives“) überarbeitet werden. In einem ersten Schritt hat die EU-Kommission die Öffentlichkeit dazu aufgerufen, im Rahmen eines Evaluationsverfahrens Stellungnahmen abzugeben. Die Working Group Beschaffung in der Open Source Business Alliance (OSBA) hat im Rahmen dieser Evaluation eine Stellungnahme abgegeben.

Quelle

  •  

Debian 13 „Trixie“ – Installer als Release Candidate verfügbar

Die Veröffentlichung von Debian 13 rückt näher. Mit dem ersten Release Candidate (RC1) des neuen Installers wird das Bild der kommenden Version klarer. Neben technischer Feinarbeit bringt das Update sichtbare Verbesserungen für Desktop- und Servernutzer gleichermaßen. Ein Highlight: Der Kernel wurde auf Version 6.12.27 aktualisiert, gleichzeitig entfällt die Unterstützung für den win32-loader, was die Codebasis […]

Der Beitrag Debian 13 „Trixie“ – Installer als Release Candidate verfügbar erschien zuerst auf fosstopia.

  •  

Debian 12.11 veröffentlicht – Sicherheit, Stabilität und frische Installationsmedien

Debian hat die Version 12.11 seiner stabilen „Bookworm“ Serie veröffentlicht. Dieses elfte Point-Release bringt zahlreiche Fehlerkorrekturen und Sicherheitsupdates, hauptsächlich als Konsolidierung bereits veröffentlichter Sicherheitsaktualisierungen. Für bestehende Systeme, die regelmäßig aktualisiert werden, ändert sich wenig. Für Neuinstallationen ist es hingegen der neue Standard und spart nach Installation das Runterladen hunderter Aktualisierungen. Besonders auffällig ist der aktualisierte […]

Der Beitrag Debian 12.11 veröffentlicht – Sicherheit, Stabilität und frische Installationsmedien erschien zuerst auf fosstopia.

  •  

Wissen teilen, Zukunft gestalten: Blueshoe bei der OSBA

Blueshoe ist neues Mitglied der Open Source Business Alliance! Das Münchner Unternehmen entwickelt maßgeschneiderte Softwarelösungen auf Basis von Open Source – mit Fokus auf Python, Django und Kubernetes. Im Interview erklärt Blueshoe, warum digitale Souveränität so wichtig ist und wie sie mit eigenen Tools wie Gefyra und viel Community-Spirit zur Open-Source-Zukunft beitragen.

Quelle

  •  

Digitale Sanktionen gegen Internationalen Strafgerichtshof müssen ein Weckruf für deutsche Behörden sein

Die von den USA angeordneten und von Microsoft mit umgesetzten Sanktionen gegen den internationalen Strafgerichtshof in Den Haag müssen ein Weckruf für alle sein, die für die sichere Verfügbarkeit staatlicher und privater IT- und Kommunikationsinfrastrukturen verantwortlich sind. Sie zeigen: Wir können uns nicht auf Unternehmen verlassen, die nicht unter unserer Jurisdiktion stehen.

Quelle

  •  

Grafana 12, k6-Stable und neue KI-Hilfe vorgestellt

Beim diesjährigen GrafanaCON in Seattle präsentierte Grafana Labs mehrere bedeutende Neuerungen für ihre Open-Source-Tools. Die Veranstaltung gilt als Treffpunkt der Observability-Community und brachte Entwickler, Experten und Enthusiasten zusammen. Mit Grafana 12 erscheint die neueste Version des beliebten Monitoring-Werkzeugs. Sie bringt unter anderem ein klareres JSON-Format, dynamische Dashboards, GitHub-Synchronisation und 15 neue Datenquellen wie Azure CosmosDB […]

Der Beitrag Grafana 12, k6-Stable und neue KI-Hilfe vorgestellt erschien zuerst auf fosstopia.

  •  

Zorin OS 16 erreicht bald das Support-Ende. Upgrade dringend empfohlen

Am 31. Mai 2025 endet der offizielle Support für Zorin OS 16. Ab diesem Zeitpunkt wird es keine Sicherheitsupdates oder Fehlerbehebungen mehr geben. Nutzerinnen und Nutzer sollten deshalb rasch auf die aktuelle Version Zorin OS 17.3 umsteigen. Zorin OS 17.3 bringt zahlreiche Verbesserungen und wird mindestens bis Juni 2027 mit Updates versorgt. So bleibt das […]

Der Beitrag Zorin OS 16 erreicht bald das Support-Ende. Upgrade dringend empfohlen erschien zuerst auf fosstopia.

  •  

Linux kostenlos testen: Keine Sorge vor dem Windows 10 Ende

Der Abschied von Windows 10 zwingt viele Nutzer zum Handeln. Doch nicht jeder Rechner erfüllt die Anforderungen für Windows 11. Linux bietet eine kostenfreie, sichere Alternative - selbst für Einsteiger. Besonders praktisch: Es lässt sich testen, ohne gleich installiert zu werden. Wie funktioniert dieser risikofreie Umstieg auf ein neues Betriebssystem?

Der Beitrag Linux kostenlos testen: Keine Sorge vor dem Windows 10 Ende erschien zuerst auf Linux Abos.

  •  

Identität im Internet schützen: Welche Fehler darf man nicht machen?

Ob Online-Shopping, Social Media oder Streaming – überall hinterlassen Menschen digitale Spuren, aus denen sich eine persönliche Identität ableiten lässt. Diese Identität wird oft unterschätzt, obwohl sie zu den sensibelsten Gütern der digitalen Welt zählt. Wie lassen sich die größten Gefahren im Netz vermeiden und welche Fehler öffnen Angreifern Tür und Tor?

Der Beitrag Identität im Internet schützen: Welche Fehler darf man nicht machen? erschien zuerst auf Linux Abos.

  •  

Red Hat Enterprise Linux 10 vorzeitig verfügbar – Start von RHEL 10 wohl beim Summit

Kurz vor dem offiziellen Start des Red Hat Summit 2025 in Boston hat Red Hat offenbar still und leise RHEL 10 veröffentlicht. Durch einen Leak gab es einen ersten Hinweis auf der japanischen Version der Red-Hat-Website. Dort wurde die Version 10.0 samt Kernel 6.12.0 als „General Availability“-Release gelistet – Codename: Coughlan. Inzwischen wurden auch verschiedene […]

Der Beitrag Red Hat Enterprise Linux 10 vorzeitig verfügbar – Start von RHEL 10 wohl beim Summit erschien zuerst auf fosstopia.

  •  

Databricks kauft Neon

Die Datenanalyse-Plattform Databricks kauft die Open-Source-Datenbank Neon (Lizenz Apache 2.0), eine skalierbare PostgreSQL-basierte Alternative zu AWS Aurora Postgres, für rund eine Milliarde…

  •  

Auf zu neuen Ufern

Die Initiative Sovereign Cloud Stack (SCS) wurde nach einer positiven Validierung der Projektidee durch die Bundesagentur für Sprunginnovationenen SPRIND in der Zeit von 2021 bis 2024 als Projekt der Open Source Business Alliance – Bundesverband für digitale Souveränität e.V. (OSBA) vom Bundesministerium für Wirtschaft und Klimaschutz (BMWK) mit 12,2 Mio. € gefördert. Nach dem erfolgreichen Abschluss der Förderphase wurde nun der offizielle Abschlussbericht veröffentlicht und beim BMWK eingereicht.

Quelle

  •  

Nextcloud kritisiert Google wegen Upload-Blockade in Android

Der Android-Client von Nextcloud kann seit Monaten keine vollständigen Datei-Uploads mehr durchführen. Betroffen sind alle Dateitypen außer Fotos und Videos. Grund ist eine Entscheidung von Google, die laut Nextcloud ohne Vorwarnung getroffen wurde. Im September 2024 entzog Google der App eine zentrale Berechtigung. Diese war nötig, um auf alle Dateien zugreifen zu können. Seitdem erlaubt […]

Der Beitrag Nextcloud kritisiert Google wegen Upload-Blockade in Android erschien zuerst auf fosstopia.

  •  

Canonical spendet monatlich 10.000 Dollar an Open-Source-Projekte

Ubuntu-Hersteller Canonical hat ein neues Förderprogramm gestartet. In den kommenden zwölf Monaten will das Unternehmen insgesamt 120.000 US-Dollar an kleinere Open-Source-Projekte spenden. Die monatlichen Zahlungen in Höhe von 10.000 Dollar richten sich an Entwickler, deren Tools Canonical selbst nutzt. Verteilt werden die Mittel über die Plattform thanks.dev. Diese analysiert, welche externen Bibliotheken, Tools und Abhängigkeiten […]

Der Beitrag Canonical spendet monatlich 10.000 Dollar an Open-Source-Projekte erschien zuerst auf fosstopia.

  •  

Woran erkennt man eine sichere Sportwetten-App?

Sportwetten per App boomen – doch mit der wachsenden Nachfrage steigt auch das Betrugsrisiko. Gefälschte Anwendungen locken mit Boni und stehlen persönliche Informationen. Eine sichere Sportwetten-App schützt Nutzer mit erkennbaren Standards: SSL-Verschlüsselung, Zwei-Faktor-Authentifizierung, regulierte Lizenz und seriöser Support. Woran erkennt man verlässliche Anbieter im App-Dschungel?

Der Beitrag Woran erkennt man eine sichere Sportwetten-App? erschien zuerst auf Linux Abos.

  •  

Nobara 42 erschienen: Neue Version mit Rolling-Release und Gaming Fokus

Die auf Fedora basierende Linux-Distribution Nobara hat Version 42 veröffentlicht. Neuerdings setzt das Projekt vollständig auf ein Rolling-Release-Modell. Zielgruppe bleiben weiterhin Gamer und Kreative, die ein stabiles, performantes System suchen. Auffällig ist der Wechsel des Standardbrowsers. Brave ersetzt Firefox, nachdem dieser in Tests bei aktivem VRR-Modus regelmäßig abstürzte. Auch Chromium-Varianten wie Vivaldi bereiteten Probleme, besonders […]

Der Beitrag Nobara 42 erschienen: Neue Version mit Rolling-Release und Gaming Fokus erschien zuerst auf fosstopia.

  •  

Flatpak 1.16.1 veröffentlicht: Mehr Kontrolle, mehr Sicherheit, mehr Effizienz

Die plattformübergreifende Linux-Paketlösung Flatpak ist in Version 1.16.1 erschienen. Das erste Wartungsupdate der 1.16-Serie bringt viele Detailverbesserungen, die sowohl Nutzern als auch Administratoren zugutekommen. Im Fokus stehen neben besserer Performance und optimiertem Speicherverbrauch vor allem Sicherheitsaspekte. Besonders relevant ist die überarbeitete Kindersicherung. Kinderkonten dürfen ab sofort standardmäßig installierte Flatpak-Anwendungen selbstständig aktualisieren. Dadurch gelangen wichtige Sicherheitsupdates […]

Der Beitrag Flatpak 1.16.1 veröffentlicht: Mehr Kontrolle, mehr Sicherheit, mehr Effizienz erschien zuerst auf fosstopia.

  •  

Mozilla veröffentlicht Firefox 138.0.3

Mozilla hat Firefox 138.0.3 veröffentlicht und behebt damit mehrere Probleme der Vorgängerversion.

Download Mozilla Firefox 138.0.3

Mozilla hat Firefox 138.0.3 für Windows, macOS und Linux veröffentlicht. Firefox 138.0.2 wurde für diese Plattformen übersprungen, da Firefox 138.0.2 ein Update war, welches ausschließlich für Android erschienen war.

Die seit Firefox 137 schrittweise ausgerollte Unterstützung für Tab-Gruppen ist ab sofort für alle Nutzer standardmäßig aktiviert.

Firefox 137

25 Prozent der neuen Nutzer auf Windows und macOS sehen beim ersten Start von Firefox einen Dialog zur Zustimmung der Nutzungsbedingungen und des Datenschutzhinweises von Firefox.

Nutzungsbedingungen und Datenschutzhinweis Firefox 138.0.3

Die Links zur Mozilla-Dokumentation im Abschnitt „Surfen“ in den Firefox-Einstellungen funktionierten nicht mehr.

Die Tastenkombination Alt + C hatte bei Verwendung der Funktion „Seite durchsuchen“ nicht länger die Checkbox „Groß-/Kleinschreibung“ aktiviert respektive deaktiviert.

Unter Linux wurde ein Problem behoben, bei dem die Videowiedergabe unter Wayland verwaschen erschien, wenn keine HDR-Unterstützung verfügbar war.

Eine mögliche Absturzursache in Zusammenhang mit WebGL sowie eine weitere mögliche Absturzursache in Zusammenhang mit bestimmten SVG-Filtern wurde behoben.

Darüber hinaus wurden mehrere Webkompatibilitätsprobleme behoben.

Der Beitrag Mozilla veröffentlicht Firefox 138.0.3 erschien zuerst auf soeren-hentzschel.at.

  •  

Abschied von Windows 10 – Initiative „End of 10“ ins Leben gerufen

Am 14. Oktober 2025 endet der offizielle Support für Windows 10. Das bedeutet: Keine Sicherheitsupdates mehr, keine Fehlerbehebungen, kein Support durch Microsoft. Millionen Nutzer weltweit stehen dadurch vor einer schwierigen Entscheidung. Besonders betroffen sind Geräte, die vor 2017 gekauft wurden. Sie laufen mit Windows 10 meist problemlos, erfüllen aber nicht die Anforderungen für Windows 11 […]

Der Beitrag Abschied von Windows 10 – Initiative „End of 10“ ins Leben gerufen erschien zuerst auf fosstopia.

  •  

Codeberg.org mit Forgejo Actions, Runner, Workflows und ich

In diesem Artikel halte ich fest, was es mit den genannten Begriffen auf sich hat und was ich in den vergangenen Tagen mit ihnen angestellt habe. Dabei gehe ich auch auf das Warum ein, während Fragen nach dem Wie vorwiegend in den Verweisen im Text beantwortet werden.

Der Artikel dient mir als Dokumentation und meinen Leser:innen zur Unterhaltung und zum Wissenstransfer.

Codeberg.org

Codeberg ist eine demokratische, gemeinschaftsgetriebene, gemeinnützige Softwareentwicklungsplattform, die von Codeberg e.V. betrieben wird und sich um Codeberg.org, eine auf Forgejo basierende Software, dreht. Der Sitz des Vereins ist in Berlin. Hier wird Codeberg.org auch gehosted.

Auf Codeberg könnt ihr eure eigenen Freie Software-Projekte entwickeln, zu anderen Projekten beitragen, inspirierende und nützliche Freie Software durchstöbern, euer Wissen teilen oder euren Projekten mit Codeberg Pages ein Zuhause im Web geben, um nur einige Beispiele zu nennen.

Die beiden vorstehenden Abschnitte wurden übersetzt mit DeepL.com (kostenlose Version) und anschließend leicht angepasst und mit Links angereichert.

Mit Codeberg.org werden keine kommerziellen Interessen verfolgt. Man ist hier (nur) Nutzer und/oder Unterstützer, jedoch nicht selbst ein Produkt. Mir gefällt die Mission des Projekts. Daher bin ich dazu übergegangen, einen Teil meiner Repositories hier zu verwalten. Zwar bin ich kein Mitglied des Vereins, unterstütze diesen jedoch durch gelegentliche Spenden.

Actions, Runner und Workflows

Plattformen wie Codeberg.org, GitHub und GitLab unterstützen Softwareentwicklungsprozesse durch CI/CD-Funktionalität.

Ein Forgejo-Runner ist ein Dienst, der Workflows von einer Forgejo-Instanz abruft, sie ausführt, mit den Protokollen zurücksendet und schließlich den Erfolg oder Misserfolg meldet.

Dabei ist ein Workflow in der Forgejo-Terminologie eine YAML-Datei im Verzeichnis .forgejo/workflows eines Repositories. Workflows umfassen einen oder mehrere Jobs, die wiederum aus einem oder mehreren Steps bestehen. Eine Action ist eine Funktion zur Erfüllung häufig benötigter Aufgaben, bspw. Quelltext auschecken, oder sich bei einer Container-Registry einloggen etc. Siehe für weitere Informationen Abschnitt Hierarchy ff. im Forgejo Actions user guide.

Motiviert, meinen eigenen Forgejo-Runner zu installieren, haben mich zwei Blog-Artikel von meinem Arbeitskollegen Jan Wildeboer:

Durch den Betrieb eigener Forgejo-Runner kann ich bereits vorhandene Rechenkapazität nutzen. Es fallen für mich und den Verein Codeberg e.V. dadurch keine zusätzlichen Kosten an. Für die Installation auf RHEL 9 bin ich dem Forgejo Runner installation guide gefolgt, da das in Jans Artikel erwähnte Repository ne0l/forgejo offensichtlich nicht mehr gepflegt wird und nur eine veraltete Version des Runner enthält.

Ein Dankeschön geht raus an Jan für unseren kurzen und produktiven Austausch dazu auf Mastodon.

Wozu das Ganze?

Ich beschäftige mich beruflich seit einiger Zeit mit dem RHEL image mode und möchte demnächst einen meiner KVM-Hypervisor damit betreiben. Bis es soweit ist, arbeite ich eine Weile im „Jugend forscht“-Modus und baue immer wieder neue Versionen meiner Container-Images. Der Ablauf ist dabei stets derselbe:

  1. Containerfile(5) erstellen bzw. anpassen
  2. Container-Image mit podman-build erstellen
  3. Das erstellte Image mit podman-push in eine Container-Registry hochladen
  4. Das Deployment auf diversen Zielsystemen testen

Dazu verwende ich das RHEL 9 Bootc Base Image aus der Registry registry.redhat.io.

The rhel-bootc and user-created containers based on rhel-bootc container image are subject to the Red Hat Enterprise Linux end user license agreement (EULA). You are not allowed to publicly redistribute these images.

Quelle: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/using_image_mode_for_rhel_to_build_deploy_and_manage_operating_systems/introducing-image-mode-for-rhel_using-image-mode-for-rhel-to-build-deploy-and-manage-operating-systems#introducing-image-mode-for-rhel_using-image-mode-for-rhel-to-build-deploy-and-manage-operating-systems

Um vorstehender Anforderung gerecht zu werden, speichere ich das erzeugte Container-Image in einem privaten Repository auf Quay.io. Sowohl für registry.redhat.io als auch für quay.io ist ein Login erforderlich, bevor es losgehen kann.

Für mich bot sich hier die Gelegenheit, die Nutzung von Forgejo Workflows zu lernen und damit den Ablauf zur Erstellung meines RHEL Bootc Images zu automatisieren.

Forgejo Workflow und Runner-Konfiguration

Im folgenden Codeblock findet ihr meinen Forgejo Workflow aus der Datei .forgejo/workflows/build_image.yaml, gefolgt von einer Beschreibung der einzelnen Schritte. Zur Erklärung der Begriffe name, on, env, jobs, steps, run, etc. siehe Workflow reference guide.

name: build_image

on:
  push:
    branches: main

env:
  REPO_URL: https://codeberg.org/Tronde/rhel-bootc.git
  REPO_NAME: rhel-bootc
  IMAGE_NAME: quay.io/rhn-support-jkastnin/rhel-bootc:9.5

jobs:
  build:
    runs-on: podman
    steps:
      - run: dnf -y install git
      - run: echo ${{ secrets.RH_REGISTRY_TOKEN }} | podman login -u ${{ secrets.RH_REGISTRY_USERNAME }} --password-stdin registry.redhat.io

      - run: echo ${{ secrets.QUAY_ROBOT_TOKEN }} | podman login -u ${{ secrets.QUAY_USERNAME }} --password-stdin quay.io

      - run: git clone ${{ env.REPO_URL }}
      - run: podman build -f /workspace/Tronde/rhel-bootc/rhel-bootc/Containerfile -t ${{ env.IMAGE_NAME }}
      - run: podman push ${{ env.IMAGE_NAME }}
  1. Der Workflow wird jedes Mal ausgeführt, wenn ich einen Commit in den Branch main pushe
  2. Ich definiere einige Umgebungsvariablen, um bei Änderungen nicht alle Schritte im Workflow einzeln auf notwendige Änderungen prüfen zu müssen
  3. Mit `runs-on: podman` bestimme ich, dass der Workflow auf einem Runner mit dem Label podman ausgeführt wird; der entsprechende Runner started dann einen rootless Podman-Container, in dem die folgenden Schritte innerhalb von rootful Podman ausgeführt werden (nested Podman bzw. Podman in Podman)
  4. Git wird installiert
  5. Anmeldung an registry.redhat.io erfolgt
  6. Anmeldung an quay.io erfolgt
  7. Das Git-Repository wird geklont, um es auf dem Runner verfügbar zu haben
  8. Der Runner baut ein Container-Image (Erinnerung an mich selbst: Ersetze den hardcodierten Pfad durch eine Variable)
  9. Das erstellte Image wird in die Registry gepusht

Damit mein Runner den obigen Workflow ausführen kann, existiert auf diesem die Konfigurationsdatei /etc/forgejo-runner/config.yml, welche ich mit dem Kommando forgejo-runner generate-config > config.yml erstellt und anschließend angepasst habe. Der folgende Codeblock zeigt nur die Abschnitte, die ich manuell angepasst habe.

…
  fetch_interval: 20s
…
  labels: [
    "rhel-9-ubi:docker://registry.access.redhat.com/ubi9/ubi",
    "podman:docker://registry.access.redhat.com/ubi9/podman",
    "ubuntu-latest:docker://ghcr.io/catthehacker/ubuntu:act-latest",
    "act-runner:docker://node:20-bullseye",
    "centos-stream-9:docker://quay.io/centos/centos:stream9"]
…
  privileged: true
…

Ich greife mal die Zeile podman:docker://registry.access.redhat.com/ubi9/podman heraus:

  • podman: am Beginn der Zeile beinhaltet das Label, welches im Worflow mit runs-on verwendet wird
  • Mit dem Rest der Zeile wird bestimmt, in welchem Container-Image der Workflow ausgeführt wird
  • Ich habe mich für ubi9/podman entschieden, weil
    • ich bei Red Hat arbeite und daher
    • mit den Prozessen zur Erstellung unserer Images vertraut bin,
    • wodurch sich ein gewisses Vertrauen gebildet hat.
    • Ich vertraue unseren Images mehr, als jenen, die irgendein Unbekannter gebaut hat und deren Inhalt ich nicht kenne (man kann den Inhalt aber selbstverständlich überprüfen)
    • und ich so prüfen konnte, ob sich ein Image mit „unseren“ Werkzeugen bauen läst (nicht, dass ich daran gezweifelt hätte).

Die Angabe von privileged: true ist erforderlich, wenn man innerhalb des Containers ebenfalls mit podman oder docker arbeiten möchte.

Entscheidungen

Meinem weiter oben abgebildeten Workflow ist zu entnehmen, dass ich auf die Verwendung von Forgejo Actions verzichtet habe. Das hat folgende Gründe:

  • Für die Verwendung ist node auf dem Runner erforderlich
  • node ist im Image ubi9/podman standardmäßig nicht installiert
  • Node.js ist für mich das Tor zur Hölle und ich vermeide dessen Nutzung wenn möglich
  • Die Nutzung ist keine Voraussetzung, da ich mein Ziel auch so ohne Mehraufwand erreicht habe

Sobald die Workflows länger und komplexer werden, mag sich meine Einstellung zu Actions ändern.

Zusammenfassung

Ich habe gelernt:

  • Forgejo Runner zu installieren und zu konfigurieren
  • Wie Forgejo Workflows funktionieren und auf Codeberg.org genutzt werden können
  • Wie ich mir damit zukünftig die Arbeit in anderen Projekten erleichtern kann
  • Was für großartige Open Source Projekte Codeberg.org und Forgejo sind
  •  
❌