Hallo,
der Artikel ist wieder im Wiki, Danke für die Überarbeitung.
Wenn du wieder Zeit hast und noch größeren Änderungen machen möchtest → einfach hier nochmal posten.
Gruß, noisefloor
Anmeldungsdatum: Beiträge: 29567 |
Hallo, der Artikel ist wieder im Wiki, Danke für die Überarbeitung. Wenn du wieder Zeit hast und noch größeren Änderungen machen möchtest → einfach hier nochmal posten. Gruß, noisefloor |
||||||||||||
Anmeldungsdatum: Beiträge: 19 |
Danke. Ich habe mich in jetzt mit Agent forwarding beschäftigt. Es gibt ein paar Anwendungsfälle, bei denen es notwendig ist von einem Server auf einen anderen zuzugreifen. z.B. Zugriff auf ein Git Repo vom Entwicklungsserver aus. Es wird oft diskutiert, ob es besser ist einen passwortgeschützten Schlüssel auf dem Server zu speichern oder einen Agent durchzureichen. Vor ein paar Wochen habe ich eine Frage auf Stackexchange gestellt. Nach einigen Überlegungen und Tests, habe ich dann eine Lösung gefunden. Zusammenfassung:
Ich weiß, dass es eine eigene Seite für PuTTY gibt, aber aus meiner Sicht sollte man nicht zwischen OpenSSH und PuTTY unterscheiden. Der Grund ist, dass sowohl OpenSSH als auch PuTTY unterschiedliche Funktionen besitzen, die für ein sicheres Agent Forwording notwendig sind. PuTTY alleine kann niemals Agent Forwarding sicher betreiben und die Anleitung für OpenSSH>8.2 ist einfach zu kompliziert, als dass diese sinnvoll everwendet werden kann. PuTTY hat einen Schutz gegen Spoofing Angriffe und der OpenSSH Agent unterstützt SSH-Askpass/FIDO2. Die Entwickler von OpenSSH haben leider keinen Spoofing Schutz in den Client eingebaut: https://github.com/openssh/openssh-portable/pull/258 Aktuell bin ich soweit, dass ich Agent Forwarding gegenüber passwortgeschützten Schlüsseln auf dem Server empfehle. Dies gilt aber nur, wenn SSH-Askpass oder ein FIDO2 Token verwendet wird. Dadurch muss die Verwendung auf Client Seite bestättigt werden. Bei einem privaten Schlüssel auf Server kann das Passwort mitgelesen werden, falls der Server kompromittiert ist. Bei einem Agent, wenn alles richtig konfiguriert ist, verliert man aber nicht die Kontrolle über die privaten Schlüssel. Das ist der Grund, warum PuTTY als Client und der OpenSSH Agent verwendet werden müssen. |
||||||||||||
Anmeldungsdatum: Beiträge: 5142 |
Hallo ruzima, ohne in dem Thema "Agent forwarding" tiefer drin zu stecken: Wenn ich Dich richtig verstehe, dann siehst Du "Agent forwarding" nur in folgender Konstellation sicher betreibbar:
Wenn dem so wäre, dann würde es IMO Sinn ergeben, dass Theme "SSH Agent forwarding" in einem eigenen Artikel auszulagern, der dann die Möglichkeit böte auf dies Kombination näher einzugehen. PuTTY generell innerhalb des Artikel SSH abzuhandeln hielte ich - solange es nur um das Agent forwarding geht - dagegen für ungünstig, weil dann IMO die Gefahr bestünde, dass nicht so versierte Leser, die Aussage man könne agent forwarding nur in der Kombination Server OpenSSH, Client PuTTY sicher betreiben, fälschlicherweise generalisieren und dann auf die Idee kommen könnten SSH insgesamt liese sich nur in dieser Kombination sicher betreiben. LG, Newubunti |
||||||||||||
Anmeldungsdatum: Beiträge: 19 |
Als Client muss PuTTY verwendet werden. Pageant (SSH Agent von PuTTY) kann leider nicht mit SSH-Askpass/FIDO2 Token umgehen. Aus diesem Grund muss man auf den SSH Agent von OpenSSH ausweichen. Somit gilt folgende Konstellation:
Der Server spielt in diesem Fall keine Rolle. Die meisten SSH Clients sind gegenüber Spoofing Angriffen anfällig. Aus diesem Grund habe ich zusammen mit Simon Tatham (PuTTY Entwickler) und Matt Johnston (Dropbear) Patches für diverse SSH Clients geschrieben. PuTTY hatte bereits seit längerm eine Spoofing Erkennung mit den Trust Sigils implementiert. Der Patch wurde aber trotzdem übernommen, weil die Idee war, dass SSH Clients ein ähnliches Verhalten aufweisen sollten. Bei der Entwicklung der Patches wurde auch davon ausgegangen, dass der OpenSSH Agent unter Linux verwendet wird und nicht Pageant. Patches für SSH Clients:
Die Entwickler von OpenSSH haben den Patch leider nicht übernommen, weil aus ihrer Sicht ein Spoofing Angriff keine Sicherheitslücke im SSH Client darstellt. Bei Dropbear wurde der Patch übernommen, es wurde aber noch kein neues Release erstellt. Dropbear ist in diesem Fall aber auch weniger relevant, weil der Client keine wirkliche Alternative zu PuTTY und dem OpenSSH Client ist. Es fehlen einfach zu viele Funktionen. |
||||||||||||
Anmeldungsdatum: Beiträge: 29567 |
Hallo,
+1
+1 Zumal aufgeteilte Artikel (=ein Artikel pro Thema) wesentlich besser wartbar = zukunftssicherer sind. Gruß, noisefloor |
||||||||||||
Supporter, Wikiteam
Anmeldungsdatum: Beiträge: 9384 Wohnort: Münster |
SSH Agent Forwarding ist eine unsichere Technik und Handlung, da man die Verantwortung für sichere Benutzung seiner IT an einen Fremden delegiert. Sie wird auch in der Dokumentation von OpenSSH (das bei Ubuntu standardmäßig installierte SSH) kritisch gesehen und von ihrer Verwendung wird abgeraten. Man kann auch auf sie verzichten, denn OpenSSH kennt bessere, d.h. hier sicherere Konzepte wie Es spricht nichts dagegen, SSH Agent Forwarding in einem eigenen Artikel zu behandeln. Im Artikel zu SSH (der sich hauptsächlich mit OpenSSH beschäftigt) hat diese sehr spezielle Aufgabenstellung nichts verloren. Auch alternative SSH-Clients wie beispielsweise PuTTY sind besser in eigenen Artikeln aufgehoben. So können auch die sicherheitstechnischen Unterschiede sauber diskutiert werden. Es mag durchaus funktionale Gründe geben, verschiedene Implementationen zu mischen. Wer so etwas tun will, sollte aber die sicherheitstechnischen Aspekte im Blick behalten. |
||||||||||||
Anmeldungsdatum: Beiträge: 19 |
Sofern die Verwendung von ProxyCommand und ProxyJump möglich ist, bin ich dafür dass man diese verwendet. Leider gibt es auch Situationen, in denen es nicht möglich ist ProxyJump zu verwenden. Ein Beispiel z.B. ist das Arbeiten auf einem fremden Server. Wenn man dort auf ein Git Repository über SSH zugreifen möchte, dann braucht man einen privaten SSH Schlüssel. Wenn man Agent Forwarding vermeiden möchte, dann besteht nur die Möglichkeit einen passwortgeschützten privaten Schlüssel auf dem Server zu speichern. Geht man davon aus, dass der Server kompromittiert ist und der Angreifer bereits "root" Rechte erlangt hat, wie dies beim Matrix Hack 2019 der Fall war, muss man davon ausgehen, dass er auch das Passwort für den privaten Schlüssel mitlesen kann. In so einem Fall ist der private Schlüssel vollständig kompromittiert. Es gibt somit keinen Unterschied zwischen ungeschütztem Agent Forwarding und privaten Schlüsseln auf dem Server.
+1 Finde ich gut, weil das Thema Agent Forwarding sehr umfangreich werden kann. Die letzten 10-15 Jahre war die allgemeine Meinung, dass Agent Forwarding böse ist und wenn man dann mit so einem Vorschlag kommt und auch noch schreibt, dass es sicher ist, kann das sehr schnell nach hinten losgehen, wenn man es nicht begründen kann. Deshalb frage ich auch nach, ob es für euch in Ordnung ist, wenn ich sowas schreibe.
Aus meiner Sicht ist es keine ideologische Entscheidung wie z.B. ob ich Chrome oder Firefox als Browser bevorzuge, sondern eine Funktionale ob man Agent Forwarding benötigt oder nicht. Wie bereits beschrieben, kann es Gründe geben, warum man Agent Forwarding braucht und derzeit hat man nur bei der Kombination PuTTY + OpenSSH-Agent einen entsprechenden Schutz vor Spoofing Angriffen. Es geht hier nicht um einen theoretischen Angriff. Mein Tool SSH-MITM ist in der Lage solche Angriffe durchzuführen! Diese Funktion habe ich damals eingebaut, um den SSH Entwicklern zu demonstrieren, dass diese Angriffe sehr wohl möglich sind und die meisten haben dann auch Änderungen an den Clients vorgenommen. |
||||||||||||
Anmeldungsdatum: Beiträge: 19 |
Ein paar Infos über den erwähnten Angriff: https://blog.deepsec.net/deepsec-2021-talk-ssh-spoofing-attack-on-fido2-devices-in-combination-with-agent-forwarding-manfred-kaiser/ Wie ich bereits geschrieben habe, hat man nun die Wahl zwischen einem Schlüssel am Server und einem durchgereichten Agent. Den Vortrag habe ich nächste Woche 😀 DeepSec 2021 Talk: SSH spoofing attack on FIDO2 Devices in Combination with Agent Forwarding Since OpenSSH 8.2 there is the possibility to secure a private key with a with a FIDO2 token (Nitrokey, Yubikey, …). A key protected by FIDO2 must be manually confirmed each time the key is used and prevents misuse of the key if an SSH agent is compromised. Although it is known that agent forwarding is a security risk and should not be used, support has been extended with OpenSSH 8.5 (Released: 3.3.2021). Prior to OpenSSH 8.5, it was not possible to forward an SSH agent during file transfers (SCP/SFTP) to another server. This was one of the reasons why AUT-milCERT (BMLV) took a closer look at the SSH protocol. The goal was to find out whether a FIDO2 protected key can provide sufficient protection against misuse in case of a leaked agent. During the analysis of the protocol, several vulnerabilities were found in the RFCs that could allow an attacker to perform targeted Man-in-the-Middle and spoofing attacks. |
||||||||||||
Supporter, Wikiteam
Anmeldungsdatum: Beiträge: 9384 Wohnort: Münster |
Ja, das ist eine missliche Situation, für deren Behandlung es zwei funktionale Lösungen gibt:
Es gibt eine dritte Möglichkeit: Man vermeidet die Situation. Das erfordert:
Das ist natürlich weniger bequem, aber sicher durchzuführen ohne dass man Agent Forwarding benötigt oder seine privaten Schlüssel aus der Hand geben muss. Leider ist Bequemlichkeit ein Feind der Sicherheit; verantwortungsbewusste Profis verzichten im Konfliktfall auf die Bequemlichkeit.
Es ist nach aktuellem Stand der Technik immer noch böse. Ob Deine Bemühungen daran etwas ändern werden, kann man hoffen, aber es wird sich erst in der Zukunft erweisen. Und mit dieser Vorsicht sollte man Agent Forwarding in der Praxis – und auch im Wiki – behandeln. |
||||||||||||
Anmeldungsdatum: Beiträge: 19 |
Es ist leider gelebte Praxis, dass Agent Forwarding oder gespeicherte Schlüssel auf dem Server verwendet werden ☹ Erst recht schlimm wird es, wenn sogar Seiten wie Github sowas "empfehlen": https://docs.github.com/en/developers/overview/using-ssh-agent-forwarding Ich habe es auch schon versucht lokal zu entwickeln und dann das irgendwie auf den Server zu bekommen - praktikabel ist was anderes...
Ich gehe nicht davon aus, dass sich sofort was ändert. Die Version 0.76 von PuTTY ist in den meisten Ubuntu Distris noch nicht enthalten und solange es keine kritischen Sicherheitslücken gibt, wird auch nicht aktualisiert. Die meisten werden PuTTY nicht selber kompillieren sondern das mitgelieferte Package verwenden. Somit wird es sicher noch ein paar Jahre dauern. Bis dahin wird es eventuell aber auch andere Lösungen geben. Die OpenSSH Entwickler verfolgen einen anderen Ansatz: https://github.com/djmdjm/openssh-wip/pull/5 Dabei geht es darum Berechtigungen auf Schlüssel zu definieren. Man kann dann beim Agent angeben, für welche Server ein bestimmter Schlüssel verwendet werden kann. Sofern die Funktion halbwegs einfach zu verwenden ist, könnte es eine sehr gute Lösung sein. Das größte Problem bei dem Ansatz der OpenSSH Entwickler ist aber, dass Änderungen am "publickey Protokoll" notwendig sind. Auch ist fraglich, wie andere Clients mit den Änderungen zurechtkommen. Auch wenn die OpenSSH Entwickler die Änderungen mit der nächsten Version umsetzen würden, würde es vermutlich noch sehr lange dauern, bis alle SSH Clients damit kompatibel sind und auch von den verschiedenen Distris angeboten werden. |
||||||||||||
Anmeldungsdatum: Beiträge: 5142 |
Stimmt im Prinzip, wobei ich jetzt nicht zu beurteilen vermag, ob die von ruzima dargestellte Kombination PuTTY Client - OpenSSH Agent nun einer sicherheitstechnischen Überprüfung Stand hält. Man muss aber auch eingestehen, dass im Wiki momentan steht:
ForwardAgent yes Dagegen wäre die Darstellung von ruzima bei der ich nicht den Eindruck habe, dass sie leichtfertig dahin formuliert ist, IMO durchaus vertretbar, zumal man ja die Möglichkeit hat, explizit darauf hinzuweisen, dass man grundsätzlich aus sicherheitstechnischen Gründen auf diese Art der Konfiguration verzichten solte, unter Umständen - die man dann auch definieren könnte - aber auf eigenes Risiko so vorgehen kann, wie von ruzima dargelegt. Man darf jetzt hier auch nicht den Anschein erwecken, als sei das hiesige Wiki in Hinsicht auf sicherheitsrelevante Aspekte stets präzise. Das ist IMO eher in Ausnahmefällen so. Grundsätzlich gebe ich Dir aber recht, dass im Bereich Sicherheit stets präzise der Stand der Technik dargelegt werden sollte. Ich bezweifle aber, dass eine Plattform wie ubuntuusers.de dazu dauerhaft in der Lage ist. Dazu fehlt nach meiner Vermutung die Expertise in der Breite und da greife ich mir durchaus auch an die eigene Nase. Mann kann aber aus den von mir im vorhergehenden Satz dargelegten Argumente auch die Einstellung vertreten, dass man dann auf Darstellung wie denen von ruzima verzichten sollte, weil die Community in der Breite nicht dazu in der Lage ist, mit den Informationen verantwortungsvoll umzugehen, bzw. es besteht immer ein gewisses Risiko, dass diese Informationen zu Lasten der Sicherheit fehlinterpretiert werden. Allerdings müssen dann konsequenter Weise ein Haufen Aussagen im Wiki diesbezüglich auf den Prüfstand. Aber noch mal: Grundsätzlich hast Du Recht! Weil ich kein Überblick habe:
Ist diese Methode eigentlich kompliziert zu konfigurieren oder ist sie "nur" in der Handhabung unbequem? Bzw. ist das ganze vielleicht einfach schlecht dokumentiert? Denn das ist IMO eines der häufigsten Probleme in der IT überhaupt, dass dann auch immer sicherheitsrelevante Auswirkungen hat. Allerdings lässt sich an der Dokumentation am "einfachsten" etwas ändern. Also wäre da eventuell auch ein Ansatzpunkt für die Problemstellung? LG, Newubunti |
||||||||||||
Supporter, Wikiteam
Anmeldungsdatum: Beiträge: 9384 Wohnort: Münster |
Das UbuntuUsers-Wiki ist nicht als „stets präzise“ anzusehen, auch nicht in Hinsicht auf sicherheitsrelevante Aspekte. Zu dieser Ansicht gelangt man bereits nach allgemeiner Lebenserfahrung. Dennoch sollte man auch generell stets Präzision und hier besonders in Hinsicht auf sicherheitsrelevante Aspekte anstreben. Und sich bewusst sein, dass man dieses Ziel nicht erreichen kann, was aber wiederum keine Ausrede sein darf, es nicht doch zu versuchen. Man kann auch durchaus unsichere Software und unsichere Praktiken verwenden, wenn man weiß, was man tut. Und auch darüber schreiben, aber dann sollte der Autor für den Leser entsprechende Warnungen einfügen. Die Wiki-Software kennt dafür auch zweckmäßige Formatierungen.
Nein. Tatsächlich muss man auf den Rechnern gar nichts konfigurieren. Man muss allerdings im eigenen Hirn den Schalter für das kritische Denken überprüfen und ggf. auf „eingeschaltet“ umstellen. Das scheint für manche bereits unbequem zu sein.
Ja.
Die meisten Menschen sind nach meiner Erfahrung durchaus bereit, sich vernünftig zu verhalten. Dabei gibt es nur zwei Probleme:
S.o. |
||||||||||||
Anmeldungsdatum: Beiträge: 19 |
Grundsätzlich bin ich dafür, dass Agent Forwarding nicht verwendet werden sollte, weil es Sicherheitsrisiken gibt und die meisten Anwender sind auch dieser Meinung. Trotzdem ist es immer wieder interessant, wenn man mal nachfragt, wer in letzter Zeit Agent Forwarding verwendet hat. Es sind dann doch einige die sich trauen es zuzugeben. Ich glaube, dass es sogar noch mehr sind aber es nicht zugeben möchten 😉 Der Lösung mit PuTTY und OpenSSH-Agent löst aber das grundsätzliche Problem nicht sondern richtet sich bereits an erfahrene Anwender, die sämtliche Schlüssel mit SSH-Askpass bzw. FIDO2 Tokens abgesichert haben. Es gibt ein paar Sicherheitslücken in den Clients, die es erlauben solche Sicherheitsmaßnahmen (SSH-Askpass/FIDO2) als Angreifer zu umgehen. Diese wurden in PuTTY aber nicht in OpenSSH behoben. Anmerkunug: Pagenat unterstützt kein SSH-Askpass/FIDO2 weshalb der OpenSSH-Agent benötigt wird. Die meisten Anwender verwenden weder SSH-Askpass noch einen FIDO2 Token. Viele haben noch nicht einmal davon gehört, dass es das gibt. In solchen Fällen ist es natürlich am Besten, wenn man von der Verwendung von Agent Forwarding abrät. Sobald aber etwas bequemer ist, auch wenn es unsicher ist, wird es trotzdem verwendet. Was soll schon passieren? Das ist das eigentliche Problem. Eine sichere Alternative gegenüber Agent Forwarding darf also nicht wesentlich unbequemer sein. Man müsste bestimmte Anwendungsfälle im Wiki beschreiben:
Nur dann sehe ich eine Möglichkeit, dass Agent Forwarding nicht mehr verwendet wird. Man sollte aber trotzdem Agent Forwarding erklären und auch auf Sicherheitslücken eingehen, weil sonst werden Empfehlungen, wie die von Github verwendet, wo auf die Sicherheitelücken nicht in vollem Umfang eingegangen wird: https://docs.github.com/en/developers/overview/using-ssh-agent-forwarding Dazu gehört es auch, dass Sicherheitslücken angesprochen und Workarounds beschrieben werden. Nur dann kann sich was ändern und ein Umdenken bei den Anwendern kann beginnen. Es wird dann sicher einige geben, die sich fragen werden, warum PuTTY diese Sicherheitslücken behoben hat und OpenSSH nicht. |
||||||||||||
Anmeldungsdatum: Beiträge: 19 |
Weiteres Vorgehen: Folgende Anwednungsfälle sollten im Wiki behandelt werden:
Dabei sollte wir uns brauchbare Lösungen einfallen lassen, die nicht wesentlich aufwändiger sind als Agent Forwarding. Das sind mal nur Vorschläge. Bitte nicht einfach schreiben "schaut gut" aus. Würde mich über kritische Kommentare und Verbesserungsvorschläge freuen. Auch solltet ihr Bedenken, dass es sowohl unter Linux als auch Windows funktionieren muss. Wir befinden uns zwar in einem Linux Wiki, Windows sollte man aber nicht außen vorlassen! Die Beispiele sind nicht auf Funktionalität getestet sondern nur mal eine grobe Idee! Beispiel: Arbeiten mit einem Git Repository auf einem Remote Server: In diesem Beispiel soll eine Webseite aus einem Git Repo akualisiert und bearbeitet werden. Mit Agent Forwaring:
Ohne Agent Forwarding:
Beispiel: SCP/SFTP von einem Remote Server auf einen anderen Server Mit Agent Forwarding: Ab OpenSSH 8.5:
Ohne Agent Forwarding: Die Datei wird von host1 auf den Client und von dort auf host2 kopiert, was bei langsamen Leitungen nicht sehr performant ist. Das war der Grund, warum die OpenSSH Entwickler dieses Jahr Agent Forwarding in die Version 8.5 eingebaut haben.
Beispiel: RSync von einem Remote Server auf einen anderen Server Mit Agent Forwarding:
Ohne Agent Forwarding:
|
||||||||||||
Anmeldungsdatum: Beiträge: 29567 |
Hallo,
Nein und ja. Grundsätzlich: im Artikel geht es um SSH - und "nur" im SSH. Sprich: es geht um eine kurzer Erklärung, wass SSH ist, wie man den Server installiert und den Client benutzt. Wenn SCP/SFTP noch immer mit SSH-Paket installiert werden kann das auch in den Artikel. Alles, was auf SSH aufsetzt, wie z.B. Git via SSH oder rsync via SSH bitte in separate Artikel bzw. eher Howtos auslagern. Grund: jeder weitere Zusatz / Aufsatz macht den Artikel schlechter testbar und erhöht das Risiko, dass der Artikel vergammelt. Gruß, noisefloor |