Tag Archives: Fedora33

Fedora: Ubuntu knockt Fedora aus dem Secure-Boot

Posted on by

Die Schlagzeile hat was, oder?  😀

Fedora: Ubuntu knockt Fedora aus dem Secure-Boot

Der Releasetermin für Fedora 33 wackelt, da kurzfristig einer neuer Blocker dazu bekommen ist. Ubuntu hat offensichtlich etwas voreilig eine aktuelle Revocationliste für Bootloader ins EFI-Bios verteilt und damit Fedora 33 Beta unbrauchbar gemacht. Um dem Bug zu begegnen, muß man natürlich erst einmal Ubuntu installiert oder laufen gehabt haben und dann Fedora booten wollen.

5. shim https://bugzilla.redhat.com/show_bug.cgi?id=1883609 NEW
Secure Boot fails to boot F33 Beta image

It appears that Ubuntu has pushed a Secure Boot revocation list early, so people who have previously installed Ubtunu will not be able to boot Fedora. This is accepted as a FESCo blocker.

Nachlesen kann man das auf Bugzilla.

Nicht ganz unüblich dürfte das bei Menschen sein, die sich gerade durch diverse Livedisks durchtesten, auf der Suche nach Ihrem zukünftigen Lieblingsbetriebssystems.

Da es auch mein Problem mit dem Bootvorgang auf dem Tablet betrifft, habe ich da natürlich Hoffnungen. Was mir gerade so einfällt: Wo ist eigentlich der Sinn von Secure-Boot, wenn man das im Bios einfach abschalten kann?

In anderen Fedora News

DoT oder DNS-over-TLS kommt wohl doch erst mit Fedora 34. Nicht aufgegriffen wurden auch die anhaltenden pcscd & RDP Probleme mit Gnome, oder der Umstand, daß man mit Fedora keine Screencasts in Videokonferenzen machen kann 🙁  Kommt alles ein bisschen spät für die Deadline, schon klar, war aber mit Sicherheit schon so, als F33 intern das erste mal durchkompilierte.

Von der Geary Front, vorgestellt im letzten BS-LUG Meeting, gibt es auch eine neue Entwicklung: Ein bereits vor Monaten eingereichter Bugreport über einen Formatierungsfehler bei in Antworten erzeugten Daten wie „ER/SIE schrieb am …. um .. das folgende…“ sind allesamt falsch lokalisiert. Als Zeitzone kommt UTC+0 und als Format „english“ zum Einsatz, was bei einer rein Deutschen Konversation per Email mit dem Satz endete: „Das hast Du doch nie vor 2 Stunden geschrieben!“ 🙂 Da ist jetzt neue Bewegung rein gekommen, da der Hauptmaintainer langsam versteht, daß es sich nicht um ein Übersetzungsproblem handelt, sondern um ein Lokalisierungsproblem. Solche Jobs übernehmen Betriebssystembibliotheken normalerweise für einen, aber man muß die natürlich richtig füttern 😉

 

Tablet: Fedora 33 Beta auf Surface Pro 4

Posted on by

Wieso würde ich Euch eine Nachricht antun, daß Fedora 33 Beta Linux auf meinem Tablet läuft? 🙂

Tablet: Fedora 33 Beta auf Surface Pro 4

Also ein Grund ist, das es Gnome 3.38 hat:

der andere Grund ist, daß es bis vor 10 Minuten nicht ging 😉

Im LiveImage von Fedora 33 kommen neue Grub Bootloader zum Einsatz und die starten nicht auf dem normalen Surface Pro 4, weil das wohl ein Firmware Update braucht, was es natürlich als reines Linux System nicht bekommen wird.

Ihr entsinnt Euch vielleicht an diesen Artikel: Fedora Guide – Falls der Grub2 Fix bei Euch versagt

Grub 2 hatte da einen bedauerliches Problem. Das wirkt sich nun scheinbar auf das Liveimage aus.

Beheben lies sich das durch ein Transplant der Grubbootloader in der Boot-Partition von F31 auf F33. Fedora ist dran, wird da aber ein kleines Problem haben, weil das Firmwareupdate von Microsoft kommen müßte.

GGf. können die Jungs vom Surface Kernel Projekt helfen, aber das wird sich erst in den nächsten Tagen entscheiden, denn noch wissen die nichts von Ihrem Glück.

PS: ich staune. Mein nur zu 77% gefüllter Akku soll angeblich noch 6 Stunden bei 4 Kernen und aktivem Turbo halten. Wie lange wäre das denn, wenn der voll wäre??? und schon sprang er auf 5h 45m. Verdacht: Es lügt mich in freundlicher Absicht an 😀

Hmm.. „Suspend“ funktioniert, der wacht sogar sofort wieder auf, wenn man auf den Power-Knopf drückt. Leider killt er dabei den Wifichip 🙁

UPDATE:

Stellt sich gerade raus, es ist wohl ein Timing Problem, denn 1 von ca. 10 Boots klappt und je schneller man bootet, nachdem der USB Stick eingesteckt ist, desto wahrscheinlicher der Start. Ich hoffe wir finden das raus. Der Grubsfiles sind da wohl nicht von Bedeutung.

OpenSSH: neuere ssh Versionen verweigern Verbindung

Posted on by

In der Fedora Welt kommt seit Wechsel auf Fedora 33 zu einem Problem mit OpenSSH-Servern, wenn die noch alte Hostskeys verwenden oder man selbst zum Authentifizieren einen Key benutzen möchte, der noch SHA1 als Hashalgorithmus benutzt.

OpenSSH: neuere ssh Versionen verweigern Verbindung

Das sollte eigentlich nicht passieren, daß man mit einem Clienten nicht mehr in seinen Server kommt, aber zur Zeit häufen sich die Meldungen, daß man mit dem OpenSSH Shellclienten von Fedora 33 nicht mehr auf Server einloggen kann, wenn entweder der Server einen alten SHA1 Keys verwendet, oder der Client einen Authkey benutzt der noch SHA1 ist.

Die temporäre Abhilfe ist, dem Clienten mitzuteilen, daß er gefälligst den alten SHA1 weiter benutzen soll. Dazu ruft man ssh mit dem Argument „-oPubkeyAcceptedKeyTypes=+ssh-rsa“ auf:

ssh -oPubkeyAcceptedKeyTypes=+ssh-rsa root@servername

Auf lange Sicht muß man natürlich einen neuen Schlüssel auf den Servern und für seinen Zugang ausrollen. Dazu muß man wissen, ob man davon überhaupt betroffen ist und da sagt einem der SSH-Keygenerator:

ssh-keygen -l -f .ssh/Krypto.id_rsa
4096 SHA256:ehMkPi1CRDPCoOYMxdTI8BB2+TkCa13CyMQXX5EXesg id@braunschweig.de (RSA)

Zuerst die Schlüssellänge 4096 Bits, dann der gesuchte Hashalgorithmus „SHA256“ und am Ende der Type „RSA“.  Wenn Ihr betroffen seid, weil Eurer Key unter 2048 und/oder SHA1 ist, dann braucht Ihr einen neuen Key:

ssh-keygen -b 4096 -t rsa-sha2-512 -N „PASSWORD“ -f „FILENAME“ -C „Kommentar“

wobei -N -f und -C alle optional sind, aber falls Ihr größere Mengen an Schlüsseln erzeugen müßte, ist das ganz hilfreich 🙂

Am Ende stellt sich nun aber heraus, daß es gar kein Fedora33 „Feature“ war, daß zu dem Problem geführt hat, sondern ein OpenSSH Bug. Hier der Patch, falls Ihr das adaptieren müßt:

— sshconnect2.c.orig 2020-09-26 07:26:37.618010545 -0700
+++ sshconnect2.c 2020-09-26 07:25:35.665009029 -0700
@@ -1281,10 +1284,9 @@
*/
if (ssh == NULL || ssh->kex->server_sig_algs == NULL ||
(key->type != KEY_RSA && key->type != KEY_RSA_CERT) ||
– (key->type == KEY_RSA_CERT && (datafellows & SSH_BUG_SIGTYPE))) {
– /* Filter base key signature alg against our configuration */
– return match_list(sshkey_ssh_name(key),
– options.pubkey_key_types, NULL);
+ ((key->type == KEY_RSA || key->type == KEY_RSA_CERT)
+ && (datafellows & SSH_BUG_SIGTYPE))) {
+ return xstrdup(sshkey_ssh_name(key));
}

/*

Der Patch ist nicht von mir, sondern von Gordon Messmer und wurde erst vor einigen Stunden bei OpenSSH eingereicht. Mal sehen was daraus wird 😉