Seite drucken

Diskussions- und Newsboard der Linux Interessen Gruppe Suletuxe

allgemeine Kategorie => Installation & Einrichtung => Thema von: Sebastian am 18. August 2022, 17:39:43

Titel: OpenSSH Inkompatibilität
Beitrag von: Sebastian am 18. August 2022, 17:39:43

Hallo liebe Suletuxe,

Ich bin immer noch dabei langsam mein EndevourOS einzurichten. Dabei bin ich auf ein Problem gestoßen das ich vorher unter Linux Mint noch nicht hatte. Ich konnte unter mein EndevourOS keine SSH Verbindung mit meinen RSA Key herstellen.

Code:

Permission denied (publickey)

Der selbe Key funktioniert aber unter Linux Mint. Also dachte ich mir dann muss es irgendwas mit meinen OpenSSH Client zutun haben, den ich unter EndevourOS verwende (Vielleicht zu neu? bzw. mein SSH Server auf dem RP4 zu alt). Also noch mal versucht eine Verbindung aufzubauen dieses mal mit

Code:

ssh -v

um die Debug Meldungen zu bekommen, um zu schauen wo es denn harkt. Nach dem Senden des Publickeys stand dann auch folgende Meldung:

Code:

debug1: send_pubkey_test: no mutual signature algorithm

Also findet Client und Server kein gemeinsamen Signatur Algorithmus. Jetzt wurde es zeit sich den Changelog (https://www.openssh.com/releasenotes.html) von OpenSSH anzuschauen ob sich bei da irgendetwas verändert hat. Da der Changelog gut in Kategorien eingeteilt ist, habe ich mit der Hervorhebung (strg+f) und dem Wort algorithm zwei Versionen zurück in der Kategorie Potentially-incompatible changes folgendes gefunden:

Zitat:

Potentially-incompatible changes
================================

This release disables RSA signatures using the SHA-1 hash algorithm
by default. This change has been made as the SHA-1 hash algorithm is
cryptographically broken, and it is possible to create chosen-prefix
hash collisions for <USD$50K [1]

For most users, this change should be invisible and there is
no need to replace ssh-rsa keys. OpenSSH has supported RFC8332
RSA/SHA-256/512 signatures since release 7.2 and existing ssh-rsa keys
will automatically use the stronger algorithm where possible.

Incompatibility is more likely when connecting to older SSH
implementations that have not been upgraded or have not closely tracked
improvements in the SSH protocol. For these cases, it may be necessary
to selectively re-enable RSA/SHA1 to allow connection and/or user
authentication via the HostkeyAlgorithms and PubkeyAcceptedAlgorithms
options. For example, the following stanza in ~/.ssh/config will enable
RSA/SHA1 for host and user authentication for a single destination host:

Host old-host
HostkeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa

We recommend enabling RSA/SHA1 only as a stopgap measure until legacy
implementations can be upgraded or reconfigured with another key type
(such as ECDSA or Ed25519).

[1] "SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 and
Application to the PGP Web of Trust" Leurent, G and Peyrin, T
(2020) https://eprint.iacr.org/2020/014.pdf

Ursache und temporäre Lösung gefunden. OpenSSH verwendet seid Version 8.8 den SHA-1 Hash Algorithmus nicht mehr für RSA.

also das ganze mit

Code:

ssh -o PubkeyAcceptedAlgorithms +ssh-rsa

ausprobiert und die Verbindung funktionierte wieder. Da SHA-1 aber auch wirklich kein sicherer Algorithmus ist, und ich dadurch nebenbei heraus gefunden habe, das mein SSH Server auf mein Pi (dropbear_2018.76) anscheint SHA-1 für RSA verwendet, dachte ich mir ok stell ich meinen Key auf einen ed25519 um (So ein Key ist mit der Sicherheit eines RSA 3072 Bit Keys vergleichbar nur viel kürzer) also schnell neuen Key erstellt:

Code:

ssh-keygen -t ed25519

Auf den RP4 übertragen und festgestellt das dieser nicht funktioniert. Dann den Changelog (https://matt.ucc.asn.au/dropbear/CHANGES) von Dropbear geprüft:

Zitat:

2022.82 - 1 April 2022

Features and Changes:
Note >> for compatibility/configuration changes

- Implemented OpenSSH format private key handling for dropbearconvert.
Keys can be read in OpenSSH format or the old PEM format.
>> Keys are now written in OpenSSH format rather than PEM.
ED25519 support is now correct. DSS keys are still PEM format.

Und festgestellt das ed25519 erst in der letzten Version korrekt funktioniert. Da mein Pi nur vom Heimnetz erreichbar ist, dachte ich mir dann ok dann bleibe ich beim RSA Key mit der "PubkeyAcceptedAlgorithms" Option bis dietpi bzw. debian da nachgezogen hat.

Moral von der Geschichte:

Wenn ihr auf einen älteren SSH Server euch mal einloggen müsst könnte es daran liegen ;D

Auserdem kann man durch Arch eine menge lernen da man sich mit den Problemen direkt an der Quelle befassen muss.

Ich weis nicht wie es euch dabei geht, aber grade diese kleinen Erfolgserlebnisse die dabei den eigenen Wissensschatz erweitern finde ich grade an Linux so toll.

Probleme sind dafür da sie zu Lösen und an ihnen zu wachsen. Dabei wird man mit jeder Recherche erfahrener. ;)

Titel: Re:OpenSSH Inkompatibilität
Beitrag von: Andreas am 19. August 2022, 08:28:56

Hallo Sebatian,

da ich auch einige Rootserver betreue liegt mir "Sicherheit" sehr am Herzen. Das betrifft sowohl ssh als SSL für meine Webserver. Leider hinken Debian-basierten Distros in diesen Dingen der technisch möglichen Realität weit hinterher - oft um Jahre. Das ist für mein Sicherheitsbewusstsein nicht akzeptabel. Auch das ist einer der vielen Gründe warum ich eben auf Arch setze und nicht mehr auf Debian. So werden von meinen Webservern (auf einem von denen läuft auch "suletuxe.de") nur Cipher verwendet die den höchsten Sicherheitsstandard haben, auch wird die Reihenfolge der verwendeten Cipher nicht vom verwendeten Browser festgelegt (der ist oft auch veraltet) sondern serverseitig. Ich habe lediglich zwei Cipher mit einer "Medium-Sicherheitsstufe" (ganz hinten in meiner Liste) weil einige ältere Apple und Windowsphone-Geräte (die aber noch recht verbreitet sind) diese schwächeren Cipher verwenden und mit stärkeren nicht umgehen können. Warum nicht? Weil Apple und Microsoft diesen Geräten keine Sicherheitsupdates mehr spendieren - hier soll neu gekauft werden :o...

LG
Andreas