OpenSSH will die Unterstützung für DSA-Schlüssel entfernen und informiert über den Zeitplan und den einhergehenden Prozess dazu.

Die freie SSH-Implementierung OpenSSH ist in Version 9.4 erschienen. Die neue Ausgabe bringt Bugfixes und einige neue Features.

Darunter fällt das neue ssh_config “Tag” und ein entsprechendes “Match tag”-Prädikat. Das Config-Tag könne dazu verwendet werden, um Konfigurationsblöcke auszuwählen, was die Konfiguration erleichtern soll. Neu ist auch die Möglichkeit des Forwarding von Unix-Domain-Sockets.

Neben den Neuerungen werden auch eine Reihe von Fehlern ausgebügelt. Die neue Version entfernt die Unterstützung für ältere Versionen von libcrypto, teilen die Entwickler mit. Und OpenSSH benötigt nun LibreSSL ab Version 3.1.0 oder OpenSSL ab Version 1.1.1.

Der Beitrag OpenSSH 9.4 verbessert Konfiguration erschien zuerst auf Linux-Magazin.

Mit Version 9.3p2 der freien Verschlüsselungssuite OpenSSH schließen die Entwickler eine kritische Sicherheitslücke, die den Remote-Zugriff ermöglicht.

Angreifer könnten dann unter bestimmten Umständen Schadcode einschleusen, warnt das OpenSSH-Projekt. Auch das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat die Sicherheitslücke auf dem Radar und stuft sie als hochriskant ein. Ein entfernter, anonymer Angreifer kann eine Schwachstelle in OpenSSL ausnutzen, um einen Denial of Service Angriff durchzuführen, schreibt das BSI in seiner Warnmeldung.

Die Entwickler erläutern in der Ankündigung zur neuen Version von OpenSSH, die die Lücke schließt, dass bestimmte Voraussetzungen gegeben sein müssen, damit der Remote-Zugriff funktioniert. So sei die das Vorhandensein bestimmter Bibliotheken auf dem Opfersystem nötig und die Fernausnutzung erfordert auch, dass der Agent an ein vom Angreifer kontrolliertes System weitergeleitet wurde.

Der Beitrag OpenSSH 9.3p2 schließt hochriskante Lücke erschien zuerst auf Linux-Magazin.

Mit Version 9.3 der freien SSH-Suite OpenSSH beheben die Entwickler unter anderem Sicherheitsprobleme.

Die neue Version enthalte Korrekturen für ein Sicherheitsproblem und ein Speicher Sicherheitsproblem, teilen die Entwickler mit. Das Speichersicherheitsproblem sei wohl nicht ausnutzbar, heißt es in der Ankündigung, man melde aber die meisten netzwerkerreichbaren Speicherfehler als Sicherheitslücken.

Das Problem stecke im portablen OpenSSH, das eine Implementierung der “getrrsetbyname”-Funktion zur Verwendung durch die VerifyHostKeyDNS-Funktion biete, falls die Standardbibliothek sie nicht zur Verfügung. Eine speziell gestaltete DNS-Antwort könnte diese Funktion dazu veranlassen ein Out-of-Bounds-Read von benachbarten Stack-Daten durchzuführen. Mehr als ein Denial-of- Service beim SSH-Client sei damit wohl aber nicht zu erreichen.

Zu den neuen Funktionen zähle, dass “ssh-keygen” und “ssh-keyscan” akzeptieren nun die Option “-Ohashalg=sha1|sha256” bei der Ausgabe von SSHFP-Fingerprints, um so die Auswahl des Algorithmus zu ermöglichen.

Der Beitrag OpenSSH 9.3 schließt Sicherheitslücken erschien zuerst auf Linux-Magazin.

Mit der Veröffentlichung von OpenSSH 9.2 beseitigen die Entwickler der freien SSH-Implementierung unter anderem Fehler und schließen Sicherheitslücken.

Zu letzteren zählte ein Speicherfehler vor der Authentifizierung, der sich in OpenSSH 9.1 eingeschlichen hat. Die Entwickler glauben allerdings nicht, dass der Fehler für Angreifer ausnutzbar gewesen sei. Beseitigt wurde auch ein Problem, dass in OpenSSH-Versionen nach 8.7 die PermitRemoteOpen-Option ihr erstes Argument ignorierte, wenn es nicht eines der speziellen Schlüsselwörter “any” oder “none” war, was dazu führte, dass die Berechtigungsliste nicht geöffnet werden konnte, wenn nur eine Berechtigung angegeben war.

ZU den neuen Features zählt die Unterstützung für Channel-Inaktivitäts-Timeouts über eine neue sshd_config-ChannelTimeout-Direktive. Dadurch können Kanäle, die in einem konfigurierbaren Intervall keinen Verkehr gesehen haben, automatisch geschlossen werden.

Die Release Notes zählen alle Änderungen auf.

Der Beitrag OpenSSH 9.2 beseitigt Bugs erschien zuerst auf Linux-Magazin.

Mit der neuen Version 9.0 der freien Kryptographielösung OpenSSH schließen die Entwickler vornehmlich Lücken und beseitigen Probleme. Neu ist aber, dass OpenSSH gegen Angriffe gegen den Shor-Algorithmus abgesichert wurde.

Der Shor-Algorithmus ermöglicht es, Teile eine zusammengesetzte Zahl mittels Faktorierungsverfahren zu berechnen, sofern künftige Quantenrechner dazu fehlerfrei in der Lage sind.  Mit OpenSSH 9.0 begegnet man der Gefahr, dass sich die Verschlüsselung mit dem Algorithmus knacken lässt mittels einem gitterbasierten Kryptographieansatz namens NTRU. Letzterer wurde weiterentwickelt und kommt in OpenSSH als NTRU Prime zum Einsatz. Bei dieser Weiterentwicklung wurde das Augenmerk auf möglicherweise für künftige Attacken anfällige algebraische Strukturen gelegt.

OpenSSH verwende dann die Schlüsselaustauschmethode NTRU Prime + x25519. Es sei davon auszugehen, dass der NTRU-Algorithmus Angriffen standhält, die durch künftige Quantencomputer ermöglicht werden, heißt es in der Ankündigung. Mit dem X25519 ECDH-Schlüsselaustausch (der bisherigen Standardmethode) als Absicherung gegen etwaige Schwachstellen in NTRU Prime kombiniert, sei man für die Zukunft gewappnet. Diese Kombination gewährleiste, dass der hybride Austausch mindestens so sicher ist wie der Status quo, heißt es weiter.

Der Beitrag OpenSSH 9 baut Angriffen von Quantencomputern vor erschien zuerst auf Linux-Magazin.

Im Februar 2020 wurde schon angekündigt, dass OpenSSH die Unterstützung von ssh-rsa auslaufen lässt. Umgesetzt wurde dies in Version 8.8, die vor gut einem Monat veröffentlicht wurde.

Leider unterstützt nicht jedes System moderne HostKeyAlgorithms. Ein solches Beispiel konnte ich die Tage z. B. bei einem Switch beobachten konnte. Hier erscheint folgender Fehler:

Unable to negotiate with 192.168.1.1 port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss

In so einem Fall kann man ausnahmsweise doch noch ssh-rsa erlauben und das geht entweder per Option im ssh-Aufruf:

ssh -o HostKeyAlgorithms=+ssh-rsa 192.168.1.1

oder man trägt es in die ~/.ssh/config dauerhaft ein:

Host XYZ
    HostName 192.168.1.1
    HostkeyAlgorithms +ssh-rsa
    PubkeyAcceptedAlgorithms +ssh-rsa