Wie gestern schon berichtet, ist die openssh Version 7.2p2-6 für Fedora defekt,

Wer keinen Zugang zu seiner Monitor Konsole hat und trotzdem das Downgrade einspielen muß, kann nun auf diesen Weg zurückgreifen:

Workaround V2.0: Downgrade auf 7.2p2-3

Über den Kojilink lädt man die drei Pakete runter:

Koji :  http://koji.fedoraproject.org/koji/buildinfo?buildID=756836

dann loggt man sich via defektem SSHD ein und  downgraded die Files für einen oneshot CronJob:

echo „59 16 * * * root /usr/bin/rpm -U –force /tmp/openssh*rpm > /tmp/log; rm -f /etc/cron.d/onetime“ > /etc/cron.d/onetime

Die Uhrzeit muß man natürlich an seine aktuelle Zeit anpassen 😉

Dann Ausloggen und nach der Zeit wieder einloggen. Der Befehl „rpm -qa | grep openssh“ sollte dann 7.2p2-3 anzeigen, welches die letzte funktionierende Version war.  Danach in /etc/dnf/dnf.conf einfügen:

exclude=openssh*

erst dann zieht das nächste Update nicht wieder die defekte Version auf den Server.

Das ganze klappt, weil der crond als „echter“ Root außerhalb der SSH Session läuft und nicht über sshd angetriggert wird.

Erste Hinweise zu den Ursachen des Problems

Wie im Bugtracker von RedHat einsehbar ist, kristallisieren sich grade Probleme mit der Chroot-Funktion vom SSHD heraus. Ist die Chroot aktiviert, was man tun sollte um Benutzer den Zugang zum System zu verweigern, so daß diese keine lokalen Angriffe fahren können, sondern in einer eigenen Umgebung arbeiten können. werden die für Root nötigen Capabilities nicht mehr gesetzt.

Capabilities sind die Eigenschaften eines Users, die erweiterte Rechte im Linuxsystem beinhalten, wie z.b. das Recht sich mit PTRACE in Prozessen einzuklinken, um diese zu belauschen oder zu verändern. Diese Capabilities machen Root erst aus und fehlen in der aktuellen sshd version:

# capsh --print
Current: =
Bounding set =
Securebits: 00/0x0/1'b0
 secure-noroot: no (unlocked)
 secure-no-suid-fixup: no (unlocked)
 secure-keep-caps: no (unlocked)
uid=0(root)
gid=0(root)
groups=

Meine Vermutung: Da hat wer zuviel weggepatcht 😉