Ubuntu 24.04 auf 26.04 per VPS aktualisieren

Wann können Sie Ubuntu 24.04 auf 26.04 aktualisieren?

Sie können Ubuntu 24.04 auf einem VPS jetzt auf 26.04 aktualisieren. Seit dem 29. September 2026, als Canonical Upgrades von 24.04 LTS freigeschaltet hat, bietet do-release-upgrade auf einem 24.04-Server 26.04.1 an. Ubuntu 26.04 LTS (Resolute Raccoon) wurde am 23. April 2026 veröffentlicht. Canonical öffnet den Upgrade-Pfad von LTS zu LTS jedoch erst, sobald das erste Point Release verfügbar ist. Dieses Release enthält die Installations- und Upgrade-Fehler, die in den ersten Monaten gefunden wurden. Dieses Mal verging mehr Zeit als bis zum Point Release selbst: 26.04.1 wurde am 27. August 2026 veröffentlicht. Canonical hielt das Upgrade anschließend noch einige Wochen zurück, um geplante Backports bereitzustellen, die Regressionen in einer aktuellen Version von rust-coreutils beheben. Falls Ihnen die neue Nummerierung nicht vertraut ist: 26.04.1 ist kein anderes Ubuntu, sondern dasselbe 26.04 mit vier Monaten an Korrekturen, die in die Installationsmedien integriert wurden. Genau deshalb ist es die erste Version, die Canonical für einen bestehenden Server anbietet.

Bis zum 29. September lieferte die Prüfung auf einem 24.04-System Folgendes:

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

Das war kein Fehler auf dem Server. Wenn Sie diese Meldung heute noch sehen, prüfen Sie die Einstellung, von der sie abhängt. /etc/update-manager/release-upgrades enthält unter Ubuntu Server Prompt=lts. Daher bietet das Tool nur das nächste Long Term Support-Release an, und auch erst, sobald Canonical den Upgrade-Pfad dafür geöffnet hat. Lassen Sie die Einstellung trotzdem auf lts. Auf einem späteren Release würde normal damit auch die kurzlebigen Interim-Releases anbieten. Während der Wartezeit bot Canonical do-release-upgrade -d für alle an, die nicht warten wollten. Jetzt, da der Pfad geöffnet ist, verwenden Sie für Server den einfachen Befehl aus der Ankündigung. Lesen Sie was sich mit 26.04.1 geändert hat und wann der Upgrade-Pfad geöffnet wurde, bevor Sie beginnen. Ein Server mit 22.04 kann diesen Sprung nicht direkt durchführen. Der Upgrader bietet immer nur das nächste LTS-Release an. Deshalb behandelt das Upgrade von 22.04 auf 26.04 über 24.04 den ersten Schritt und den Snapshot, den Sie vor dem zweiten Schritt erstellen sollten.

Jeden folgenden Befehl führen Sie selbst auf Ihrem eigenen Server in der angegebenen Reihenfolge aus. Ein Release-Upgrade kann auf dem System, das Sie aktualisieren, nicht testweise durchgeführt werden. Es ersetzt den Kernel und die C-Bibliothek und benötigt zum Abschluss einen Reboot.

Sollten Sie überhaupt aktualisieren?

Ubuntu 24.04 erhält bis 2029 reguläre Sicherheitsupdates. Für einen funktionierenden Produktionsserver besteht daher kein Zeitdruck. Aktualisieren Sie, wenn Sie etwas benötigen, das 26.04 mitbringt: PHP 8.5, PostgreSQL 18, MySQL 8.4 LTS, OpenSSH 10.2 oder den 7.0-Kernel. „Die Nummer ist höher“ ist kein Grund, eine Maschine anzufassen, die Kunden bedient.

Führen Sie kein In-Place-Upgrade durch, wenn eine der folgenden Bedingungen zutrifft:

• Sie haben noch nie die Konsole Ihres Providers (VNC oder seriell) geöffnet und sich darüber angemeldet. Diese Konsole ist der einzige Rückweg auf den Server, wenn SSH ausfällt. Wenn Sie erst während der Aussperrung feststellen, dass sie nicht funktioniert, ist es zu spät.
• Sie können sich keine Stunde Ausfallzeit leisten und haben keinen Rollback.
• Ihr Stack hängt von einem Drittanbieter-Repository ab, das noch keine Pakete für resolute veröffentlicht hat.
• Der Server wurde vor mehr als zwei Jahren manuell eingerichtet, und niemand weiß, was darauf installiert ist.

Die Alternative ist oft besser: Erstellen Sie eine neue 26.04-VPS, installieren Sie Ihren Stack, stellen Sie die Daten wieder her und ändern Sie anschließend den DNS-Eintrag, sobald der neue Server korrekt antwortet. Der alte Server bleibt in Betrieb, bis sich der neue bewährt hat. Für ein Rollback müssen Sie dann lediglich den DNS-Eintrag ändern, statt eine Wiederherstellung durchzuführen. Wenn Sie diesen Weg wählen, beginnen Sie mit den ersten zehn Minuten auf einer neuen VPS und richten Sie den neuen Server ordnungsgemäß ein.

Schritt 1: Erstellen Sie ein Backup, aus dem Sie wiederherstellen können

Verwenden Sie zwei Ebenen, weil sie auf unterschiedliche Weise ausfallen. Ein Snapshot des Providers umfasst die gesamte Festplatte und lässt sich innerhalb weniger Minuten wiederherstellen. Er wird jedoch erstellt, während Ihre Datenbanken Schreibvorgänge ausführen. Daher ist er konsistent zum Zeitpunkt eines Absturzes, aber nicht anwendungskonsistent. Mit einem dateibasierten Backup mittels restic, das außerhalb des Servers gespeichert wird erhalten Sie einzelne Dateien und eine Kopie, die auch dann verfügbar bleibt, wenn Ihr Konto gesperrt wird.

Erstellen Sie zuerst manuell Dumps der Datenbanken. Ein Dump ist eine Möglichkeit, eine laufende Datenbank zu sichern.

sudo -u postgres pg_dumpall | sudo tee /var/backups/pg-all.sql > /dev/null
sudo mysqldump --all-databases --single-transaction --routines | sudo tee /var/backups/mysql-all.sql > /dev/null
sudo tar czf /var/backups/etc-before-upgrade.tgz -C / etc
sudo chmod 600 /var/backups/pg-all.sql /var/backups/mysql-all.sql

--single-transaction erstellt nur für InnoDB-Tabellen einen konsistenten Dump. Für einen konsistenten Dump von MyISAM-Tabellen sind Sperren erforderlich. Das /etc-Tarball ist das Archiv, zu dem Sie in der Praxis greifen werden, weil es jede Konfigurationsdatei enthält, zu der das Upgrade Sie gleich Fragen stellen wird.

Ein Backup, aus dem Sie noch nie eine Wiederherstellung durchgeführt haben, ist nur eine Vermutung. Stellen Sie jetzt eine einzelne Datei daraus wieder her, bevor Sie sie unter Zeitdruck benötigen.

Schritt 2: 24.04 zuerst vollständig aktualisieren

do-release-upgrade wird auf einem System mit einem beschädigten Paketstatus nicht ausgeführt. Ein nur teilweise aktualisiertes 24.04 erschwert die Analyse aller späteren Fehler.

sudo apt update
sudo apt full-upgrade
sudo apt --purge autoremove
sudo dpkg --audit
apt-mark showhold

dpkg --audit ohne Ausgabe bedeutet, dass kein Paket nur teilweise konfiguriert ist. apt-mark showhold ohne Ausgabe bedeutet, dass kein Paket mit einem dpkg hold versehen ist. APT-Prioritäts-Pins werden dadurch nicht angezeigt. Sie sind ein separates Verfahren und können ebenfalls verhindern, dass ein Paket aktualisiert wird. Schritt 3 prüft diese Pins. Geben Sie alle von showhold aufgelisteten Pakete mit sudo apt-mark unhold und dem Paketnamen frei. Alternativ können Sie davon ausgehen, dass der hold einen Grund hat, und hier abbrechen.

Starten Sie den Server neu, wenn sich der Kernel geändert hat. Dadurch führen Sie das Upgrade auf einem System aus, das tatsächlich den Code verwendet, von dem es ausgeht, dass es ihn verwendet.

[ -f /var/run/reboot-required ] && sudo reboot

Prüfen Sie anschließend den verfügbaren Speicherplatz. Das Upgrade-Programm lädt den vollständigen Satz der neuen Pakete herunter, bevor es irgendetwas installiert. Bei zu wenig Speicherplatz bricht es mit einer Meldung ab, die das betroffene Dateisystem nennt.

df -h / /boot

Alte Kernel sind meistens die Ursache. sudo apt --purge autoremove entfernt sie.

Beenden Sie vor dem Start noch einen weiteren Dienst: Wenn automatische Sicherheitsupdates während des Vorgangs starten, halten sie die dpkg-Sperre. Das Release-Upgrade bricht dann mit Could not get lock /var/lib/dpkg/lock-frontend ab. Führen Sie zuerst sudo systemctl stop unattended-upgrades aus und starten Sie den Dienst wieder, wenn Sie fertig sind.

Schritt 3: Drittanbieter-Repositorys und festgelegte Pakete prüfen

Standardmäßig kommentiert do-release-upgrade jede APT-Paketquelle aus, die nicht von Ubuntu stammt, weil ein für noble erstelltes Paket ein resolute-System beschädigen kann. Die Option --allow-third-party lässt diese Quellen stattdessen aktiviert und geht damit genau dieses Risiko ein. Prüfen Sie, welche Pakete und Quellen Sie verwenden, bevor das Tool diese Entscheidung für Sie trifft.

ls /etc/apt/sources.list.d/
grep -rhE '^(deb |Types:|URIs:|Suites:)' /etc/apt/sources.list.d/
ubuntu-security-status --thirdparty
ls /etc/apt/preferences.d/

Ubuntu 24.04 verwendet in diesem Verzeichnis zwei Formate: die alten einzeiligen .list-Dateien und deb822-.sources-Dateien mit Types:- und Suites:-Feldern. Ein Standard-Upgrade deaktiviert beide Formate. ubuntu-security-status --thirdparty listet die installierten Pakete auf, für die kein Ubuntu-Archiv eine Version bereitstellt. Das ist die genaue Anzahl der Pakete, die Sie zusätzlich installiert haben. Eine Datei in /etc/apt/preferences.d/ wird nur dann als Pin eingelesen, wenn ihr Name keine Erweiterung hat oder mit .pref endet und ausschließlich Buchstaben, Ziffern, Bindestriche, Unterstriche und Punkte enthält. Jede andere Datei ignoriert APT normalerweise mit einem Hinweis. Ein Pin, der noble angibt, kann ein Paket nach dem Upgrade auf einer alten Version halten. Das hängt davon ab, welche Versionen noch verfügbar sind und welche Priorität der Pin festlegt. Lesen Sie daher jede Datei und entscheiden Sie, ob sie noch benötigt wird.

Prüfen Sie für jedes Drittanbieter-Repository vor Beginn, ob der Anbieter eine Version für den neuen Codenamen veröffentlicht hat. Die Docker-Suites sind unter https://download.docker.com/linux/ubuntu/dists/ aufgeführt. Andere Anbieter stellen dasselbe Verzeichnis bereit. Eine Paketquelle, die auf eine nicht vorhandene Suite verweist, führt beim ersten apt update nach dem Upgrade zu dieser Ausgabe:

E: The repository 'https://download.docker.com/linux/ubuntu resolute Release' does not have a Release file.

Docker veröffentlicht jetzt eine resolute-Suite. Lassen Sie jede Paketquelle deaktiviert, deren Suite fehlt, bis der Anbieter sie veröffentlicht. Wenn Sie den Codenamen auf eine Suite ändern, für die der Anbieter tatsächlich Pakete erstellt hat, installieren Sie Pakete, die gegen die falschen Systembibliotheken gelinkt sind.

Schritt 4: Führen Sie das Upgrade in tmux aus, nicht in einer einfachen SSH-Shell

Der Server-Upgrader läuft normalerweise in GNU screen und unterstützt die erneute Verbindung nach einem Verbindungsabbruch. Ein Verlust der SSH-Verbindung beendet das Upgrade daher nicht automatisch. Führen Sie es zusätzlich in einer eigenen tmux-Sitzung aus. So haben Sie eine Sitzung mit Namen, zu der Sie erneut eine Verbindung herstellen können.

sudo apt install -y tmux
tmux new -s upgrade

In dieser Sitzung:

sudo ufw allow 1022/tcp
sudo do-release-upgrade

Der Upgrader startet einen zweiten SSH-Daemon auf Port 1022, bevor er Änderungen vornimmt, und weist darauf hin:

To make recovery in case of failure easier, an additional sshd will be started on port '1022'. If anything goes wrong with the running ssh you can still connect to the additional one.

Er öffnet diesen Port nicht in Ihrer Firewall. Eine Firewall ohne Rückfrage zu öffnen, wäre eine unerwartete und problematische Änderung. Öffnen Sie Port 1022 selbst, bevor Sie beginnen, und schließen Sie ihn nach Abschluss von sudo ufw delete allow 1022/tcp wieder. Beachten Sie, dass Ihr Provider möglicherweise eine zweite Firewall in seinem Control Panel außerhalb des Servers betreibt.

Wenn die Verbindung trotzdem abbricht, melden Sie sich erneut an und führen Sie tmux attach -t upgrade aus. Das Upgrade lief während Ihrer Abwesenheit weiter. Falls dies nicht der Fall war und Sie zu einem teilweise konfigurierten dpkg oder zu APT-Quellen zurückkehren, die teilweise zu noble und teilweise zu resolute gehören, beschreibt die Wiederherstellung nach einem fehlgeschlagenen Release-Upgrade, wie Sie den Paketstatus reparieren und erkennen, wann Sie die Reparatur beenden und stattdessen den Snapshot wiederherstellen sollten.

Schritt 5: Beantworten Sie die Eingabeaufforderungen für Konfigurationsdateien bewusst

dpkg fragt nur nach Dateien, die Sie oder ein Skript geändert haben. Jede Eingabeaufforderung betrifft daher eine Datei, die Sie oder ein Skript geändert haben. Durch Drücken der Eingabetaste behalten Sie standardmäßig die aktuelle Version.

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** sshd_config (Y/I/N/O/D/Z) [default=N] ?

Drücken Sie jedes Mal zuerst D. Lesen Sie die Änderungen und entscheiden Sie dann, ob Sie Ihre Version mit N behalten oder die Version des Paketbetreuers installieren. Die Voreinstellung ist bereits N. Das Behalten der alten Datei ist jedoch nicht für jedes Paket sicher, weil bestimmte Konfigurationsänderungen für den Betrieb des aktualisierten Systems erforderlich sind.

Wenn Sie Ihre Datei behalten, hat das Folgen: Sie erhalten die neuen Standardwerte nicht. Führen Sie den Abgleich später durch, sobald der Server wieder läuft und Sie nicht unter Zeitdruck stehen.

sudo find /etc -name '*.dpkg-dist' -o -name '*.dpkg-new'

Jede in der Liste aufgeführte Datei ist die Version des Paketbetreuers, die neben Ihrer Version gespeichert wird. Vergleichen Sie die Dateien einzeln und übernehmen Sie die wichtigen Einstellungen. Bei zwei Dateien ist besondere Sorgfalt erforderlich: /etc/ssh/sshd_config, weil die falsche Antwort Ihre Sitzung beendet, und Ihre Webserver-Konfiguration, weil die falsche Antwort die Websites außer Betrieb setzt.

Seit Ubuntu 24.04 startet needrestart betroffene Dienste standardmäßig automatisch neu. Wenn Sie den interaktiven Modus wiederhergestellt haben, akzeptieren Sie die vollständige Liste. Ein Daemon, der weiterhin eine alte gemeinsam genutzte Bibliothek verwendet, bleibt anfällig für Fehler, die durch das Update behoben wurden, bis er neu gestartet wird.

Schritt 6: Neustart durchführen und anschließend den Rechner prüfen

sudo reboot

Nach dem Neustart:

lsb_release -a
uname -r
systemctl --failed
journalctl -p err -b --no-pager | head -50
sudo apt update && sudo apt full-upgrade
sudo apt --purge autoremove

lsb_release -a sollte Release: 26.04 und Codename: resolute melden. uname -r sollte einen 7.0-Kernel anzeigen. systemctl --failed sollte null Units auflisten. Jede Unit, die dort angezeigt wird, ist Ihre nächste Aufgabe. apt update aktualisiert abschließend die Paketindizes. apt full-upgrade installiert danach alle Updates, die veröffentlicht wurden, seit das Upgrade seine Pakete abgerufen hat.

PostgreSQL 16 auf 18: Der Cluster bleibt unbemerkt zurück

Ubuntu 24.04 liefert PostgreSQL 16 aus, Ubuntu 26.04 PostgreSQL 18. Das Upgrade installiert 18 neben 16 und verschiebt Ihre Daten nicht. Die Debian-postgresql-common-Schicht erstellt bei der Installation des Serverpakets nur dann einen Main-Cluster, wenn noch keine Cluster vorhanden sind. Ein vorhandener PostgreSQL-16-Cluster erhält daher nicht automatisch einen leeren 18-Cluster auf Port 5433. Ihre Anwendung kommuniziert weiterhin mit 5432, und zunächst sieht alles korrekt aus. Deshalb wird das Problem oft erst Monate später entdeckt.

pg_lsclusters

Ein Eintrag für Version 16 bedeutet, dass dieser Cluster weiterhin Version 16 verwendet. Wenn pg_lsclusters außerdem einen 18 main-Cluster auflistet, vergewissern Sie sich vor dem Entfernen mit sudo pg_dropcluster --stop 18 main, dass dieser leer ist. pg_upgradecluster schreibt nicht in einen Ziel-Cluster, der bereits vorhanden ist. Führen Sie die Migration durch, wenn Sie die Anwendung anhalten können:

sudo pg_upgradecluster 16 main
pg_lsclusters
sudo -u postgres vacuumdb --all --analyze-only

Bei der Standardmethode wird der Cluster mit Version 16 exportiert und in 18 wiederhergestellt. Dafür benötigen Sie ungefähr so viel freien Speicherplatz wie die Datenbank groß ist. -m upgrade verwendet stattdessen pg_upgrade und ist bei großen Datenbanken deutlich schneller. Lesen Sie nach Abschluss die Spalte Port: Der neue Cluster übernimmt 5432, und der alte Cluster bleibt angehalten. Der Upgrade-Hook des Pakets führt automatisch einen Analyze-Durchlauf aus. Der obige Befehl wiederholt ihn ausdrücklich.

Testen Sie die Anwendung einige Tage lang mit dem neuen Cluster. Entfernen Sie erst danach den alten Cluster:

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

Das Datenverzeichnis des alten Clusters ist Ihre schnellste Möglichkeit für ein Rollback. Löschen Sie es am Tag des Upgrades nicht.

MySQL 8.0 auf 8.4: Die entfernte Option, die den Server am Start hindert

26.04 aktualisiert MySQL von 8.0 auf 8.4 LTS. Dabei führen zwei Änderungen bei Servern zu Problemen.

Erstens startet mysqld nicht, wenn die Konfiguration eine Option enthält, die in der neuen Version entfernt wurde. default_authentication_plugin ist häufig betroffen, weil zahlreiche ältere Anleitungen empfehlen, diese Option zu setzen. Der Dienst schlägt fehl, und journalctl -u mysql -n 50 nennt die unbekannte Variable direkt. Löschen Sie diese Zeile aus der Datei unter /etc/mysql/mysql.conf.d/ und führen Sie anschließend sudo systemctl start mysql aus.

Zweitens ist das Plugin mysql_native_password in 8.4 standardmäßig nicht mehr aktiviert. Ein Konto, das dieses Plugin weiterhin verwendet, kann sich daher überhaupt nicht mehr anmelden. Prüfen Sie dies, solange Sie noch 8.0 verwenden:

sudo mysql -e "SELECT user, host, plugin FROM mysql.user;"

Übertragen Sie vor dem Upgrade jedes Konto, bei dem mysql_native_password angezeigt wird. Aktualisieren Sie anschließend das Passwort in der Anwendungskonfiguration:

ALTER USER 'appuser'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'a new password';

Wenn eine Clientbibliothek zu alt ist, um caching_sha2_password zu verwenden, können Sie das alte Plugin in 8.4 wieder aktivieren. Fügen Sie dazu mysql_native_password=ON unter [mysqld] hinzu. Verwenden Sie dies nur als Übergangslösung mit einem festgelegten Enddatum, da MySQL das Plugin in 9.0 entfernt hat.

PHP 8.3 auf 8.5: Ihre Vhosts verweisen auf einen nicht mehr vorhandenen Socket

24.04 liefert PHP 8.3, 26.04 PHP 8.5. Die Pakete werden in versionsbezogene Pfade installiert. Ihre Webserver-Konfiguration wird dabei nicht angepasst. Ein nginx-Vhost mit fastcgi_pass unix:/run/php/php8.3-fpm.sock; verweist nun auf einen Socket, den kein Prozess erstellt. Jede PHP-Anfrage liefert daher 502, und das nginx-Fehlerprotokoll enthält:

connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory)

Verweisen Sie auf den neuen Socket. Testen Sie die Konfiguration und laden Sie sie neu:

sudo sed -i 's/php8.3-fpm.sock/php8.5-fpm.sock/' /etc/nginx/sites-available/example.com
sudo nginx -t
sudo systemctl reload nginx

Bei Apache mit mod_php äußert sich das Problem anders. Apache startet überhaupt nicht. sudo apache2ctl -t meldet, dass libphp8.3.so nicht geladen werden kann, weil die Datei nicht vorhanden ist. Das aktivierte Modul ist ein Symlink auf ein nicht mehr vorhandenes Paket.

sudo a2dismod php8.3
sudo a2enmod php8.5
sudo systemctl restart apache2

Wenn Sie den Server nach einem LAMP-Stack auf Ubuntu 24.04 eingerichtet haben, sollten Sie beide Pfade prüfen. Die Anleitung hinterlässt einen versionsbezogenen Modulnamen und einen versionsbezogenen Socket.

Auch Ihre php.ini-Einstellungen werden nicht übernommen. memory_limit, upload_max_filesize und alle weiteren Einstellungen befinden sich in /etc/php/8.3/. Der neue Verzeichnisbaum verwendet die Standardwerte. Vergleichen Sie die beiden Dateien und übertragen Sie die Werte manuell. Wenn Sie die alte Datei vollständig über die neue kopieren, übernehmen Sie die PHP-8.3-Standardwerte in die PHP-8.5-Installation. Führen Sie anschließend php -m aus und vergleichen Sie die Ausgabe. Eine Erweiterung, die als php8.3-redis installiert ist, benötigt ihr php8.5--Paket. Wenn sie aus einem PPA stammt, hat das Upgrade diese Paketquelle deaktiviert. Die Erweiterung fehlt dann einfach.

Zertifikate sollten Sie separat prüfen. Führen Sie nach dem Upgrade sudo certbot renew --dry-run --run-deploy-hooks aus. Der Befehl testet den gesamten Erneuerungsablauf einschließlich des Hooks zum Neuladen des Webservers, ohne das aktive Zertifikat zu verändern. Ein Hook, der einen Dienstnamen oder ein geändertes Binary aufruft, schlägt dabei sichtbar fehl und nicht erst still beim nächsten Erneuerungsversuch. Certbot mit Let's Encrypt auf nginx zeigt, wie diese Hooks aussehen sollten.

SSH: der Fehler, der die aktuelle Sitzung beendet

Die Eingabeaufforderung sshd_config ist der Punkt, an dem sich Benutzer aussperren. Mit der Antwort Y wird die Datei des Paketbetreuers installiert. Dadurch werden PermitRootLogin, PasswordAuthentication, AllowUsers, Port und alle anderen von Ihnen hinzugefügten Zeilen verworfen. Wenn Ihre Firewall nur einen benutzerdefinierten Port zulässt und die mitgelieferte Konfiguration auf 22 lauscht, wird die nächste Verbindung abgewiesen. Die Sitzung, in der Sie gerade arbeiten, ist dann Ihre letzte.

Verhindern Sie das vor dem Upgrade. /etc/ssh/sshd_config beginnt unter 24.04 mit Include /etc/ssh/sshd_config.d/*.conf. Bei den meisten Einstellungen verwendet OpenSSH den ersten gelesenen Wert. Daher setzt sich ein am Anfang eingebundenes Drop-in gegenüber derselben Einstellung weiter unten durch. Einige Schlüsselwörter sind Ausnahmen: Port und ListenAddress akzeptieren mehrere Werte. Eine Port-Zeile in einem Drop-in fügt daher einen Port hinzu, statt einen weiter unten festgelegten Port zu ersetzen. Verschieben Sie Ihre Einstellungen in eine Datei, die dpkg nicht besitzt:

sudo tee /etc/ssh/sshd_config.d/99-local.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
AllowUsers deploy
EOF
sudo chmod 644 /etc/ssh/sshd_config.d/99-local.conf
sudo sshd -t && sudo systemctl restart ssh

Sobald sich in /etc/ssh/sshd_config keine Ihrer Einstellungen mehr befindet, ist diese Eingabeaufforderung nicht mehr relevant. Unabhängig von der Antwort bleiben Ihre Einstellungen erhalten, weil sie in einer anderen Datei liegen.

Ein benutzerdefinierter Port erfordert eine zusätzliche Prüfung, weil er möglicherweise nicht dort festgelegt ist, wo Sie ihn vermuten:

systemctl is-enabled ssh.socket

Wenn dort enabled ausgegeben wird, öffnet systemd den Listening-Port, nicht sshd. Ubuntu verwendet seit 22.10 die Socket-Aktivierung für sshd. Unter 24.04 liest ein systemd-Generator die Einstellungen Port und ListenAddress aus der sshd-Konfiguration und übernimmt sie als Listening-Adressen des Sockets. Das geschieht jedoch nur, wenn systemd seine Units neu lädt. Deshalb scheint eine Bearbeitung von Port 2222 wirkungslos zu bleiben: Sie wird erst nach sudo systemctl daemon-reload && sudo systemctl restart ssh.socket wirksam. Die mitgelieferte sshd_config enthält inzwischen einen entsprechenden Hinweis. Wenn Sie den Port stattdessen direkt für die Socket-Unit festlegen möchten, verwenden Sie sudo systemctl edit ssh.socket:

[Socket]
ListenStream=
ListenStream=2222

Der leere ListenStream= ist erforderlich. Er löscht den geerbten Wert. Ohne ihn lauscht der Socket zusätzlich zu 2222 auch auf 22. Wenden Sie die Änderung mit sudo systemctl daemon-reload && sudo systemctl restart ssh.socket an.

Nach dem Upgrade und bevor Sie die aktuelle Sitzung schließen:

sudo sshd -t
sudo systemctl status ssh.socket --no-pager
sudo ss -lntp | grep -E ':(22|2222)'

Öffnen Sie anschließend auf Ihrem eigenen Rechner ein zweites Terminal und melden Sie sich erneut an. Eine funktionierende Shell in diesem zweiten Terminal ist der einzige verlässliche Nachweis. Lassen Sie die erste Sitzung geöffnet, bis die zweite funktioniert. SSH auf einem VPS härten beschreibt die Einstellungen, die Sie in diesem Drop-in beibehalten sollten.

Wenn es bereits zu spät ist, bietet die Webkonsole Ihres Providers eine Anmeldung, die SSH nicht verwendet. Melden Sie sich dort an, korrigieren Sie die Konfiguration, führen Sie sudo sshd -t aus und starten Sie den Dienst neu. Genau deshalb sollten Sie den Zugriff auf die Konsole vor einem Upgrade testen und nicht erst während des Upgrades.

FAQ

Warum meldet do-release-upgrade unter Ubuntu 24.04 „No new release found“?

Seit dem 29. September 2026 sollte das nicht mehr passieren, da Canonical an diesem Tag Upgrades von 24.04 LTS auf 26.04.1 aktiviert hat. Davor war diese Meldung zu erwarten: Ubuntu 26.04 LTS wurde am 23. April 2026 veröffentlicht, 26.04.1 folgte am 27. August, und der Upgrade-Pfad blieb noch einige Wochen geschlossen, während Canonical Korrekturen für Regressionen in rust-coreutils zurückportierte. Wenn die Meldung weiterhin erscheint, prüfen Sie, ob /etc/update-manager/release-upgrades den Wert Prompt=lts enthält. Das ist der Ubuntu-Server-Standard und bietet nur das nächste Long-Term-Support-Release an. Belassen Sie diese Einstellung bei lts.

Muss ich den Server neu starten, um das Upgrade abzuschließen?

Ja. Das Upgrade installiert einen neuen Kernel, eine neue C-Bibliothek und ein neues Init-System. Das laufende System verwendet die alten Komponenten weiter, bis es neu gestartet wird. do-release-upgrade fordert am Ende zu einem Neustart auf. Ein Rechner, der bis „später“ weiterläuft, verwendet währenddessen eine Mischung aus zwei Releases. Prüfen Sie nach dem Neustart uname -r auf den neuen Kernel und systemctl --failed auf Dienste, die den Neustart nicht überstanden haben.

Sollte ich ein Upgrade im laufenden Betrieb durchführen oder einen neuen 26.04-Server erstellen?

Erstellen Sie nach Möglichkeit einen neuen Server. Auf einem neuen VPS können Sie den Stack installieren, die Daten wiederherstellen und alles testen, während der alte Server weiterhin Datenverkehr verarbeitet. Ein Rollback besteht dann aus einer DNS-Änderung und nicht aus einer Wiederherstellung aus dem Backup. Führen Sie das Upgrade im laufenden Betrieb durch, wenn der Server schwer verschiebbaren Zustand enthält, der Anbieter pro Maschine abrechnet oder wenn Sie über einen Snapshot und nachweislich funktionierenden Konsolenzugriff verfügen. Der direkte Upgrade-Pfad ist etabliert, aber während der Ausführung für etwa eine Stunde unumkehrbar.

Was passiert, wenn meine SSH-Verbindung während des Upgrades abbricht?

Das Server-Upgrade verwendet normalerweise GNU screen. Eine abgebrochene SSH-Verbindung beendet das Upgrade daher nicht automatisch. Wenn Sie es innerhalb der oben genannten tmux-Sitzung gestartet haben, verbinden Sie sich erneut und führen Sie tmux attach -t upgrade aus, um es fortzusetzen. Der Upgrader startet außerdem einen zusätzlichen SSH-Daemon auf Port 1022. Er öffnet diesen Port jedoch nicht in der Firewall. Erlauben Sie Port 1022 daher zunächst selbst und schließen Sie ihn anschließend wieder.

Meine PHP-Website liefert nach dem Upgrade 502. Was ist fehlgeschlagen?

Der Pfad zum PHP-FPM-Socket hat sich mit der Version geändert. Ubuntu 24.04 verwendet PHP 8.3, während 26.04 PHP 8.5 verwendet. Daher existiert /run/php/php8.3-fpm.sock nicht mehr, während Ihr nginx-vhost weiterhin darauf verweist. Das nginx-Fehlerprotokoll zeigt connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory). Aktualisieren Sie fastcgi_pass auf den Socket für 8.5, führen Sie sudo nginx -t aus und laden Sie nginx anschließend neu. Bei Apache mit mod_php besteht die entsprechende Korrektur aus sudo a2dismod php8.3, gefolgt von sudo a2enmod php8.5 und einem Neustart.