|
|
| (34 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| '''topic''' kurze Beschreibung | | '''topic''' - Kurzbeschreibung |
|
| |
|
| == Beschreibung == | | == Beschreibung == |
| == Installation == | | === scp === |
| == Syntax ==
| | siehe '''[[scp]]''' |
| === Parameter ===
| |
| === Optionen ===
| |
| === Umgebungsvariablen ===
| |
| === Exit-Status ===
| |
|
| |
|
| == Konfiguration == | | === sftp === |
| === Dateien ===
| | siehe '''[[sftp]]''' |
|
| |
|
| == Anwendungen ==
| | == Entfernte Dateisysteme einbinden == |
| == Sicherheit ==
| |
| == Dokumentation ==
| |
| === RFC ===
| |
| === Man-Pages ===
| |
| === Info-Pages ===
| |
| === Siehe auch ===
| |
| | |
| == Links ==
| |
| === Projekt-Homepage ===
| |
| === Weblinks ===
| |
| === Einzelnachweise ===
| |
| <references />
| |
| | |
| == Testfragen ==
| |
| <div class="toccolours mw-collapsible mw-collapsed">
| |
| ''Testfrage 1''
| |
| <div class="mw-collapsible-content">'''Antwort1'''</div>
| |
| </div>
| |
| <div class="toccolours mw-collapsible mw-collapsed">
| |
| ''Testfrage 2''
| |
| <div class="mw-collapsible-content">'''Antwort2'''</div>
| |
| </div>
| |
| <div class="toccolours mw-collapsible mw-collapsed">
| |
| ''Testfrage 3''
| |
| <div class="mw-collapsible-content">'''Antwort3'''</div>
| |
| </div>
| |
| <div class="toccolours mw-collapsible mw-collapsed">
| |
| ''Testfrage 4''
| |
| <div class="mw-collapsible-content">'''Antwort4'''</div>
| |
| </div>
| |
| <div class="toccolours mw-collapsible mw-collapsed">
| |
| ''Testfrage 5''
| |
| <div class="mw-collapsible-content">'''Antwort5'''</div>
| |
| </div>
| |
| | |
| = 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. <tt>-r</tt> 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 <tt>rsync -e ssh</tt> 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. | | 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. | | * Damit ist eine transparente Nutzung von Dateien auch über unsichere Netze hinweg möglich. |
| | * siehe [[sshfs]] |
|
| |
|
| === Grafische Programme zum Dateitransfer ===
| | == Grafische Programme zum Dateitransfer == |
| ==== Gnome/Ubuntu ====
| | === Gnome === |
| Der Gnome-Dateimanager unterstützt das SSH-Protokoll von Haus aus. | | Der Gnome-Dateimanager unterstützt das SSH-Protokoll von Haus aus. |
| * Dazu benutzt man eine Adresse der Form <tt>ssh://rechnername/pfad</tt>, um über SSH die Dateien auf dem angegebenen Rechner zu sehen. | | * Dazu benutzt man eine Adresse der Form <tt>ssh://rechnername/pfad</tt>, 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 <tt>ssh://andererbenutzer@rechnername/pfad</tt>. | | * Wenn man sich als ein anderer Benutzer anmelden möchte, verwendet man stattdessen eine Adresse der Form <tt>ssh://andererbenutzer@rechnername/pfad</tt>. |
| * Alternativ können auch die Hosts aus der <tt>~/.ssh/config</tt> verwendet werden. | | * Alternativ können auch die Hosts aus der <tt>~/.ssh/config</tt> verwendet werden. |
| * Dort lassen sich auch noch andere SSH-Einstellung, wie. | | * Dort lassen sich auch noch andere SSH-Einstellung, wie z.B SSH-Keys, definieren. |
| * z.B SSH-Keys, definieren.
| |
| * Der Zugriff erfolgt mit <tt>ssh://hostname</tt>. | | * Der Zugriff erfolgt mit <tt>ssh://hostname</tt>. |
| * Diese Adressen funktionieren übrigens auch in einigen anderen Gnome-Anwendungen. | | * Diese Adressen funktionieren übrigens auch in einigen anderen Gnome-Anwendungen. |
|
| |
|
| ==== KDE/Kubuntu ====
| | === KDE === |
| 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. | | 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. | | * Dies funktioniert im sowie in allen KDE-Anwendungen. |
| Zeile 118: |
Zeile 35: |
| * Diese Option einzustellen wird in KDE4 vermutlich in Dolphin selbst möglich sein. | | * Diese Option einzustellen wird in KDE4 vermutlich in Dolphin selbst möglich sein. |
|
| |
|
| ==== Xfce/Xubuntu ====
| | === Weitere grafische Programme === |
| 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. | | 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. | | * 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. |
| Zeile 130: |
Zeile 43: |
| SSH-Verbindungen zu Datenverzeichnissen auf Fremdrechnern unterstützen auch Datensynchronisationsprogramme wie und Backupprogramme wie Keep. | | SSH-Verbindungen zu Datenverzeichnissen auf Fremdrechnern unterstützen auch Datensynchronisationsprogramme wie und Backupprogramme wie Keep. |
|
| |
|
| == X-Forwarding == | | == Dokumentation == |
| 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.)
| | === Siehe auch === |
|
| |
|
| Das Programm muss sich nur an den X11-Standard halten, was leider die meisten Windows- und Mac-Programme ausschließt.
| | == Links == |
| | === Weblinks === |
|
| |
|
| Um das X11-Forwarding zu aktivieren, muss man dem '''ssh'''-Befehl die Option <tt>-X</tt> '''(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 <tt>-Y</tt>, 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 <tt>-x</tt> '''(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 <tt> #</tt> 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 <tt>-L</tt> 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 <tt>-L</tt> oder <tt>-R</tt> gibt dabei die Richtung an, aus der der Tunnel benutzt werden kann.
| |
| * Bei <tt>-L</tt> vom eigenen Rechner zum entfernten hin, bei <tt>-R</tt> in der entgegengesetzten Richtung. (Das merkt man sich am Besten als norma'''L''' 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 <tt>-N</tt>, 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 <tt>GatewayPorts</tt> 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 ==
| |
| * The Secure Shell (SSH) Protocol Architecture http://www.ietf.org/rfc/rfc4251.txt
| |
| * Video vom Vortrag Ubuntu im sicheren Netz - Ubucon 2011 http://www.youtube.com/watch?v=Hxsl-jj2Bq0
| |
| * Putting the Secure in SSH - Tipps und Tricks für sicheres SSH.
| |
| * Blogbeitrag, 11/2014http://thepcspy.com/read/making-ssh-secure/
| |
| * Mosh - auf SSH aufsetzende Lösung für den Fernzugriff auf andere Rechnerhttps://wiki.ubuntuusers.de/Mosh/
| |
| * [http://www.harding.motd.ca/autossh/ autossh] - Monitor für SSH-Verbindungen mit Reconnect-Möglichkeit (in den Paketquellen enthalten)http://www.harding.motd.ca/autossh/
| |
| * Portweiterleitung - DSL-Router für SSH freischaltenhttps://wiki.ubuntuusers.de/Portweiterleitung/
| |
| * SSH Reverse Tunnel oder wie mache ich ein Loch in die Firewall - Reverse SSH (keine Portweiterleitung nötig)http://www.codejungle.org/site/SSH+Reverse+Tunnel+oder+wie+mache+ich+ein+Loch+in+die+Firewall.html
| |
|
| |
|
|
| |
|
|
| |
|
| [[Kategorie:Entwurf]] | | [[Kategorie:SSH]] |
| [[Kategorie:ssh]]
| |