Seiten: [1] 
|
 |
|
|
Autor
|
Thema: OpenSSH Inkompatibilität (Gelesen 1101 mal)
|
|
Sebastian
Sr. Member
 Online
Einträge: 487
|
 |
OpenSSH Inkompatibilität
« 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.
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
um die Debug Meldungen zu bekommen, um zu schauen wo es denn harkt. Nach dem Senden des Publickeys stand dann auch folgende Meldung:
debug1: send_pubkey_test: no mutual signature algorithm
|
|
Also findet Client und Server kein gemeinsamen Signatur Algorithmus. Jetzt wurde es zeit sich den Changelog 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:
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
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:
Auf den RP4 übertragen und festgestellt das dieser nicht funktioniert. Dann den Changelog von Dropbear geprüft:
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 
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. 
|
| « Letzte Änderung: 18. August 2022, 17:55:42 von Sebastian » |
 Gespeichert
|
Richtig um Hilfe bitten
|
|
|
Andreas
Administrator
 Offline
Einträge: 1319
Linux von Innen
|
|
Re:OpenSSH Inkompatibilität
« Antwort #1 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  ...
LG
Andreas
|
|
Gespeichert
|
Wissen ist das einzige Gut, das mehr wird, wenn man es teilt - wenn es Menschen gibt, die es teilen, und es Menschen gibt, die bereit sind, dieses Geschenk auch mit eigenem Einsatz anzunehmen.
Freiheit zu erkämpfen reicht nicht. Man muss sie auch verteidigen.
Ohne IT-Kompetenz ist man heutzutage ein willkommenes Opfer und Spielball anderer, egal, welches System oder Gerät man nutzt. Nur Wissen schützt vor Schaden!
|
|
|
Seiten: [1] 
|
|
|
|
|
|
|
