SSH/Dateitransfer

Aus Foxwiki

topic kurze Beschreibung

Beschreibung

Installation

Syntax

Parameter

Optionen

Umgebungsvariablen

Exit-Status

Konfiguration

Dateien

Anwendungen

Sicherheit

Dokumentation

RFC

Man-Pages

Info-Pages

Siehe auch

Links

Projekt-Homepage

Weblinks

Einzelnachweise


Testfragen

Testfrage 1

Antwort1

Testfrage 2

Antwort2

Testfrage 3

Antwort3

Testfrage 4

Antwort4

Testfrage 5

Antwort5

TMP

Dateitransfer

Wenn man also ein Protokoll hat, das so sicher wie nach dem heutigen Stand der Technik möglich Daten durch einen verschlüsselten Kanal senden und empfangen kann, dann wäre es wohl Verschwendung, dieses Protokoll nur für interaktive Terminal-Sessions zu benutzen.

  • Sehr häufig möchte man bspw.
  • einfach nur Dateien sicher von einem System zum anderen bewegen.
  • Dafür existieren verschiedene Programme der grafischen Benutzeroberfläche sowie gleich zwei Terminalbefehle nämlich scp und sftp.

Transfer von der Kommandozeile

scp

Das Kommandozeilenwerkzeug scp funktioniert in etwa so wie das normale Unix-Kommando cp, nur dass es über Systemgrenzen hinweg funktioniert.

  • Jedes Datei- oder Verzeichnisargument kann dabei optional, getrennt durch einen Doppelpunkt, durch einen vorangestellten Benutzer- oder Hostnamen ergänzt werden.
  • Dabei werden weggelassene Teile durch den aktuellen Benutzernamen, localhost oder das Homeverzeichnis (oder das aktuelle Verzeichnis) ergänzt, etwa so:
scp benutzerx@server1:datei1 datei2 benutzery@server2:

In diesem Beispiel wurde die datei1 aus dem Homeverzeichnis von benutzerx auf server1 und die datei2 aus dem aktuellen Verzeichnis des lokalen Hosts in das Homeverzeichnis von benutzery auf server2 kopiert.

Der Befehl scp versteht auch einige von bekannte Optionen, bspw. -r für das rekursive Kopieren ganzer Verzeichnisbäume.

  • Bedauerlicherweise unterstützt scp aber nicht alle cp-Optionen, die für das exakte Klonen von Verzeichnissen, inkl.
  • aller Dateirechte und symbolischen Verknüpfungen notwendig sind.
  • Für die exakte Replikation sollte deswegen entweder das Werkzeug rsync -e ssh genutzt werden (man beachte die Handbuchseite zu diesem Tool) oder der oben schon genutzte Trick mit tar und einer Pipe.
ssh root@server 'cd verzeichnis; tar czvf - verz./dateien' | tar xzf -

sftp

Die andere Möglichkeit des Dateitransfers lautet sftp.

  • Das funktioniert genau so wie der normale Kommandozeilen-FTP-Client:
sftp server 

Connecting to server...
user@server's password:
sftp> pwd
Remote working directory: /export/home/user
sftp> dir
[...]
wichtige_datei.txt
[...]
sftp> get wichtige_datei.txt
Fetching /export/home/user/wichtige_datei.txt to wichtige_datei.txt
/export/home/user/wichtige_datei.txt                                                     100%   62KB  62.2KB/s   00:00
sftp> quit

Mit dem Befehl help bekommt man eine Übersicht über die möglichen Kommandos.

Entfernte Dateisysteme einbinden

Man kann das Dateisystem eines entfernten Rechners in sein eigenes Dateisystem mittels einbinden.

  • Damit ist eine transparente Nutzung von Dateien auch über unsichere Netze hinweg möglich.

Grafische Programme zum Dateitransfer

Gnome/Ubuntu

Der Gnome-Dateimanager unterstützt das SSH-Protokoll von Haus aus.

  • Dazu benutzt man eine Adresse der Form ssh://rechnername/pfad, um über SSH die Dateien auf dem angegebenen Rechner zu sehen.
  • Wenn man sich als ein anderer Benutzer anmelden möchte, verwendet man stattdessen eine Adresse der Form ssh://andererbenutzer@rechnername/pfad.
  • Alternativ können auch die Hosts aus der ~/.ssh/config verwendet werden.
  • Dort lassen sich auch noch andere SSH-Einstellung, wie.
  • z.B SSH-Keys, definieren.
  • Der Zugriff erfolgt mit ssh://hostname.
  • Diese Adressen funktionieren übrigens auch in einigen anderen Gnome-Anwendungen.

KDE/Kubuntu

Auch bei KDE ist SSH-Unterstützung eingebaut: Mit einer Adresse der Form fish://rechnername/pfad kann man auf die Dateien auf einem anderen Rechner zugreifen, und mit fish://andererbenutzer@rechnername/pfad meldet man sich als anderer Benutzer auf dem Zielrechner an.

  • Dies funktioniert im sowie in allen KDE-Anwendungen.

Man kann also beispielsweise im Malprogramm via Datei -> Öffnen.. und dann oben in der Adresszeile eine fish://-Adresse eingeben, um direkt ein Bild auf einem anderen Rechner anzusehen oder zu bearbeiten.

  • Im Dateimanager (Kubuntu-Standard) können über das Bookmark "Netzwerk" und den Assistenten "Netzwerkordner hinzufügen" neue ssh-basierte Netzwerkordner als feste Bookmarks erstellt werden.

Wenn der Zielrechner ebenfalls ein UTF-8 codiertes Dateisystem hat, sind gegebenenfalls die Umlaute falsch angezeigt.

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

Xfce/Xubuntu

Der Xfce-Dateimanager unterstützt das SSH-Protokoll wie Nautilus unter GNOME.

  • Siehe .

Weitere grafische Programme

Die meisten grafischen FTP-Clients () unterstützen auch sftp oder scp über das SSH-Protokoll.

  • Beim Gnome FTP-Cient etwa muss man unter "FTP -> Optionen -> Netz -> Voreingestelltes Protokoll" in der Drop-Down-Liste SSH2 an Stelle von FTP auswählen.
  • Leider hat gftp Probleme, wenn man neben Passwörtern auch Public-Keys (siehe ) benutzt.
  • Das funktioniert nur mit dem SSH-Agenten (ebenfalls weiter unten beschrieben) und der Einstellung "Benötige SSH Benutzername/Passwort nicht" in "FTP -> Optionen -> SSH".

SSH-Verbindungen zu Datenverzeichnissen auf Fremdrechnern unterstützen auch Datensynchronisationsprogramme wie und Backupprogramme wie Keep.

X-Forwarding

Mit dem X11-Forwarding kann man auch grafische Programme, die man über SSH auf einem anderen Rechner startet, auf dem eigenen Display anzeigen lassen, und zwar unabhängig davon, welches Betriebssystem auf dem entfernten Rechner läuft (siehe Bild.)

Das Programm muss sich nur an den X11-Standard halten, was leider die meisten Windows- und Mac-Programme ausschließt.

Um das X11-Forwarding zu aktivieren, muss man dem ssh-Befehl die Option -X (großes X) hinzufügen, die dem Programm eingeschränkte Rechte am eigenen Display einräumt.

Für den Fall, dass es zu einem Programmabbruch kommt, weil diese eingeschränkten Rechte nicht ausreichen, existiert noch die Option -Y, die dem Programm volle Rechte gewährt.

Diese sollte man jedoch nicht verwenden, wenn man dem Administrator des entfernten Rechners nicht vertraut, denn sie öffnet einen Tunnel, der auch in der umgekehrten Richtung für einen Angriff auf das eigene Display genutzt werden könnte.

Vorsicht: mit der Option -x (kleines x) wird X11-Forwarding deaktiviert.

Hinweis: bei Nutzung von VNC (zum Beispiel für Fernwartung) muss auf dem Server X11VNC installiert sein.

Einen deutlichen Geschwindigkeitszuwachs erreicht man durch die Wahl einer anderen Verschlüsselung und der Aktivierung der Kompression der Daten für langsame Verbindungen (DSL, etc.) mit diesen zusätzlichen Optionen im Aufruf von ssh: -c arcfour,blowfish-cbc -XC.

  • Beispiele:

Öffnen des Programms und andere: ssh -X user@server lxpanel &

Da Panel-Programme in der Regel nicht über eine Funktion "schließen" verfügen kann man diese zum Beispiel mittels schließen.

Serverkonfiguration

Dies sollte in der Regel nicht notwendig sein.

  • Auf dem Server muss hierfür das Paket xauth installiert werden, wenn es das noch nicht ist.
  • Außerdem muss dem SSH-Daemon des Servers mitgeteilt werden, dass X-Forwarding verwendet wird.
  • Das wird über die Konfigurationsdatei /etc/ssh/sshd_config erledigt.
  • Dort werden die Optionen:
X11Forwarding yes
X11UseLocalhost no

gesetzt.

  • Danach ist ein Neustart des Daemons erforderlich.

Zusätzlich müssen in der Client-Konfigurationsdatei /etc/ssh/ssh_config die Einträge: 

ForwardX11 yes

und 

ForwardX11Trusted yes

durch Entfernen von # am Zeilenanfang einkommentiert werden.

SSH-Tunnel

Wenn man mit Hilfe von SSH so ein nicht ganz triviales Protokoll wie X-Window tunneln kann, dann muss das doch auch mit anderen Protokollen funktionieren, oder? - Aber sicher geht das.

  • Allerdings ist die Syntax für den SSH-Tunnelbau ein wenig verwirrend:
ssh -L [bind_address:]port:host:port user@server
ssh -R [bind_address:]port:host:port user@server

Hierbei richtet die Option -L laut Dokumentation eine lokale, und die Option '-R' eine entfernte (englisch remote) Port-Weiterleitung ein.

Der verschlüsselte Tunnel wird dabei immer zwischen dem eigenen Rechner und server hergestellt.

  • Die Verbindung vom Ende des Tunnels zu host läuft dagegen unverschlüsselt ab, und wird aus Sicht des betreffenden Systems angegeben, weswegen man host in den allermeisten Fällen wohl auf "localhost" setzen sollte.
  • Hierbei darf "localhost" nicht mit dem lokalen Rechner verwechselt werden.

Es handelt sich um "localhost" von server aus betrachtet, daher um den Server selbst.

Die Option -L oder -R gibt dabei die Richtung an, aus der der Tunnel benutzt werden kann.

  • Bei -L vom eigenen Rechner zum entfernten hin, bei -R in der entgegengesetzten Richtung. (Das merkt man sich am Besten als normaL und Rückwärts.)

Das erste port-Argument bezeichnet dabei den Einstiegsport in die Verbindung.

  • Zu beachten ist hierbei, dass die Öffnung eines privilegierten Ports, also unter 1024, nur dem Superuser root gestattet ist.
  • Man sollte also auf die höheren Ports ausweichen.

Mit dem optionalen Parameter bind_address kann man festlegen, auf welchen Netzwerkschnittstellen die Weiterleitung laufen soll, wobei localhost der Standard ist.

Ein * oder ein leeres bind_address-Argument vor dem Doppelpunkt bedeutet, dass die Weiterleitung an allen Schnittstellen läuft.

  • Möglicherweise funktioniert das nicht auf jedem Ubuntu-System auf Anhieb, da die IPv6-Adresse das irgendwie verhindert, weshalb man den SSH-Tunnel mit dem Argument -4 auf die IPv4-Schnittstellen beschränken muss.

Der zweite port-Parameter gibt schließlich an, auf welchen Port von host die Weiterleitung gehen soll.

Ein weiteres nützliches Argument ist die Option -N, die das Erzeugen einer Terminal-Sitzung auf dem entfernten System unterbindet, wenn man nur die Port-Weiterleitung benutzen möchte.

Beispiele

Weiterleitung von Port 8000 auf dem lokalen System an den Webserver (Port 80) auf server: 

ssh -L 8000:localhost:80 server -N &
netstat -anp --inet | egrep '(^Proto|8000)' 
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:8000          0.0.0.0:*               LISTEN     10843/ssh
fg 
ssh -L 8000:localhost:80 server -N
[Strg-C]
Killed by signal 2.

Dasselbe, aber es wird nicht nur vom lokalen Host weitergeleitet, sondern von allen Schnittstellen (hierzu ist die Option GatewayPorts in der Server-Konfiguration entsprechend zu setzen, genaueres zu finden in der Manpage; man wähle diese Option mit Bedacht!): 

ssh -L *:8000:localhost:80 server -N -4 &
netstat -anp --inet | egrep '(^Proto|8000)' 
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:8000            0.0.0.0:*               LISTEN     10906/ssh

Umgekehrte Richtung.

  • Benutzern auf server wird ermöglicht, über localhost:3306 auf den MySQL-Server auf client zuzugreifen:
ssh -R 3306:localhost:3306 server 
Last login: Sat Mar 11 23:24:20 2006 from 192.168.4.56
netstat -an --inet | egrep '(^Proto|3306)'
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN
exit
logout
Connection to server closed.

Zur Veranschaulichung folgt hier noch einmal eine grafische Darstellung dieser Beispiele:

Doppelter SSH-Tunnel über zwei Konsolen: 

supportpc$ ssh -L 54321:localhost:54321 zwischennutzer@zwischen
zwischen$ ssh -L 54321:localhost:8080 zielnutzer@ziel

SSH-Tunnel über Zwischenrechner mit Zielrechner verbinden: 

supportpc$ ssh -L 54322:ziel:22 zwischennutzer@zwischen

Verschlüsselungsdetails

Symmetrische Verschlüsselung

Wer als Laie an Verschlüsselung denkt, der denkt meist an die "symmetrische Verschlüsselung".

  • Hierbei gibt es genau einen Schlüssel, mit dem ein Datensatz verschlüsselt wird.

Nur wer diesen Schlüssel kennt (oder durch Probieren herausfindet) kann die Verschlüsselung umkehren und den Klartext wieder extrahieren.

Bekannte und bewährte Algorithmen wie TripleDES, AES und Blowfish machen das Erraten des Schlüssels natürlich nicht gerade leicht, genauer gesagt, nach dem heutigen Stand der Technik nahezu unmöglich.

Das einzige Problem bei der Benutzung von symmetrischer Verschlüsselung ist, den Schlüssel sicher zum Kommunikationspartner zu befördern.

Asymmetrische Verschlüsselung

Um dieses Problem der symmetrischen Verschlüsselung zu umgehen, gelang es Forschern schon vor einiger Zeit, das gemeinsame Geheimnis, das für eine erfolgreiche Ver- und Entschlüsselung nötig ist, so hinter komplizierten Algorithmen zu verbergen, dass man es unter bestimmten Bedingungen öffentlich verteilen konnte.

Bei diesem Verfahren, asymmetrische Verschlüsselung genannt, wird nicht ein Schlüssel erzeugt, sondern ein Schlüsselpaar, das mathematisch voneinander abhängt, aber nicht ohne sehr viel Aufwand voneinander abgeleitet werden kann.

Jeweils zwei zueinander passende Schlüssel wirken auf geradezu magische Weise genau entgegengesetzt: Was mit dem einen Schlüssel verschlüsselt wird, kann nur durch den anderen Schlüssel wieder entschlüsselt werden.

Dies ermöglicht es, einen der beiden Schlüssel öffentlich zur Verfügung zu stellen, um Sendungen zu verschlüsseln, die man aber einzig und allein mit dem anderen Schlüssel, den man niemals weitergibt, entschlüsseln kann.

Im Gegenzug kann man ein Datenpaket auch mit dem eigenen privaten Schlüssel chiffrieren.

  • Wenn dieser Chiffretext sich dann mit dem öffentlichen Schlüssel wieder in Klartext zurückverwandeln lässt, weiß jeder, dass die Nachricht nur vom Besitzer des privaten Schlüssels kommen kann.

Diese Anwendungsmöglichkeit nennt man digitale Signatur.

Da der Umgang mit asymmetrischen Verschlüsselungsalgorithmen wie RSA oder DSA signifikant mehr Rechenleistung erfordert als mit symmetrischen, ist es gängige Praxis, am Beginn der Kommunikation mit Hilfe des öffentlichen Schlüssels einen neu generierten, symmetrischen Session-Schlüssel auszutauschen und für den Rest der Kommunikation auf symmetrische Verschlüsselung umzusteigen.

Links

Abgerufen von „https://wiki.foxtom.de/index.php?title=SSH/Dateitransfer&oldid=40527“