ubuntuusers.de

SSH

Status: Ungelöst | Ubuntu-Version: Nicht spezifiziert
Antworten |
Dieses Thema ist die Diskussion des Artikels SSH.

noisefloor Team-Icon

Anmeldungsdatum:
6. Juni 2006

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

ruzima

Avatar von ruzima

Anmeldungsdatum:
26. September 2021

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:

In the default configuration, ssh agent forwarding is still a security issue.

PuTTY and OpenSSH have added a lot of features ragarding agent forwarding and depending on the client, the configuration and the operating system, agent forwarding is more secure, than using a password protected private key on the remote server.

This combination only works on linux machines! (see notes about windows, macos not tested).

If agent forwarding is used, the private keys must be protected with ssh-askpass or a fido2 token.

The recommended method is using PuTTY in combination with the OpenSSH agent. PuTTY is able to detect and mitigate spoofing attacks in recent versions.

When using PuTTY>=0.76, you should use Disable "trivial" authentication (SSH-2 only). This option can be found under "Connection → SSH → Auth". In older versions (>0.71) you can use the trust sigils to detect spoofing attacks.

Pageant (PuTTY's agent) should not be used, because it does not support fido2 tokens or ssh-askpass. This is where the OpenSSH agent comes in.

You only have to start the ssh agent (if it is not already started). When PuTTY is started, it can use the OpenSSH agent without further configuration.

With this setup, you have to confirm each usage of the private key and abusing or spoofing a forwarded agent is not possible.

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.

Newubunti

Anmeldungsdatum:
16. Februar 2008

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:

  • Server = OpenSSH, Client = PuTTY

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

ruzima

Avatar von ruzima

Anmeldungsdatum:
26. September 2021

Beiträge: 19

Newubunti schrieb:

Wenn ich Dich richtig verstehe, dann siehst Du "Agent forwarding" nur in folgender Konstellation sicher betreibbar:

  • Server = OpenSSH, Client = PuTTY

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:

  • SSH Server: nicht relevant

  • SSH Client: PuTTY

  • SSH Agent: OpenSSH

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.

noisefloor Team-Icon

Anmeldungsdatum:
6. Juni 2006

Beiträge: 29567

Hallo,

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.

+1

PuTTY generell innerhalb des Artikel SSH abzuhandeln hielte ich - solange es nur um das Agent forwarding geht - dagegen für ungünstig, ...

+1

Zumal aufgeteilte Artikel (=ein Artikel pro Thema) wesentlich besser wartbar = zukunftssicherer sind.

Gruß, noisefloor

kB Team-Icon

Supporter, Wikiteam
Avatar von kB

Anmeldungsdatum:
4. Oktober 2007

Beiträge: 9384

Wohnort: Münster

ruzima schrieb:

[…] Agent forwarding

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 ProxyCommand und ProxyJump.

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.

ruzima

Avatar von ruzima

Anmeldungsdatum:
26. September 2021

Beiträge: 19

kB schrieb:

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 ProxyCommand und ProxyJump.

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.

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.

+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.

Es mag durchaus funktionale Gründe geben, verschiedene Implementationen zu mischen. Wer so etwas tun will, sollte aber die sicherheitstechnischen Aspekte im Blick behalten.

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.

ruzima

Avatar von ruzima

Anmeldungsdatum:
26. September 2021

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.

kB Team-Icon

Supporter, Wikiteam
Avatar von kB

Anmeldungsdatum:
4. Oktober 2007

Beiträge: 9384

Wohnort: Münster

ruzima schrieb:

[…] 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.

Ja, das ist eine missliche Situation, für deren Behandlung es zwei funktionale Lösungen gibt:

  1. Man bringt seinen privaten Schlüssel auf den nicht vertrauenswürdigen fremden Rechner. Das ist aus den von Dir dargestellten Gründen eine schlechte Idee.

  2. Man verwendet Agent Forwarding, welches die Experten (wie Du selber schreibst) als böse betrachten. Das ist auch eine schlechte Idee.

Es gibt eine dritte Möglichkeit: Man vermeidet die Situation. Das erfordert:

  1. Den Zugriff auf das Git Repository nicht vom fremden Server, sondern vom eigenen Rechner durchführen, und

  2. die benötigten Dateien sicher zwischen eigenem und fremdem Rechner transferieren.

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.

[…] Die letzten 10-15 Jahre war die allgemeine Meinung, dass Agent Forwarding böse ist […]

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.

ruzima

Avatar von ruzima

Anmeldungsdatum:
26. September 2021

Beiträge: 19

kB schrieb:

Es gibt eine dritte Möglichkeit: Man vermeidet die Situation. Das erfordert:

  1. Den Zugriff auf das Git Repository nicht vom fremden Server, sondern vom eigenen Rechner durchführen, und

  2. die benötigten Dateien sicher zwischen eigenem und fremdem Rechner transferieren.

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 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...

[…] Die letzten 10-15 Jahre war die allgemeine Meinung, dass Agent Forwarding böse ist […]

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.

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.

Newubunti

Anmeldungsdatum:
16. Februar 2008

Beiträge: 5142

kB schrieb:

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.

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:

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

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:

Es gibt eine dritte Möglichkeit: Man vermeidet die Situation. Das erfordert: ...

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

kB Team-Icon

Supporter, Wikiteam
Avatar von kB

Anmeldungsdatum:
4. Oktober 2007

Beiträge: 9384

Wohnort: Münster

Newubunti schrieb:

[…] Man darf jetzt hier auch nicht den Anschein erwecken, als sei das hiesige Wiki in Hinsicht auf sicherheitsrelevante Aspekte stets präzise.

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.

[…]

Es gibt eine dritte Möglichkeit: Man vermeidet die Situation. Das erfordert: ...

Ist diese Methode eigentlich kompliziert zu konfigurieren

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.

oder ist sie "nur" in der Handhabung unbequem?

Ja.

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.

Die meisten Menschen sind nach meiner Erfahrung durchaus bereit, sich vernünftig zu verhalten. Dabei gibt es nur zwei Probleme:

  1. Sie müssen bereit sein, sich aufklären zu lassen. Aus eigener Erfahrung weiß ich, das dies unbequem sein kann.

  2. Man muss sie Aufklären. Aus eigener Erfahrung weiß ich, das dies unbequem ist.

Allerdings lässt sich an der Dokumentation am "einfachsten" etwas ändern. Also wäre da eventuell auch ein Ansatzpunkt für die Problemstellung?

S.o.

ruzima

Avatar von ruzima

Anmeldungsdatum:
26. September 2021

Beiträge: 19

kB schrieb:

Es gibt eine dritte Möglichkeit: Man vermeidet die Situation. Das erfordert: ...

Ist diese Methode eigentlich kompliziert zu konfigurieren

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.

oder ist sie "nur" in der Handhabung unbequem?

Ja.

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:

  • Arbeiten mit einem Git Repository

  • SCP/SFTP von einem Remote Server auf einen anderen Server

  • RSync von einem Remote Server auf einen anderen Server

  • ...

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.

ruzima

Avatar von ruzima

Anmeldungsdatum:
26. September 2021

Beiträge: 19

Weiteres Vorgehen:

Folgende Anwednungsfälle sollten im Wiki behandelt werden:

  • Arbeiten mit einem Git Repository auf einem Remote Server

  • SCP/SFTP von einem Remote Server auf einen anderen Server

  • RSync von einem Remote Server auf einen anderen Server

  • ...

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:

1
2
3
4
5
6
ssh -A devserver
git pull
vim homepage.php
git add homepage.php
git commit -m "test"
git push

Ohne Agent Forwarding:

1
2
3
4
5
6
git pull
vim homepage.php
rsync ... devserver
git add homepage.php
git commit -m "test"
git push

Beispiel: SCP/SFTP von einem Remote Server auf einen anderen Server

Mit Agent Forwarding:

Ab OpenSSH 8.5:

1
scp -A host1:/path/to/file host2:/path/to/file

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.

1
scp -3 host1:/path/to/file host2:/path/to/file

Beispiel: RSync von einem Remote Server auf einen anderen Server

Mit Agent Forwarding:

1
2
ssh -A host1
rsync ... hotst2

Ohne Agent Forwarding:

1
ssh -R localhost:50000:host2:22 host1 'rsync -e "ssh -p 50000" -vuar /var/www localhost:/var/www'

noisefloor Team-Icon

Anmeldungsdatum:
6. Juni 2006

Beiträge: 29567

Hallo,

Folgende Anwednungsfälle sollten im Wiki behandelt werden:

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