ubuntuusers.de

noisefloor schrieb:

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.

scp und sftp sind Bestandteil von OpenSSH und werden somit auch installiert.

Soll auf Agent Forwarding von SCP/SFTP von OpenSSH eingegangen werden oder davon abgeraten werden?

Die OpenSSH Entwickler haben diese Funktion ja nicht ohne Grund nach über 20 Jahren eingebaut... 😳

Mit Agent Forwarding (ab OpenSSH 8.5):

Datei wird direkt von host1 auf host2 kopiert.

1

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

Ohne Agent Forwarding und bei OpenSSH<8.5:

Die Datei wird von host1 auf den Client und von dort auf host2 kopiert, was bei langsamen Leitungen nicht sehr performant ist. (z.B. 4 GB ISO Image über eine 10Mbit Leitung 🙄 )

1

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

Der Workarround (PuTTY Client/OpenSSH-Agent), kann bei PuTTY hinzugefügt werden, weil es doch ein PuTTY spezifische Konfiguration ist und mit OpenSSH direkt nichts zu tun hat.

Begründung:

PuTTY ist ein SSH Client, der für die Authentifizierung mittels Publickey einen SSH Agent verwenden kann. Der SSH Agent wiederum ist ein eigenständiges Programm, dass von einem SSH Client Anfragen entgegennimmt und mit den privaten Schlüsseln kryptographische Operationen durchführt.

Unter Windows wird standardmäßig Pageant verwendet, der im Programmpaket von PuTTY enthalten ist. Bei Linux wird jedoch meist der OpenSSH-Agent verwendet, weil dieser auf den meisten Systemen vorinstalliert ist und beim Systemstart/Anmeldung automatisch gestartet wird.

ruzima schrieb:

... Soll auf Agent Forwarding von SCP/SFTP von OpenSSH eingegangen werden oder davon abgeraten werden?

Also grundsätzlich finde ich schon, dass auf implementierte Funktionen eingegangen werden sollte. Erst Recht dann wenn bei einem Dienst, dessen Kernaufgabe die Bereitstellung einer Sicherheitsinfrastruktur bezüglich der Einbindung mehr oder weniger starke Sicherheits-relevante Bedenken bestehen.

Da würde ich dem Motto folgen: Problem erkannt, Gefahr (halbwegs) gebannt.

Aber wie schon gesagt sehe ich das Agent Forwarding hier in einem eigenen Artikel also weder in SSH noch in PuTTY. Dem steht dann IMO nicht entgegen, dass es dabei - soweit der Artikel es erfordert - zu inhaltlichen Überschneidungen mit PuTTY bzw. SSH kommen kann.

Der Artikel sollte dabei aus meiner Sicht folgendes erklären:

• Was ist Agent Forwarding überhaupt genau?

• Wann kann und wann muss man es unter Umständen anwenden?

• Welche etwaigen sicherheitstechnischen Bedenken bestehen?

• Wenn Sicherheits-technische Bedenken bestehen, gibt es Alternativen? (Ob diese Alternativen dann Bestandteil dieses oder eines eigenständigen Artikels wären hängt auch vom Umfang ab. Generell würde ich sie eher in einem Artikel sehen auf den dann von diesem (Agent-Forwarding-Artikel) aus verlinkt würde)

• Eine Anleitung wie man Agent Forwarding (so sicher wie möglich) konkret anwendet. IMO wäre das dann auch der Raum für konkrete von Dir schon angerissene Anwendungsfälle. Solche praktischen Beispiele halte ich immer für angebracht, sie sollten aber aus Wiki-technischer Sicht auch nicht Überhand nehmen, denn sonst testet das auf Dauer niemand.

Diese Liste erhebt jetzt keinen Anspruch auf Vollständigkeit, aber das ist so das mindeste was ich mir als Leser - der in diesem Fall nämlich von dem Thema keine praktische Erfahrung hat - immer wünsche.

Was ich selbst nicht Einschätzen kann, welchen praktischen Stellenwert das Thema insgesamt und insbesondere für die hiesige Community hat.

LG, Newubunti

Sehe ich das richtig, dass "ssh -D ..." nicht behandelt worden ist?

a) Gibt es dafür einen verweigernden Grund (Sicherheit)?

b) Oder hat das nur noch keiner gemacht?

Hallo,

also bei so "großen" Progs wie ssh mit dutzenden von Optionen kannst du immer davon ausgehen, dass nicht alles im Wiki aufgeführt ist. Muss auch nicht, dass Wiki ist ja keine Handbuch oder Manpage Ersatz. In der Regel wird hier "nur" eine Einführung gegeben.

Ob jetzt in Wiki was fehlt oder nicht ist halt auch immer subjektiv und hängt von der Sichtweise dessen ab, was man selber gerade braucht. Im Falle der -D Option wäre es aus meiner Sicht so, dass man das nicht im "täglichen Umgang" mit ssh braucht. Auch wenn es sicherlich Anwendungsfälle gibt, wo die -D Option Sinn macht.

Gruß, noisefloor

... vielleicht hätte ich Lust einen Absatz dazu zu schreiben...

Wenn das aber nicht gewünscht ist... frage ich vorher besser nach...

Hallo,

Artikel ist in der Baustelle, kannst los legen.

Gruß, noisefloor

Jetzt MUSSS ich mich ja damit beschäftigen...

...zum querlesen freigegeben...!

Nicht nur dass ich das -D erklärt habe mit hoffentlich genügend, aber mit nicht zu vielen Beispielen die mißbräuchlich genutzt werden können,

sondern ich habe eine kurze Auflistung der Befehle des ssh Klient hinzugefügt.

Sowas vermisse ich nämlich ständig... Stichpunktartige Auflistung der wichtigsten Parameter ohne lange Erklärung.

Ok, die "wichtigsten" sind relativ... und manch einer denkt vielleicht mehrere Schnittstellen oder Adressen und Weiterleitungen sind für den Normalanwender nicht nötig. Aber wenn man etwas länger darüber Nachdenkt ist das nicht nur um in Netzwerksegmente von großen Organisationen einzudringen, sondern viele der Normalanwender haben weitere Netzwerkgeräte (Router, Accesspoints) im heimischen Netz, haben kleine Raspberry-Projekte oder nur der Fernseher, den TV-Receiver den man erreichen möchte, aber gerade kein VPN (was wesentlich sinnvoller wäre) zur Verfügung. (Einen Hinweis, dass das mit AVM-Produkten nicht schwer ist, habe ich auch hinzugefügt - ja... könnte als Werbung verstanden werden, aber... es ist doch wirklich damit nicht schwer, oder?)

Ich habe z.B. zum Konfigurieren von Routern und Accesspoints für freifunk.net auf meiner Netzwerkschnittstelle eine Konfiguration für die Karte die im Switch hängt, mit einer IP in dem Konfigurationsbereich konfiguriert. WIE??? Na, mein IP-Bereich ist 192.168.71.0 , aber die Router wollen, wenn sie resettet worden sind mit der Adresse 192.168.0.1 , 192.168.1.1 , 192.168.0.254 oder was auch immer Konfiguriert werden. Dazu dann eine zusätzlich IP - oder sogar eine eigene Netzwerkkarte ... oder ... man spielt mit Kontainern oder VM's umher... oje getreu meinem Motto - Windows ist nur mit WINE zu ertragen...

Hallo,

bitte Wiki/Syntax beachten, konkret:

• fett _nicht_ für Hervorhebungen

• Optionen von Befehlen in Monospace formatieren.

Das bitte korrigieren, sonst ist es IMHO ok.

Gruß, noisefloor

Hi!

Wo sollen denn die Links in Baustelle/SSH (Abschnitt „Aufruf-wichtige-Parameter“) hinführen? Da steige ich nicht ganz durch - sind die Ziele Anker/Überschriften im Artikel? Oder sollen sie auf andere Artikel verweisen? . Formatierungen, die mit "[:#" beginnen, führen ins Nirwana, und zu erkennen sind Dead-Links auch daran, dass sie ausgegraut sind...

Suboptimal ist auch die Verwendung der Fett-Formatierung, wenn es sich eigentlich um Unterüberschriften handelt.

so long
hank

EDIT - hab nochmal nachgearbeitet, ich hoffe es passt jetzt so...

Danke fürs Korrigieren, habe einen einzelnen Punkt, eine Zeile zur dynamischen Proxy Weiterleitung hinzugefügt...

Ich denke damit wäre es fertig, oder?

Hallo,

Artikel ist wieder im Wiki, Danke für die Ergänzungen.

Gruß, noisefloor

Eine Anmerkung zu dem Eintrag in der Datei /etc/ssh/sshd_config:

1

UsePAM no

Wenn ich dies setze, unterdrücke ich auf meinem Server Ubuntu 20.04.5 LTS Server die MOTD Informationen beim Login. Dies ist für mich aber recht wichtig, weil hier nützliche Infos über anstehende Updates und Zombie Prozesse ausgegeben werden.

In der /etc/ssh/sshd_config ist zudem der Hinweis:

1
2
3
4
5
6

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PAM authentication via ChallengeResponseAuthentication may bypass
# If you just want the PAM account and session checks to run without
# and ChallengeResponseAuthentication to 'no'.

Ich habe daher eingetragen:

1
2
3
4

UsePAM yes
ChallengeResponseAuthentication no
PasswordAuthentication no
PermitRootLogin no

Damit erhalte ich die MOTD Informationen, verbiete den root Login und kann mich nur über Public-Key einloggen.

kkarsten62 schrieb:

Eine Anmerkung zu dem Eintrag in der Datei /etc/ssh/sshd_config:

1

UsePAM no

[…]

Danke für den Hinweis. In der Tat kann die Abschaltung von PAM unerwünschte Nebeneffekte zeigen und ist auch unnötig. Ich habe die problematische Option UsePAM no (yes ist Standard) entfernt und Deine Hinweise in den Artikel eingearbeitet.

Der Artikel enthält bzgl einer Einstellung für Dolfin diesen Hinweis:

Um dies zu ändern, muss man im Konqueror eine fish-Adresse aufrufen und kann nun unter "Extras → Entfernte Zeichencodierung wählen..." die entsprechende Codierung einstellen. Diese Einstellung ist fortan auch in Dolphin gültig. Diese Option einzustellen wird in KDE4 vermutlich in Dolphin selbst möglich sein.

Ist dies noch aktuell oder wie ist der aktuelle Stand?