ubuntuusers.de

Ich habe mal das Kapitel "Fingerprints" überarbeitet. Es war mir wichtig zu betonen, dass der Fingerprint eigentlich das primäre Sicherheitsmerkmal von SSH ist.

Ursprünglich ist z.B. "dann hat man halt Pech gehabt" bei einem falschen Fingerprint gestanden.

Aus diesem Grund habe ich etwas mehr Warnungen als Üblich eingefügt. Die Anwender müssen verstehen, dass es nicht einfach eine Frage ist, ob man eine Verbindung aufbauen möchte, sondern ob man auch wirklich weiß, dass es der richtige Server ist und im Prinzip damit die Verbindung sicher ist oder nicht. Die beste Verschlüsselung hilft nichts, wenn man sich mit dem falschen Server verbindet.

Ich habe auch mehrmals reingeschrieben, dass es die Aufgabe des Server Administrators ist, die Fingerprints über eine vertrauenswürdige Quelle zur Verfügung zu stellen. Ähnlich wie es Github macht. Ich habe auch Github als Beispiel angegeben, wie es richtig gemacht werden sollte.

Es gibt leider sehr viele Server Anbieter oder Webhoster, die keine Fingerprints für die Server bereitstellen. Am schlimmsten sind die Anleitungen diverser Anbieter, in denen steht, dass man die Fingerprint-Abfrage einfach akzeptieren soll.

Kann bitte jemand von euch mal drüberlesen, ob es auch für Anfänger verständlich geschrieben ist. Falls nicht kann ich gerne noch nachbessern.

Ziel ist es, dem Anwender nicht zu beschreiben, wie er schnell eine SSH Verbindung aufbauen kann, sondern wie eine sichere SSH-Verbindung konfiguriert werden muss. Das Problem ist leider, dass eine sichere Konfiguration doch um einiges an Mehrarbeit ist.

Als nächstes werde ich das Kapitel über Publickey Authentication angehen.

Ein Punkt, der mich auch sehr gestört hat ist folgender:

Login über mehrere Rechner

Ab und zu muss man sich von Rechner zu Rechner hangeln, da kein direkter Zugriff besteht. 
Doch der Key wird nicht automatisch übertragen. 
Darum besteht die Möglichkeit dies direkt in der ~/.ssh/config zu vermerken.

ForwardAgent yes

Wenn man diese Konfiguration wie beschrieben vornimmt, hat man ein großes Problem, weil dann an jeden Server der Agent durchgereicht wird. Agent Forwarding sollte eigentlich nicht bzw. nur in Ausnahmefällen verwendet werden.

Dieses Kapitel wird vermutlich auch umfangreicher ausfallen, weil eine sichere Konfiguration relativ komplex werden kann.

Es bringt meiner Meinung aber nichts, wenn die Konfiguration einfach ist, aber die Sicherheit darunter leidet.

Hallo,

wenn du komplette fertig bist, bitte kurz hier im Thread ein explizites "fertig" posten. Du kannst natürlich auch weiterhin posten, was du so änderst - musst du aber nicht.

Gruß, noisefloor

ruzima schrieb:

Kann bitte jemand von euch mal drüberlesen, ob es auch für Anfänger verständlich geschrieben ist. Falls nicht kann ich gerne noch nachbessern.

Danke zunächst ein mal, dass Du den Artikel überarbeitest! Ich bin jetzt kein reiner Anfänger aber ich habe es mal versucht durch die Anfängerbrille zu lesen:

Der einleitende Satz zu SSH Host Fingerprint könnte IMO noch etwas genauer erklären, was des SSH Host Fingerprint überhaupt ist, also unter anderem, dass er zu den jeweiligen Dateien auf dem Server unter /etc/ssh/ gehört und einen Rechner eindeutig identifizieren soll. Vielleicht auch noch, dass diese Keys bei der Installation von OpenSSH-Server automatisch generiert werden, man sie aber auch jederzeit selbst generieren lassen kann.

Der SSH Host Fingerprint

Falls der SSH Client die Möglichkeit bietet einen Fingerprint einzugeben, ist diese Methode immer zu bevorzugen. Man muss dann nur den Fingerprint von der Webseite kopieren und im Terminal einfügen.

Hier würde ich der Klarheit für Anfänger halber einfach bei Deinem github-Beispiel bleiben und besser z.B. so formulieren:

Am sichersten gelingt der Fingerprint-Abgleich, wenn man den vom Server-Betreiber zur Verifizierung zur Verfügung gestellten Fingerprint kopieren und in das Terminal-Fenster einfügen kann. Besteht die Möglichkeit des Kopierens nicht, sollte der Fingerprint - wenn er z.B. telefonisch übermittelt wird - manuell eingegeben werden, weil der SSH-Client unter Ubuntu dann die Verifizierung von angezeigtem und übermittelten, eingetippten Fingerpint abnimmt - also im obigen Beispiel github.com:

The authenticity of host 'github.com (140.82.121.3)' can't be established.
RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
Are you sure you want to continue connecting (yes/no/[fingerprint])? SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8
Warning: Permanently added 'github.com,140.82.121.3' (RSA) to the list of known hosts.

Hast Du auch vor etwas zu SSH-Zertifikaten zu schreiben?

Soweit erst mal. Das ist in der Tat ein komplexes Thema, was sich gar nicht so einfach gliedern lässt, sofern man den Leser auch nicht überfordern will.

LG, Newubunti

Danke fürs drüberlesen.

Ich werde das Kapitel mit den Fingerprints noch anpassen und deine Änderungsvorschläge einarbeiten.

Ich werde versuchen die Fingerprints zu vereinheitlichen bzw. Github als Beispiel heranziehen.

Publickey Authentication

Mit dem Kapitel über Publickey Authentifizierung werde ich noch länger brauchen, weil ich noch ein paar Punkte genauer erarbeiten muss.

• Konfiguration der SSH Agenten

• Konfiguration von SSH-Askpass

• Konfiguration von FIDO2 Token

Ich würde daher empfehlen, die bisherigen Änderungen zu veröffentlichen, sobald ich deine Vorschläge eingearbeitet habe.

Newubunti schrieb:

Hast Du auch vor etwas zu SSH-Zertifikaten zu schreiben?

SSH Zertifikat sind ein komplexes Thema. Ich glaube, dass es den Rahmen dieser Seite sprengen würde und viele Anfänger dadurch verwirrt. Wir können aber eine eigene Seite machen, in der es nur um SSH Zertifikate geht. Ein Freund von mir hat umlengst einen Artikel im Linux Magazin veröffentlicht wo die Grundlagen beschrieben sind: https://www.linux-magazin.de/ausgaben/2021/10/ssh-zertifikate/

ruzima schrieb:

Ich werde das Kapitel mit den Fingerprints noch anpassen und deine Änderungsvorschläge einarbeiten.

Ich würde mich grundsätzlich noisefloor anschließen und Dir empfehlen, den Artikel erst mal nach Deiner Auffassung komplett zu überarbeiten. IMO ist das einer der Artikel, bei dem ich mir gut vorstellen kann, dass man bei der Überarbeitung Inhalte auch mal von einem Abschnitt in einen anderen umplatziert. Deshalb macht es unter Umständen nur bedingt Sinn, wenn man sich Abschnitte "absegnen" lässt, die dann vielleicht zwei Abschnitte später doch noch mal angepasst werden müssen.

Aber davon abgesehen kannst Du Dich natürlich gerne immer melden, wenn Du mal aktuell ein Feedback brauchst.

Newubunti schrieb:

Hast Du auch vor etwas zu SSH-Zertifikaten zu schreiben?

SSH Zertifikat sind ein komplexes Thema. Ich glaube, dass es den Rahmen dieser Seite sprengen würde und viele Anfänger dadurch verwirrt.

Da gebe ich Dir recht. Ein eigener Artikel würde sicher Sinn ergeben, in diesem Artikel dann vielleicht aber trotzdem insoweit, dass der Leser überhaupt mal über die Möglichkeit dieser Option aufgeklärt wird. Details dann in einem eigenen Artikel oder eventuell auch erst mal einfach nur extern verlinkt.

An mir ist z.B. lange Zeit vorbeigegangen, dass es diese Möglichkeit überhaupt gibt, weil es eher selten bis gar nicht erwähnt wird. Darauf gestoßen bin ich durch Zufall beim Suchen zu Artikeln über aktuelle SSH-Cipher-Sicherheit.

Ich bin im übrigen der Meinung, dass das weniger eine Frage von "Anfänger/Profi", als vielmehr von "Anwendungsfall" ist. Komplexität ist dabei auch relativ zum Anwendungsfall.

Aber wie gesagt, ich gebe Dir Recht. Grundsätzlich wäre dieses Thema gut in einem eigenen Artikel besser aufgehoben. Dieser hier ist ohnehin schon lang genug. Und wenn es auf dieser Plattform keinen Artikel dazu gibt, auch ok - war nur eine Frage.

Danke!

LG, Newubunti

Hallo,

aktuell komme ich leider nicht dazu, dass ich an dem Artikel weiterschreibe.

Wollt ihr den Artikel vorerst wieder aus der Baustelle rausnehmen und den bisherigen Text übernehmen?

Ich habe bis Mitte November leider einiges in der Arbeit zu erledigen.

Mitte November habe ich einen Vortrag auf der Deepsec zum Thema SSH MitM Angriffe (https://deepsec.net/speaker.html#PSLOT525)

Diese Infos werde dann auch in den Artikel einbauen 😉

lg, Manfred

Hallo,

Wollt ihr den Artikel vorerst wieder aus der Baustelle rausnehmen und den bisherigen Text übernehmen?

Ist der Artikel denn im aktuellen Zustand in sich schlüssig, d.h. das keine Fragmente, nicht zu Ende gebrachte Abschnitte etc drin sind?

Gruß, noisefloor

noisefloor schrieb:

Ist der Artikel denn im aktuellen Zustand in sich schlüssig, d.h. das keine Fragmente, nicht zu Ende gebrachte Abschnitte etc drin sind?

Wenn ich was geändert habe, dann habe ich auch die Links innerhalb der Seite angepasst. Auch die Absätze sollten in sich abgeschlossen sein. Somit sollte es passen.

Ob noch Links von anderen Seiten auf einzelne Kapitel verweisen, habe ich jedoch nicht kontrolliert.

Sobald ich wieder mehr Zeit habe, werde ich mich melden um an dem Artikel weiterzuschreiben.

Hallo,

Ob noch Links von anderen Seiten auf einzelne Kapitel verweisen, habe ich jedoch nicht kontrolliert.

Das brauchst du auch nicht kontrollieren.

Wir schieben den Artikel dann in den kommenden Tagen zurück ins Wiki. Wenn du wieder Zeit hast einfach hier kurz posten.

Gruß, noisefloor

Hallo,

da ich nicht weiß, ob ich zum späteren Zeitpunkt zwecks Korrekturlesen zur Verfügung stehe, stelle ich hier mal zwei Punkte heraus, die mir aktuell im Bereich Authentifizierung über Public-Keys noch auffallen:

Wem die Authentifizierung über Passwörter trotz der Verschlüsselung zu unsicher ist, - immerhin könnte das Passwort ja erraten werden - der benutzt am besten das Public-Key-Verfahren.

Diese Aussage finde ich zu verkürzt. Ich fände es hier insgesamt besser, wenn man schlicht Vor- und Nachteile von Authentifizierungsverfahren klar darstellt.

Die Verwendung von Public-Keys ohne oder ohne ausreichend sichere Passphrase, kann z.B. je nach Einsatzgebiet weniger sicher sein, als wechselnde gut gehütet Passwörter, mit eventuell weiteren begleitenden Maßnahmen zur Erhöhung der Sicherheit.

Wenn man die Sicherheit des Schlüssels weiter erhöhen möchte, benutzt man anstatt des rsa-Verschlüsselungsverfahrens die Eliptische Kurve ED25519.

Der Schlüssel wird durch diesen Befehl erstellt:

ssh-keygen -t ed25519 

Nach meinem Kenntnisstand und den habe ich von https://goteleport.com/blog/comparing-ssh-keys/ bezogen, sind ED25519 nicht absolut gesehen sicherer als RAS-Keys - sie sind es aber gemessen an der Schlüssellänge (Bits). ED25519 braucht viel weniger Bits um auf die gleiche Sicherheit von RSA zu kommen. ED25519-Schlüssel sind damit wesentlich performanter als RSA Schlüssel sie sind aber nicht absolut sicherer.

Dabei sollte man - bei entsprechendem Sicherheitsbedarf berücksichtigen (man ssh-keygen, Abschnitt -b):

ECDSA-SK, Ed25519 and Ed25519-SK keys have a fixed length and the -b flag will be ignored.

Sollte es also auf Sicherheit des Keys ankommen, dann kann ich z.B. mittels

ssh-keygen -t rsa -b 81996

einen RSA-Key erzeugen, der absolut gesehen, sicherer ist als ein aktuell erstellbarer ED25519-Key, aber dafür ist dieser Key dann eben sehr lang mit entsprechenden Konsequenzen für die Performance.

Damit möchte ich NICHT den Eindruck erwecken, dass ED25519 aktuell nicht ausreichend sicherer wären. Das sind sie nach Aussage des oben verlinkten Dokuments im Moment auch.

Ich finde nur, dass man bei solchen Aussagen möglichst genau sein sollte.

Da ich auf dem Gebiet kein Experte bin, können meine Aussagen bezüglich RSA vs. ED25519 durchaus auch falsch sein - eventuell habe ich selbst etwas falsch verstanden.

Ich wollte aber auf den Umstand mal hinweisen.

LG, Newubunti

Grunsätzlich gelten RSA Schlüssel mit einer Länge von 2048 Bits als sicher. Alles was darunter ist, ist aber bereits als unsicher einzustufen. Der Standard bei OpenSSH ist 3072 Bits und sollte eigentlich ausreichen. Ich würde hier der Empfehlung von OpenSSH folgen.

Bei ECDSA Schlüssel kann man 256, 384 oder 521 Bits verwenden.

ECDSA-SK, Ed25519 und Ed25519-SK haben aber eine fix vorgegebene Bitlänge und die angegebene Anzahl an Bits wird für diese Schlüssel ignoriert.

Man sollte auch beachten, dass man regelmäßig seine Keys (Client & Server) wechseln sollte. Dadurch kann man, falls notwendig, relativ einfach auf neue Schlüssel mit mehr Bits wechseln.

Der Vorteil der elyptischen Kurven ist, dass die Schlüssellängen bei vergleichbarer Sicherheit wesentlich kürzer und daher effizienter sind.

Bei RSA Schlüssel kann es aber bald zu anderen Problemen kommen. OpenSSH hat mit der Version 8.8 die Unterstützung von RSA Schlüssel mit einer SHA-1 Signatur entfernt. Bisher war es nur als Veraltet eingestuft. Ich hatte schon ein paar Probleme mit einigen Bibliotheken und Clients.

Für einige kann es noch einen Unterschied machen, ob man ED25519 oder ECDSA verwendet, weil die ECDSA Schlüssel NIST Kurven verwenden, bei denen die NSA mitgarbeitet hat. ED25519 Schlüssel sind ähnlich zu ECDSA Schlüssel, nur dass diese auf Curve25519 basieren.

Hallo ruzima,

danke, für Deine Antwort! Hast Du oder natürlich auch jeder andere Leser eigentlich eine Quelle aus der man relativ aktuell etwas über die Einstufung bezüglich der Sicherheit von Keys erfahren kann?

Ich bin dieses Jahr über das Dokument aus dem vorigen Beitrag gestoßen und viele - sofern das Thema überhaupt behandelt wird - verlinken auch auf https://stribika.github.io/2015/01/04/secure-secure-shell.html.

Danke!

LG, Newubunti

Newubunti schrieb:

Hast Du oder natürlich auch jeder andere Leser eigentlich eine Quelle aus der man relativ aktuell etwas über die Einstufung bezüglich der Sicherheit von Keys erfahren kann?

Das BSI hat in Deutschland immer sehr gute Richtlinien, an die man sich halten kann. Die verlinkte Richtlinie ist von 2021 und somit aktuell.

https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.pdf?__blob=publicationFile

Gerade im deutschsprachigen Raum würde ich mich an die BSI Empfehlungen halten.

ruzima schrieb:

Gerade im deutschsprachigen Raum würde ich mich an die BSI Empfehlungen halten.

Dem stimme ich insofern zu, soweit man mit seiner Tätigkeit bzw. seiner Nutzung irgendwie unter die DSGVO fällt. Dann kann man sich nämlich im Zweifel auch darauf berufen.

Davon abgesehen halte ich es aber bei solchen Themen für optimal, wenn man verschiedene Quellen einer gewissen Reputationsstufe gegeneinander abwägen und daraus Schnittmengen bilden kann.

Bei einem Ministerium muss man grundsätzlich auch damit rechnen, dass Publikationen nicht frei von politischer Einflussnahme sind. Das muss nicht zwangsläufig so sein, ist aber durchaus möglich.

Natürlich muss bei jeder anderen Quellen auch berücksichtigt werden aus welcher Perspektive/Motivation heraus sie unter Umständen publiziert.

Deswegen eben auch der Abgleich verschiedener Quellen.

Aber danke, denn an das Naheliegende (BSI) hatte ich in dem Fall gar nicht gedacht.

LG, Newubunti

Dem stimme ich insofern zu, soweit man mit seiner Tätigkeit bzw. seiner Nutzung irgendwie unter die DSGVO fällt. Dann kann man sich nämlich im Zweifel auch darauf berufen.

Die Technische Richtlinie des BSI hat nicht direkt mit der DSGVO zu tun. Die DSGVO setzt aktuelle Sicherheitsmaßnahmen voraus und wie du bereits geschrieben hast, macht man mit den Empfehlungen des BSI wenig falsch.

Davon abgesehen halte ich es aber bei solchen Themen für optimal, wenn man verschiedene Quellen einer gewissen Reputationsstufe gegeneinander abwägen und daraus Schnittmengen bilden kann.

Es gibt noch das NIST: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57Pt3r1.pdf

In eine etwas andere Richtung geht FIPS. Bei FIPS würde ich aber aufpassen, weil es zu Problemen kommen kann. Einige SSH Clients und Bibliotheken haben Probleme, wenn bestimmte Ciphers nicht unterstützt werden. Solche Konfigurationen würde ich nur empfehlen, wenn man sie braucht und sich den Problemen bewusst ist die auftreten können. Eine aktuelle Quelle habe ich leider nicht, weil ich mit FIPS noch nicht viel zu tun hatte.