|
|
| (104 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| == Was ist die Secure Shell? ==
| | '''Secure Shell''' ('''SSH''') - [[Kryptografie|kryptographisches]] [[Netzwerkprotokoll]] für den sicheren Betrieb von [[Netzwerkdienst]]en über ungesicherte Netzwerke |
| * Es gab einmal eine Zeit, als Computer im Netz über das [http://de.wikipedia.org/wiki/Telnet Telnet]-Protokoll zugänglich waren. Da dieses Protokoll keine Verschlüsselung bot, wurde das Mitschneiden von Passwörtern zur trivialen Angelegenheit.
| |
| * Um den Fernzugang zu sichern, schrieb Tatu Ylönen Mitte der 1990er eine Programmsuite – bestehend aus Server, Client und Hilfsprogrammen – die er '''ssh''' (''secure shell'') nannte.
| |
| * Später gründete er die Firma [http://www.ssh.com/ ssh.com] und bot die Version 2 der SSH-Suite nur noch kommerziell an. Daraufhin wurde von Entwicklern des Betriebssystems [http://de.wikipedia.org/wiki/OpenBSD OpenBSD] der öffentliche Quellcode der Version 1 [http://de.wikipedia.org/wiki/Abspaltung_%28Softwareentwicklung%29 geforkt]. Sie entwickelten das Programm unter dem Namen "OpenSSH" weiter. Diese OpenSSH-Suite wurde fester Bestandteil quasi aller Linux-Distributionen.
| |
| * Drei wichtige Eigenschaften führten zum Erfolg von '''ssh''' :* Authentifizierung der Gegenstelle, kein Ansprechen falscher Ziele
| |
| ** Verschlüsselung der Datenübertragung, kein Mithören durch Unbefugte
| |
| ** Datenintegrität, keine Manipulation der übertragenen Daten
| |
| * Mehr Details zur verwendeten Verschlüsselung finden sich [https://wiki.ubuntuusers.de/SSH/#Weitere-Verschluesselungsdetails weiter unten]. Falls man sich auf den eigenen Computer hinter einem DSL-Router per SSH einloggen will, muss man zuvor in diesem eine [https://wiki.ubuntuusers.de/Portweiterleitung/ Portweiterleitung] einrichten, sonst kommt keine Verbindung zustande.
| |
|
| |
|
| == Der SSH-Client == | | == Beschreibung == |
| * Das funktioniert normalerweise in einen Terminal-Fenster [https://wiki.ubuntuusers.de/SSH/#source-2 [2]] so: | | ; Verwendung |
| ssh user@sol-1
| | * Fernzugriff auf Computersysteme |
| user@sol-1's password:
| | * Sichere Übertragung von Dateien über nicht vertrauenswürdige Netzwerke |
| Last login: Sun Feb 12 07:38:50 2006 from client.local
| | * Entfernte [[Kommandozeile]] |
| Sun Microsystems Inc. SunOS 5.9 Generic_112234-03 November 2002
| | ** auf einer lokalen Konsole werden die Ausgaben der entfernten Konsole ausgegeben |
| bash-2.05$
| | ** lokale Tastatureingaben werden an den entfernten Rechner gesendet |
| Und schon befindet man sich auf einem anderen System, in diesem Fall mit dem Betriebssystem Solaris.
| |
| ssh server
| |
| Password:
| |
| Linux vdr 2.4.27-ctvdr-1 #1 Fri Oct 15 18:38:29 UTC 2004 i686 GNU/Linux
| |
| The programs included with the Debian GNU/Linux system are free software;
| |
| the exact distribution terms for each program are described in the
| |
| individual files in /usr/share/doc/*/copyright.
| |
| Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
| |
| permitted by applicable law.
| |
| You have new mail.
| |
| Last login: Sun Feb 12 07:38:23 2006 from client.local
| |
| user@server:~$
| |
| Oder auf einem anderen Linux-System. Wie man sieht, ist die Angabe des Benutzernamens optional, wenn er auf beiden Systemen gleich ist. Man kann auch einfach einen Befehl anhängen, der anstelle der Terminal-Session ausgeführt wird. Nach der Ausführung des Befehls wird die SSH-Session dann automatisch beendet:
| |
| ssh server cat /etc/issue
| |
| Password:
| |
| Debian GNU/Linux 3.1 \n \l
| |
|
| |
|
| Oder etwas komplizierter - eine Datensicherung machen ("backup"):
| | ; Verfügbarkeit |
| user@client:~$ ssh root@server 'cd /etc; tar czvf - network/' | cat > etc_network_backup.tar.gz
| | * [[Unixoides System|unixoiden]] Betriebssysteme |
| Password:
| | * [[Microsoft Windows]] |
| network/
| |
| network/interfaces
| |
| network/if-post-down.d/
| |
| network/if-pre-up.d/
| |
| network/if-up.d/
| |
| network/if-down.d/
| |
| network/options
| |
| network/interfaces.pre-etherconf
| |
| network/interfaces.1
| |
| network/run
| |
| Bei einer langsamen Verbindung empfiehlt sich zusätzlich die Benutzung der Option <tt>-C</tt> (großes C), die zusätzlich zur Verschlüsselung eine transparente Kompression der übertragenen Daten aktiviert. Bei einer schnellen Verbindung wird die Kompression aber vermutlich bremsen.
| |
| * Woher weiß man nun aber, dass man tatsächlich mit dem richtigen Rechner verbunden ist, und nicht ein Angreifer die Verbindung umgeleitet hat? Dafür gibt es den Host-Schlüssel, der jeden SSH-Server eindeutig identifiziert. Greift man zum ersten Mal auf einen bestimmten Server zu, kennt man diesen Schlüssel natürlich noch nicht. (Außer man hat ihn sich auf anderen Wegen im Voraus besorgt.) | |
| ssh server
| |
| The authenticity of host 'server (192.168.1.5)' can't be established.
| |
| ECDSA key fingerprint is b5:0e:ec:b7:16:06:e6:24:a6:39:18:58:4e:ec:3b:d1.
| |
| Are you sure you want to continue connecting (yes/no)? yes
| |
| Warning: Permanently added 'server' (ECDSA) to the list of known hosts.
| |
| Password:
| |
| * Wenn gerade in diesem Moment jemand die Verbindung gekapert hat, hat man natürlich Pech, außer man kann den Administrator des Servers nach dem richtigen Fingerprint des Host-Schlüssels fragen.
| |
| * Den ECDSA-Fingerprint eines Servers kann man mit dem Systemprogramm '''ssh-keygen''' erfahren: | |
| ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key.pub -l
| |
| gibt den Fingerprint und einige weitere Informationen aus, z.B. <tt>256 b5:0e:ec:b7:16:06:e6:24:a6:39:18:58:4e:ec:3b:d1 root@server (ECDSA)</tt>. Wenn man auf Nummer sicher gehen möchte, lässt man sich vom Administrator des Servers diese Ausgabe mitgeben (evtl. ausdrucken) und kann dann beim ersten Verbindungsversuch überprüfen, ob man sich tatsächlich zum richtigen SSH-Server verbunden hat und nicht zu einem dazwischengeschalteten Angreifer.
| |
|
| |
|
| Bei allen weiteren Kontakten stellt das '''ssh'''-Programm jedoch von nun an über asymmetrische Kryptografie sicher, dass der Server auch über den richtigen öffentlichen Schlüssel verfügt, der zum öffentlichen, in der Datei '''~/.ssh/known_hosts''' abgelegten passt, und verweigert im Zweifelsfall den Verbindungsaufbau.
| | ; Ziele |
| | Authentifizierung |
| | * Authentifizierung der Gegenstelle |
| | * Kein Ansprechen falscher Ziele |
| | Vertraulichkeit |
| | * Kryptografie der Datenübertragung |
| | Integrität |
| | * Keine Manipulation der übertragenen Daten |
|
| |
|
| Sollte sich dieser Schlüssel einmal aus legitimen Gründen geändert haben, bspw. weil das System neu aufgesetzt wurde, muss man den entsprechenden veralteten Schlüssel erst einmal auf dem Client mit dem Befehl
| | ; Port Zuordnung |
| | * [[Internet Assigned Numbers Authority|IANA]] |
| | * [[Transmission Control Protocol|TCP]]-[[Port (Protokoll)|Port]] 22 |
| | * [[User Datagram Protocol|UDP]]-Port 22 |
| | * [[Stream Control Transmission Protocol|SCTP]]-Port 22 |
|
| |
|
| ssh-keygen -R hostname
| | ; [[Client-Server-Modell|Client–Server]]-Architektur |
| | Eine SSH-Client-Anwendung verbindet sich mit einem SSH-Server |
| | ;Protokollspezifikation |
| | * SSH-1 |
| | * SSH-2 |
|
| |
|
| aus der '''known_hosts'''-Datei entfernen.
| | ; Fernwartung |
| | * Genutzt werden kann dies z. B. zur [[Fernwartung]] eines in einem entfernten Rechenzentrum stehenden [[Server]]s. |
| | * Die neuere Protokoll-Version SSH-2 bietet weitere Funktionen wie [[Datenübertragung]] per [[SSH File Transfer Protocol|SFTP]]. |
|
| |
|
| Sollte die Verbindung nicht mehr reagieren, z.B. wenn der SSH-Server heruntergefahren wurde, lässt sich der ssh-Client mit der Eingabe von "<tt>~.</tt>" (nacheinander) beenden.
| | Ersatz für Telnet |
| | * Bestandteil aller Linux- und Unix-Distributionen |
| | * Dabei dient SSH als Ersatz für andere, unsichere Methoden wie [[Telnet]]. |
| | * Bei diesen werden alle Informationen, auch sensible wie etwa [[Passwort|Passwörter]], im [[Klartext (Kryptografie)|Klartext]] übertragen. |
| | * Dies macht sie anfällig für [[Man-in-the-Middle-Angriff]]e sowie einen Vertraulichkeitsverlust durch [[Sniffer|Packet Analyzer]], die die [[Datenpaket]]e mitschneiden. Die [[Kryptografie]]stechnik, die durch SSH genutzt wird, hat deshalb den Zweck, die Vertraulichkeit, Integrität und Authentizität von Daten, die über ein unsicheres Netzwerk (wie z. B. das [[Internet]]) gesendet werden, sicherzustellen. |
|
| |
|
| ==== Hinweis ==== | | == Siehe auch == |
| | * [[OpenSSH]] |
| | {{Special:PrefixIndex/SSH}} |
|
| |
|
| Wer (noch) einen Windows-Desktop benutzt und über das SSH-Protokoll auf eine Linux-Maschine zugreifen will, kann das Programm [https://wiki.ubuntuusers.de/PuTTY/ PuTTY] nutzen.
| | === Sicherheit === |
| | # [[SSH/Kryptografie]] |
|
| |
|
| === Benutzeroberflächen === | | === Dokumentation === |
| | | ==== RFC ==== |
| Wem es zu mühsam ist, auf der Kommandozeile die SSH-Verbindung zu einem Server aufzubauen, der sucht vielleicht ein grafisches Programm, um Verbindungsdaten zu verwalten.* [https://wiki.ubuntuusers.de/PuTTY/ PuTTY] - gibt es sowohl für Linux als auch für Windows. Das Programm ist in den offiziellen Paketquellen enthalten.
| | {| class="wikitable sortable options" |
| * [http://sourceforge.net/projects/pacmanager PAC Manager] - ('''Perl''' '''A'''uto '''C'''onnector) nicht in den offiziellen Paketquellen enthalten, aber über SourceForge wird ein Fremdpaket angeboten, das manuell installiert werden kann.
| |
| * [http://sourceforge.net/projects/gnome-rdp Gnome-RDP] - mit diesem Programm kann man nicht nur [http://de.wikipedia.org/wiki/Remote_Desktop_Protocol RDP]- und [https://wiki.ubuntuusers.de/VNC/ VNC]-Verbindungen aufbauen, sondern auch SSH-Terminalsitzungen. Leider kann man in der aktuellen Version die Zugangspasswörter nicht speichern lassen und keine Angaben zum verwendeten Port machen. Es funktioniert somit nur mit Servern, die den Standard-SSH-Port <tt>22</tt> nutzen. In den offiziellen Paketquellen enthalten, benötigt aber [http://de.wikipedia.org/wiki/Mono-Projekt Mono] als Voraussetzung.
| |
| | |
| | |
| | |
| === .ssh/config ===
| |
| | |
| Wenn man sich auf der Konsole mit einem anderen Server verbinden möchte, muss man evtl. z.B. Port und Benutzernamen angeben. Um das Ganze zu vereinfachen, kann man Voreinstellungen für ssh in der config-Datei '''$HOME/.ssh/config''' hinterlegen. Hier ein Beispiel:
| |
| | |
| vergrößern
| |
| | |
| <nowiki># ssh (secure shell) configuration file</nowiki>
| |
| Host test1
| |
| HostName 123.456.789.0
| |
| Port 980
| |
| User MeinBenutzerName
| |
| | |
| Host test2
| |
| HostName test.mynet.local
| |
| User test
| |
| CheckHostIP no
| |
| Cipher blowfish
| |
| | |
| Host foobar
| |
| HostName domain.tld
| |
| Port 55550
| |
| User fanta
| |
| IdentityFile ~/.ssh/private_ssh_key_rsa
| |
| | |
| Nun braucht man nicht mehr
| |
| | |
| ssh MeinBenutzerName@123.456.789.0 -p980
| |
| | |
| zu schreiben, es reicht nun ein kurzes
| |
| | |
| ssh test1
| |
| | |
| für einen Verbindungsaufbau. Alle Parameter, die man verwenden kann, findet man unter [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh_config openbsd.org] oder in der [https://wiki.ubuntuusers.de/man/ Manpages] von '''ssh_config'''.
| |
| | |
| == Der SSH-Server ==
| |
| | |
| Im Gegensatz zum SSH-Klienten ist der SSH-Server unter Ubuntu standardmäßig nicht installiert. Er lässt sich über das Paket
| |
| | |
| '''openssh-server'''
| |
| | |
| mit [https://wiki.ubuntuusers.de/apturl/ apturl]
| |
| | |
| Paketliste zum Kopieren: '''apt-get''' aptitude
| |
| | |
| sudo apt-get install openssh-server
| |
| | |
| installieren [https://wiki.ubuntuusers.de/SSH/#source-1 [1]].
| |
| | |
| Die Konfiguration des SSH-Servers '''sshd''' findet über die Datei '''/etc/ssh/sshd_config''' statt. Die Voreinstellungen sind aber durchweg akzeptabel.
| |
| | |
| Wer den '''sshd''' auf einem Gateway oder Router betreibt oder aus einem anderen Grund mehrere Netzwerkschnittstellen verwendet (bspw. WLAN), der möchte dort vielleicht die '''ListenAddress'''-Direktive benutzen, um den Server nur an bestimmten Netzwerk-Schnittstellen laufen zu lassen.
| |
| | |
| Außerdem kann es sinnvoll sein, '''PermitRootLogin''' auf '''no''' zu setzen. Dann kann sich niemand direkt als ''root'' einloggen, sondern man meldet sich unter seinem Benutzernamen an und ruft dann '''su''' oder '''sudo -s''' auf. Dies ist aber unter Ubuntu nur relevant, sollte man dem "root"-Benutzerkonto ein Passwort zugewiesen haben.
| |
| | |
| Mit den Direktiven '''AllowUsers''' und '''AllowGroups''' bzw. '''DenyUsers''' und '''DenyGroups''' lässt sich noch genauer festlegen, welche Benutzer sich anmelden dürfen und welche nicht. Dies empfiehlt sich besonders bei Servern. '''AllowGroups admin''' verbietet bspw. allen Benutzern, die keine Mitglieder der Gruppe ''admin'' sind, den Zugriff.
| |
| | |
| Wer sich ausschließlich über das noch sicherere [https://wiki.ubuntuusers.de/SSH/#Authentifizierung-ueber-Public-Keys Public-Key-Verfahren] anmelden will, der sollte die Benutzung von Passwörtern mit '''PasswordAuthentication no''' abschalten.
| |
| | |
| Falls lange Wartezeiten bei der Anmeldung am SSH-Server auftreten, könnte das an einer fehlgeschlagenen Namensauflösung liegen. Da man SSH normalerweise sowieso über die IP benutzt, können diese DNS-Anfragen in der '''sshd_config''' deaktiviert werden. Der dafür nötige Eintrag wäre '''UseDNS no'''.
| |
| | |
| Nach erfolgter Änderung der Datei '''sshd_config''' muss der Server mit dem Befehl:
| |
| | |
| sudo reload ssh
| |
| | |
| neugestartet werden, damit die Änderungen wirksam werden.
| |
| | |
| '''Hinweis'''
| |
| | |
| Standardmäßig wird der SSH-Server beim Booten geladen. Ab [https://wiki.ubuntuusers.de/Lucid_Lynx/ Ubuntu 10.04] ist Upstart für den Autostart des SSH-Servers zuständig. Wie man den Autostart deaktiviert, wird im [https://wiki.ubuntuusers.de/Upstart/#Deaktivieren-von-Init-Jobs Upstart-Artikel] beschrieben.
| |
| | |
| == 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- bzw. Hostnamen ergänzt werden. Dabei werden weggelassene Teile durch den aktuellen Benutzernamen, ''localhost'' bzw. das Homeverzeichnis (bzw. 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 [https://wiki.ubuntuusers.de/cp/ cp] 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
| |
| | |
| vergrößern
| |
| | |
| 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 [https://wiki.ubuntuusers.de/FUSE/sshfs/ sshfs] einbinden. Damit ist eine transparente Nutzung von Dateien auch über unsichere Netze hinweg möglich.
| |
| | |
| === Grafische Programme zum Dateitransfer ===
| |
| | |
| ==== Gnome/Ubuntu ====
| |
| | |
| Der Gnome-Dateimanager [https://wiki.ubuntuusers.de/Nautilus/ Nautilus] 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. 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. Dort lassen sich auch noch andere SSH-Einstellung, wie. z.B SSH-Keys, definieren. Der Zugriff erfolgt mit <tt>ssh://hostname</tt>. 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 [https://wiki.ubuntuusers.de/Konqueror/ Konqueror] sowie in allen KDE-Anwendungen.
| |
| | |
| Man kann also beispielsweise im Malprogramm [https://wiki.ubuntuusers.de/KolourPaint/ KolourPaint] 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 [https://wiki.ubuntuusers.de/Dolphin/ Dolphin] (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 u.U. 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 [https://wiki.ubuntuusers.de/Thunar/ Thunar] unterstützt das SSH-Protokoll wie Nautilus unter GNOME. Siehe [https://wiki.ubuntuusers.de/SSH/#Gnome-Ubuntu Gnome-Ubuntu].
| |
| | |
| ==== Weitere grafische Programme ====
| |
| | |
| Die meisten grafischen FTP-Clients ([https://wiki.ubuntuusers.de/FTP/ FTP]) unterstützen auch sftp oder scp über das SSH-Protokoll. Beim Gnome FTP-Cient [https://wiki.ubuntuusers.de/gFTP/ gFTP] 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 [https://wiki.ubuntuusers.de/SSH/#Authentifizierung-ueber-Public-Keys Public-Key-Verfahren]) 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 [https://wiki.ubuntuusers.de/Unison/ Unison] und Backupprogramme wie Keep.
| |
| | |
| == Authentifizierung über Public-Keys ==
| |
| | |
| Wem die Authentifizierung über Passwörter trotz der Verschlüsselung zu unsicher ist, - immerhin könnte das Passwort ja erraten werden - der benutzt am besten das Public-Key-Verfahren. Hierbei wird asymmetrische Verschlüsselung genutzt, um den Benutzer zu authentifizieren. Der (oder die) öffentliche(n) Schlüssel des Benutzers befindet sich dabei in der Datei '''~/.ssh/authorized_keys''' des Zielsystems, der private Schlüssel in einer Datei (meist '''id_rsa''') im Verzeichnis '''~/.ssh''' auf dem lokalen System, wo er zusätzlich von einer "pass phrase" geschützt wird. Wenn man sich nun mit der Public-Key-Methode auf einem SSH-Server anmelden möchte, so schickt der Server dem Klienten eine zufällig generierte ''Challenge''. Der Klient verschlüsselt diesen Datenblock mit seinem privaten Schlüssel, (wofür nötigenfalls die Passphrase abgefragt wird,) und wenn der Server diesen Chiffre mit dem zugehörigen öffentlichen Schlüssel wieder entschlüsseln kann, ist die Identität des Benutzers bestätigt.
| |
| | |
| Damit man dieses Verfahren überhaupt verwenden kann, muss man sich zunächst mit Hilfe des Kommandozeilenprogramms <tt>ssh-keygen</tt> ein entsprechendes Schlüsselpaar erzeugen:
| |
| | |
| ssh-keygen -t rsa -b 4096
| |
| | |
| vergrößern
| |
| | |
| Generating public/private rsa key pair.
| |
| Enter file in which to save the key (/home/user/.ssh/id_rsa):
| |
| Enter passphrase (empty for no passphrase):
| |
| Enter same passphrase again:
| |
| Your identification has been saved in /home/user/.ssh/id_rsa.
| |
| Your public key has been saved in /home/user/.ssh/id_rsa.pub.
| |
| The key fingerprint is:
| |
| 24:55:ee:67:83:72:82:55:5f:b9:b4:09:2a:fa:56:a1 user@client.local
| |
| The key's randomart image is:
| |
| +--[ RSA 4096]----+
| |
| | |
| |
| | |
| |
| | |
| |
| | + . |
| |
| | S E |
| |
| | . + + |
| |
| | .o . o.|
| |
| | o.oo. oo|
| |
| | <nowiki>==o.BO+|</nowiki>
| |
| +-----------------+
| |
| | |
| Der voreingestellte Dateiname ('''id_rsa''') kann einfach mit der Taste ⏎ bestätigt werden, außer man möchte sich ein weiteres Schlüsselpaar erzeugen. Von der Benutzung einer leeren Passphrase ist jedoch abzuraten, weil sonst jeder, der evtl. in den Besitz dieser Datei kommt, sofortigen Zugriff auf alle zugehörigen Systeme erhält.
| |
| | |
| Nun muss noch der öffentliche Schlüssel, zu erkennen an der Endung ''.pub'' ('''id_rsa.pub'''), auf dem Zielsystem deponiert werden. Dazu dient das Programm '''ssh-copy-id'''. Zu diesem Zeitpunkt muss die Authentifizierung per Passwort noch erlaubt sein ('''PasswordAuthentication yes'''):
| |
| | |
| ssh-copy-id -i ~/.ssh/id_rsa.pub user@server
| |
| Password:
| |
| Now try logging into the machine, with "ssh 'user@server'", and check in:
| |
| .ssh/authorized_keys
| |
| to make sure we haven't added extra keys that you weren't expecting.
| |
| | |
| '''Hinweis'''
| |
| | |
| Sollte man - warum auch immer - bei der Angabe des Dateinamens des Schlüssels die Endung '''.pub''' vergessen, so wird diese automatisch durch <tt>ssh-copy-id</tt> angehängt. Man kann also nie aus Versehen seinen privaten Schlüssel Namens '''id_rsa''' (also ohne Endung '''.pub''') übertragen.
| |
| | |
| Sollte '''ssh-copy-id''' nicht funktionieren, kann man den öffentlichen Schlüssel auch anders auf das Zielsystem kopieren und in die Datei '''~/.ssh/authorized_keys''' einfügen. Dabei ist unbedingt darauf zu achten, dass die Datei mit der Endung '''.pub''' und nicht der private Schlüssel ohne diese Endung verwendet wird:
| |
| | |
| cat id_rsa.pub | ssh server 'cat>> ~/.ssh/authorized_keys'
| |
| | |
| Wenn ein vom Standard abweichender Dateiname für den Key gewählt wurde, muss er mittels der Kommandozeilenoption <tt>-i ~/pfad/dateiname</tt> gesondert angegeben werden. Für die dauerhafte Nutzung empfiehlt sich ein Eintrag in der [https://wiki.ubuntuusers.de/ssh/#ssh-config ~/.ssh/config] mittels <tt>IdentityFile</tt>-Parameter.
| |
| | |
| '''Hinweis'''
| |
| | |
| Bei [https://wiki.ubuntuusers.de/Precise/ Ubuntu 12.04] sollten die [https://wiki.ubuntuusers.de/Rechte/ Rechte] der Datei '''~/.ssh/authorized_keys''' sowie des Ordners '''~/.ssh''' auf dem Server noch restriktiver gesetzt werden, falls diese neu erzeugt wurden und daher nur mit Standardrechten ausgestattet sind:
| |
| | |
| chmod 700 /home/BENUTZERNAME/.ssh
| |
| chmod 600 /home/BENUTZERNAME/.ssh/authorized_keys
| |
| | |
| Anschließend kann man sich ohne Passwort anmelden:
| |
| | |
| ssh user@server
| |
| Enter passphrase for key '/home/user/.ssh/id_rsa':
| |
| Linux server.local 2.6.12-10-686 #1 Mon Feb 13 12:18:37 UTC 2006 i686 GNU/Linux
| |
| The programs included with the Ubuntu system are free software;
| |
| the exact distribution terms for each program are described in the
| |
| individual files in /usr/share/doc/*/copyright.
| |
| Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
| |
| applicable law.
| |
| Last login: Fri Mar 3 03:51:14 2006
| |
| | |
| In einigen Fällen tritt ein Fehler beim ersten Anmeldeversuch auf:
| |
| | |
| <div style="margin-left:1cm;margin-right:1cm;">''"Agent admitted failure to sign using the key."''</div>
| |
| | |
| In diesem Fall einfach '''ssh-add''' ausführen.
| |
| | |
| ssh-add
| |
| Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa)
| |
| | |
| '''Hinweis'''
| |
| | |
| Falls es noch nicht klappt kann es daran liegen, dass die Rechte beim Server nicht korrekt sind. sshd achtet darauf, dass das Homeverzeichnis, das dem Login-Namen entspricht (also die "Mappe" selbst), das <tt>.ssh</tt>-Verzeichnis und <tt>authorized_keys</tt> nur für den Eigentümer Schreibrechte hat. Hintergrund ist wohl, die Gefahr zu verringern, dass <tt>authorized_keys</tt> manipuliert wird und man keinen Zugriff mehr hat, wenn der Passwortzugang (s.u.) gesperrt ist.
| |
| | |
| Wer also bei bestimmten Konten auf dem Server auch einer Gruppe Schreibrechte gewähren will, muss evtl. die Optionen in '''/etc/ssh/sshd_config''' prüfen.
| |
| | |
| Jetzt ist es aber immer noch möglich, sich mit dem Passwort anzumelden. Um dies zu unterbinden, sind in der Datei '''/etc/ssh/sshd_config''' die Optionen
| |
| | |
| PasswordAuthentication no
| |
| UsePAM no
| |
| | |
| zu setzen und mit einem
| |
| | |
| sudo /etc/init.d/ssh reload
| |
| | |
| die Konfiguration neu einlesen lassen.
| |
| | |
| Alternativ: Auf der Serverseite eingeben <tt>passwd -l <user></tt>. Damit sind Passwörter nur für ausgewählte Accounts sperrbar.
| |
| | |
| === Verschlüsseltes Home-Verzeichnis ===
| |
| | |
| Man sollte darauf achten, dass bei verschlüsselten Home-Verzeichnissen (ecryptfs) auch die <tt>authorized_keys</tt> mit verschlüsselt ist und somit nicht zur Authentifizierung verwendet werden kann, solange das Home-Verzeichnis nicht entschlüsselt ist (durch parallele Anmeldung mit dem gleichen Benutzernamen).
| |
| | |
| Eine Abhilfe ist z.B. die <tt>authorized_keys</tt> in ein nicht-verschlüsseltes Verzeichnis zu legen (z.B. /etc/ssh/username/) und die Einstellung ''AuthorizedKeysFile'' in der <tt>/etc/ssh/sshd_config</tt> auf ''/etc/ssh/%u/authorized_keys'' zu ändern (Root-Rechte und Neustart des SSH-Daemons erforderlich).
| |
| | |
| sudo mkdir /etc/ssh/$USER
| |
| sudo mv $HOME/.ssh/authorized_keys /etc/ssh/$USER/
| |
| ln -s /etc/ssh/$USER/authorized_keys $HOME/.ssh/
| |
| | |
| Quelle: [http://superuser.com/questions/61057/ssh-with-authorized-keys-to-an-ubuntu-system-with-encrypted-homedir SSH with authorized_keys to an Ubuntu system with encrypted homedir?]
| |
| | |
| === Der SSH-Agent ===
| |
| | |
| Unter grafischen Desktop-Sitzungen (Unity, Gnome, etc.) startet automatisch im Hintergrund der SSH-Agent. In diesem werden automatisch die privaten Schlüssel abgelegt, sodass nicht jedes Mal die "pass phrase" abgefragt wird. Dies verbindet die Bequemlichkeit der Bedienung mit der Sicherheit des Public-Key-Verfahrens.
| |
| | |
| Zur direkten Interaktion mit dem SSH-Agenten im Terminal dient das Programm <tt>ssh-add</tt>, wobei die Option <tt>-l</tt> die augenblicklich gespeicherten Schlüssel auflistet:
| |
| | |
| ssh-add -l
| |
| {{{
| |
| The agent has no identities.
| |
| ssh-add
| |
| Enter passphrase for /home/user/.ssh/id_rsa:
| |
| Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa)
| |
| ssh-add -l
| |
| 1024 24:55:ee:67:83:72:82:55:5f:b9:b4:09:2a:fa:56:a1 /home/user/.ssh/id_rsa (RSA)
| |
| ssh server
| |
| Last login: Wed Mar 8 11:11:58 2006 from 192.168.4.56
| |
| | |
| Wenn man nicht über Unity oder eine andere graphische Benutzeroberfläche, die unter dem ssh-agent läuft, eingeloggt ist, funktioniert das so leider nicht. Dann muss man vorher noch ein
| |
| | |
| exec ssh-agent bash
| |
| | |
| ausführen, um eine Shell zu öffnen, die mit dem ssh-agent kommunizieren kann.
| |
| | |
| Arbeitet man oft im Terminal und möchte nicht immer wieder die "pass phrase" eingeben, kann man das folgende in seine '''.bashrc''' eintragen:
| |
| | |
| if [ $SSH_AGENT_PID ]; then
| |
| <nowiki>if [[ $(ssh-add -l) != *id_?sa* ]]; then</nowiki>
| |
| ssh-add -t 2h <nowiki>## Haltbarkeit von 2 Std.</nowiki>
| |
| fi
| |
| fi
| |
| | |
| === Login über mehrere Rechner ===
| |
| | |
| 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
| |
| | |
| === SSH-Askpass ===
| |
| | |
| Wenn eines der Pakete '''ssh-askpass''', '''ssh-askpass-gnome''', '''ssh-askpass-fullscreen''' oder '''gtk-led-askpass''' installiert ist, kann <tt>ssh-add</tt> die Passphrase in Ermangelung eines Terminals auch über ein Dialogfenster abfragen. Das nutzt man sinnvollerweise, um seinen Schlüssel gleich nach der Anmeldung auf einem grafischen System zu laden [https://wiki.ubuntuusers.de/SSH/#source-5 [5]]. Für KDE-Nutzer gibt es das Paket '''ksshaskpass''', das für ssh-add eine graphische Oberfläche zur Verfügung stellt.
| |
| | |
| === Single-Sign-On ===
| |
| | |
| Wem immer noch zu umständlich ist, beim Login nacheinander erst das Login-Passwort und dann die SSH-Passphrase einzugeben, der installiert sich stattdessen das Paket '''libpam-ssh'''.
| |
| | |
| Mit den richtigen Einstellungen wird man beim Login nach der Eingabe des Benutzernamens nicht mehr nach dem Passwort, sondern nach der SSH-Passphrase gefragt und kann sich danach ohne nervige Passwortabfrage mittels SSH auf seinen Systemen bewegen.
| |
| | |
| Nur wenn man die Passphrase nicht richtig eintippt, kann man sich stattdessen auch mit seinem normalen Passwort authentifizieren. Zu beachten ist allerdings, dass der [https://wiki.ubuntuusers.de/GNOME_Schlüsselbund/ GNOME-Schlüsselbund] dann nicht mehr automatisch freigeschaltet wird.
| |
| | |
| Macht man hier einen Fehler, kann man sich eventuell nicht mehr am System anmelden. Sollte das passiert sein, ist es normalerweise noch möglich, sich per SSH einzuloggen und den Fehler zu beheben. Wenn auch das nicht mehr hilft, muss man das System zum Reparieren im Single-User-[http://de.wikipedia.org/wiki/Runlevel Runlevel] oder von einer Live-CD starten.
| |
| | |
| == 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 <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 (z.B. 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 [https://wiki.ubuntuusers.de/Leafpad/ Leafpad]: ssh -X user@server leafpad & Zur bequemeren Nutzung entfernter Programme können auch die Panel-Programme der jeweiligen Desktop-Umgebung gestartet werden, z.B. [https://wiki.ubuntuusers.de/LXDE_Einstellungen/#Panel LXPanel], [https://wiki.ubuntuusers.de/Xfce_Panel/ Xfce Panel] und andere: ssh -X user@server lxpanel &
| |
| | |
| Da Panel-Programme in der Regel nicht über eine Funktion "schließen" verfügen kann man diese z.B. mittels [https://wiki.ubuntuusers.de/xkill/ xkill] 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><nowiki>#</nowiki></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> bzw. <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 '''<nowiki>*</nowiki>''' 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
| |
| | |
| | |
| | |
| | |
| | |
| = Secure Shell =
| |
| | |
| == Einführung ==
| |
| | |
| === Was ist Secure Shell ===
| |
| | |
| Secure Shell oder SSH meint sowohl ein Netzwerkprotokoll als auch entsprechende Programme, mit deren Hilfe man auf eine sichere Art und Weise eine verschlüsselte Netzwerkverbindung mit einem entfernten Gerät herstellen kann. Häufig wird diese Methode verwendet, um sich eine entfernte Kommandozeile quasi auf den lokalen Rechner zu holen, das heißt, auf der lokalen Konsole werden die Ausgaben der entfernten Konsole ausgegeben und die lokalen Tastatureingaben werden an den entfernten Rechner gesendet.
| |
| | |
| Hierdurch wird der Effekt erreicht, als säße man vor der entfernten Konsole, was beispielsweise sehr gut zur Fernwartung eines in einem entfernten Rechenzentrum stehenden Root-Servers genutzt werden kann.
| |
| | |
| [[Image:Grafik4.png|right]]Die neuere Protokoll-Version SSH-2 bietet weitere Funktionen wie Datenübertragung per SFTP. Die IANA hat dem Protokoll den TCP-Port 22 zugeordnet, jedoch lassen sich in den Konfigurationsdateien des Daemons auch beliebige andere Ports auswählen.
| |
| | |
| ==== Informationssicherheit ====
| |
| | |
| Secure Shell kann folgende Grundwerte sicherstellen* Vertraulichkeit
| |
| * Integrität
| |
| * Nichtabstreitbarkeit
| |
| | |
| | |
| | |
| ==== Arbeitsweise ====
| |
| | |
| Secure Shell öffnet eine durch Verschlüsselung gesicherte Verbindung, zu einem entfernten Rechner, die mit unterschiedlichen Protokollen und Einsatzszenarien genutzt werden kann. Sowohl Login-, als auch Nutzdaten werden verschlüsselt übertragen.
| |
| | |
| ==== Einsatzmöglichkeiten ====
| |
| | |
| | |
| {| style="border-spacing:0;margin:auto;width:17.501cm;"
| |
| |- style="border:none;padding:0cm;"
| |
| || * Entfernter Shell-Zugang
| |
| * Dateiübertragung
| |
| * Entfernte Befehlsausführung
| |
| | |
| | |
| || * Einbindung in Pipes
| |
| * Einbinden entfernter Dateisysteme
| |
| * Tunnelung beliebiger Netzwerkprotokolle
| |
| | |
| | |
| | |
| | |
| |-
| |
| |}
| |
| Secure Shell kann damit viele unsichere (unverschlüsselte) Anwendungen wie telnet, ftp, rlogin oder rcp ersetzen und unsichere Protokolle wie http, pop3 oder smb absichern.
| |
| | |
| Als sicherer Telnet-Ersatz bietet '''ssh''' drei wichtige Eigenschaften:* Authentifizierung der Gegenstelle
| |
| * Verschlüsselung der Datenübertragung und der Anmelde-Informationen
| |
| * Datenintegrität, also Schutz vor Manipulation der Übertragung
| |
| | |
| | |
| | |
| ==== Weitere Funktionen und Eigenschaften ====
| |
| | |
| * Open Source Project / Freie Software
| |
| * Starke Verschlüsselung (3DES, Blowfish, AES, Arcfour)
| |
| * X11 Forwarding (encrypt X Window System traffic)
| |
| * Strong Authentication (Public Key, One-Time Password and Kerberos Authentication)
| |
| * Agent Forwarding (Single-Sign-On)
| |
| * Interoperability (Compliance with SSH 1.3, 1.5, and 2.0 protocol Standards)
| |
| * Kerberos and AFS Ticket Passing
| |
| * Data Compression
| |
| | |
| | |
| | |
| ==== Ursprung und Entwicklung ====
| |
| | |
| [[Image:.png|thumb|right|Tatu Ylönen]]Mit dem Befehl <tt>telnet</tt> kann man sich über das Netzwerk bei anderen Systemen anmelden, die den ''Telnet-Daemon'' installiert hatten, vorausgesetzt, man kenn das Passwort.
| |
| | |
| Leider bietet das Protokoll keine Verschlüsselung, so dass das Mitschneiden von Passwörtern und Daten eine triviale Angelegenheit ist.
| |
| | |
| Um solche Verbindungen abzusichern, erstellte der Finne Tatu Ylönen in den frühen Neunzigern des vorigen Jahrhunderts eine Programmsuite – bestehend aus einem Server, einem Client und mehreren Hilfsprogrammen – die er '''ssh''' (''secure shell'') nannte.
| |
| | |
| Das SSH-Protokoll, das er veröffentlichte, bot eine komplett verschlüsselte Alternative zu ''Telnet'' und noch vieles mehr und wurde ein voller Erfolg.
| |
| | |
| Als er später die Firma ''ssh.com'' gründete und die Version 2 der SSH-Suite nur noch unter einer kommerziellen Lizenz anbot, nahmen sich die Entwickler des Betriebssystems OpenBSD des Quellcodes von '''ssh1''' an und entwickelten das Programm bis zum heutigen Tage unter dem Namen '''OpenSSH''' weiter.
| |
| | |
| Die OpenSSH-Suite ist Bestandteil vieler Unix-Derivate und nahezu jeder Linux-Distribution.
| |
| | |
| Auch wenn es inzwischen Erweiterungen für Telnet gibt, die bspw. ''SSL-Verschlüsselung'' oder ''Kerberos-Authentifizierung'' bieten, wurde der Telnet-Server fast komplett von SSH verdrängt und ist nicht mehr verbreitet
| |
| | |
| == Grundlagen ==
| |
| | |
| === OpenSSH ===
| |
| | |
| [[Image:Grafik1.png|right]]OpenSSH ist eine FREIE Version der SSH-Verbindungssuite, auf die sich technische Nutzer des Internets verlassen. Benutzer von telnet, rlogin, ftp und ähnlichen Programmen mögen es nicht wissen, dass ihr Passwort unverschlüsselt über das Internet übertragen wird. So ist es jedoch! OpenSSH verschlüsselt den gesamten Datenverkehr (inklusive der Passwörter), um das Mithören (»eavesdropping«), das Einschleichen in Verbindungen (»connection hijacking«) und ähnliche Angriffe effektiv zu unterbinden. Zusätzlich bietet OpenSSH die Möglichkeit zur Erzeugung sicherer Tunnelverbindungen, verschiedene Authentifizierungsmethoden und unterstützt sämtliche Protokollversionen von SSH.
| |
| | |
| Die OpenSSH-Suite ersetzt rlogin und telnet mit dem Programm [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh&sektion=1 ssh], rcp mit [http://www.openbsd.org/cgi-bin/man.cgi?query=scp&sektion=1 scp] und ftp mit [http://www.openbsd.org/cgi-bin/man.cgi?query=sftp&sektion=1 sftp]. Außerdem sind der Server [http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8 sshd] und andere Werkzeuge wie [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-add&sektion=1 ssh-add], [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-agent&sektion=1 ssh-agent], [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-keysign&sektion=8 ssh-keysign], [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-keyscan&sektion=1 ssh-keyscan], [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-keygen&sektion=1 ssh-keygen] und [http://www.openbsd.org/cgi-bin/man.cgi?query=sftp-server&sektion=8 sftp-server] enthalten.
| |
| | |
| OpenSSH wird vom [http://www.openbsd.org/de/ OpenBSD-Projekt] entwickelt. Die Software wird in Ländern entwickelt, die den Export von Kryptographie erlauben, und ist somit für jeden unter der BSD-Lizenz frei nutz- und wiederverwendbar. Die Entwicklung jedoch verursacht Kosten. Solltest du also OpenSSH als nützlich empfinden (insbesondere, wenn du es in einem kommerziellen System einsetzt, das verkauft wird), so denke bitte über eine [http://openssh.org/de/donations.html Spende nach, um das Projekt finanziell zu unterstützen].
| |
| | |
| OpenSSH wird von zwei Teams entwickelt. Ein Team führt ausschließlich OpenBSD-basierte Entwicklung durch. Das Ziel dahinter ist, einen Quelltext zu schaffen, der so sauber, einfach und sicher wie möglich ist. Wir glauben, dass die Einfachheit ohne das ganze, für die Portabilität notwendige »Drumherum«, bessere Codequalität ermöglicht. Das andere Team nimmt dann diesen sauberen Quelltext als Basis und macht ihn portabel (fügt also das »Drumherum« hinzu), sodass der Code auf vielen Betriebssystemen ausgeführt werden kann. Das sind dann die so genannten '''-p'''-Releases, zum Beispiel »OpenSSH 4.0p1«.
| |
| | |
| Ein exzellentes Buch zum Erlernen von OpenSSH wurde geschrieben, betitelt [https://www.michaelwlucas.com/nonfiction/ssh-mastery SSH Mastery]. Wir empfehlen die Bestellung über die [https://https.openbsd.org/cgi-bin/order?B09=1&B09%2B=Add OpenBSD Bestellseite], da dies OpenSSH ein wenig weiter hilft.
| |
| | |
| Wir möchten auch auf unsere Seite [http://openssh.org/de/users.html Wer setzt OpenSSH ein] hinweisen, auf der jene Hersteller gelistet werden, die OpenSSH in ihren eigenen Produkten - als eine sicherheitskritische Schlüsselkomponente - einsetzen, statt ihre eigene SSH-Implementation zu schreiben oder die Implementierung eines anderen Herstellers zu kaufen. Diese Liste beinhaltet insbesondere Firmen wie Cisco, Juniper, Apple, Red Hat und Novell; aber möglicherweise gehören dazu auch alle Router- oder Switchhersteller sowie Entwickler von Unix-artigen Betriebssystemen. In den 10 Jahren, in denen das OpenSSH-Projekt besteht, haben diese Firmen nicht einen einzigen Euro aus Dankbarkeit beigetragen, um das OpenSSH-Projekt zu unterstützen (lediglich unzählige Anfragen).
| |
| | |
| ==== Projektziele ====
| |
| | |
| Unser Ziel ist einfach: Weil telnet und rlogin unsicher sind, sollten alle Betriebssysteme mit SSH-Unterstützung ausgeliefert werden (siehe Bild unten).
| |
| | |
| Das SSH-Protokoll gibt es in zwei inkompatiblen Varianten: SSH 1 und SSH 2.
| |
| | |
| Das ältere SSH-1-Protokoll teilt sich wieder in zwei Hauptvarianten auf: Protokoll 1.3 und Protokoll 1.5. Beide werden von OpenSSH unterstützt, verwenden für die Schlüsselübertragung den asymmetrischen Kryptographiealgorithmus [http://www.openbsd.org/cgi-bin/man.cgi?query=rsa RSA] (dessen USA-Patent abgelaufen ist und somit für jedermann frei zur Verfügung steht) und greifen dann auf ein paar symmetrische Algorithmen zurück, um die Daten zu verstecken: [http://www.openbsd.org/cgi-bin/man.cgi?query=des_crypt 3DES] und [http://www.openbsd.org/cgi-bin/man.cgi?query=blowfish Blowfish] (es gab ein paar andere Algorithmen, wie z. B. RC4, doch hätte ihre Implementation zu Sicherheitsproblemen geführt). Einige SSH-1-Protokollimplementationen unterstützen außerdem den symmetrischen IDEA-Algorithmus. OpenSSH hat aber keine Unterstützung für IDEA, weil dieser Algorithmus in einigen Nationen patentiert ist und die anderen beiden völlig ausreichend sind.
| |
| | |
| Das SSH-1-Protokoll benutzt ein einfaches CRC, um die Datenintegrität sicherzustellen, was sich aber als fehlerhaft herausstellte - ein Insertionangriff ist bekanntermaßen möglich. Angriffe sind aber wegen den vielen Heftpflastern, die über die Jahre auf SSH aufgeklebt wurden, überaus schwierig durchzuführen. Wird der 3DES-Cipher benutzt, ist der Insertionangriff bedeutend schwieriger auszuführen (wir lösen das Problem wahrscheinlich bald).
| |
| | |
| Die zweite Hauptvariante von SSH ist das SSH-2-Protokoll. SSH 2 wurde eingeführt, um die patentrechtlichen Schwierigkeiten bezüglich des RSA-Protokolls zu umgehen (was inzwischen nicht mehr nötig ist, da das Patent abgelaufen ist), das CRC-Datenintegritätsproblem von SSH 1 zu lösen und aus einer Reihe weiterer technischer Gründe. Durch die Benutzung der asymmetrischen Algorithmen [http://www.openbsd.org/cgi-bin/man.cgi?query=dsa DSA] und [http://www.openbsd.org/cgi-bin/man.cgi?query=dh DH] vermeidet Protokoll 2 alle Patente. Das CRC-Problem wird durch die Benutzung eines richtigen [http://www.openbsd.org/cgi-bin/man.cgi?query=HMAC HMAC]-Algorithmus gelöst. Neben vielen neuen symmetrischen Ciphern unterstützt das SSH-2-Protokoll auch viele neue Funktionen.
| |
| | |
| Seit dem 1. Dezember 1999 beinhaltet der OpenSSH-Quelltext volle Unterstützung für die Protokolle 1.3 und 1.5.
| |
| | |
| Für viele Kryptographiefunktionen greift OpenSSH auf die nicht unter der GPL stehende [http://www.openssl.org/ OpenSSL]-Bibliothek zurück.
| |
| | |
| Fast sofort nachdem wir unsere Implementation des SSH-1-Protokolls veröffentlicht hatten, zeigten verschiedene Gruppen außerhalb von OpenBSD sehr, sehr großes Interesse daran. Damien Miller, Philip Hands und eine handvoll Anderer fingen an, OpenSSH auf Linux und verschiedene andere Unix-Betriebssysteme zu portieren. Von Anfang an unserer Bemühungen hatten wir das Gefühl, dass sogar der originale SSH-Code zu kompliziert war - er hatte einfach zu viele Betriebssystemabhängigkeiten in sich. Unser Anspruch, komplett sicheren und absolut stabilen Code zu schreiben, verhindert es natürlich, sich mit solchen übermäßigen Unterschieden herumzuschlagen. Um daher den gesamten Entwicklungsprozess für uns alle einfacher zu machen, haben wir die Kernentwicklung von der Portabilität getrennt. Das hat für uns sehr gut funktioniert (vergleiche doch mal die Anzahl der Zeilen zwischen der Basisversion und den portablen Versionen).
| |
| | |
| Diesen Trend fortführend haben Mitglieder des Projektteams von OpenBSD, die an OpenSSH gearbeitet haben, sich stark bemüht, das SSH-2-Protokoll ebenfalls zu unterstützen. Diese Arbeit wurde primär von Markus Friedl gemacht. Um den 4. Mai 2000 herum wurde das SSH-2-Protokoll so weit unterstützt, dass es von da an nutzbar war.
| |
| | |
| ==== Funktionalität ====
| |
| | |
| OpenSSH ist eine freie SSH/SecSH-Protokollsuite, die Verschlüsselung für Netzwerkdienste bereitstellt, wie etwa Remotelogins, also Einloggen auf einem anderen, entfernten Rechner, oder auch Dateiübertragung von oder zu einem entfernten Rechner.
| |
| | |
| Es folgt eine Liste der Fähigkeiten von OpenSSH: * Open-Source-Projekt
| |
| * Freie Lizenzpolitik
| |
| * Starke Verschlüsselung (3DES, Blowfish, AES, Arcfour)
| |
| * X11-Weiterleitung (verschlüsselt X-Window-System-Netzwerkverkehr)
| |
| * Portweiterleitung (verschlüsselte Kanäle für bestimmte Protokolle)
| |
| * Starke Authentifizierung (Öffentliche Schlüssel, Einmal-Passwort- und Kerberos-Authentifizierung)
| |
| * Agentweiterleitung (Single-Sign-On)
| |
| * Interoperabilität (arbeitet kompatibel zu den SSH-Protokollstandards 1.3, 1.5 und 2.0)
| |
| * SFTP-Client- und -Serverunterstützung sowohl im SSH1- als auch im SSH2-Protokoll.
| |
| * Kerberos- und AFS-Ticketpassing
| |
| * Datenkompression
| |
| | |
| | |
| | |
| ===== Open-Source-Projekt =====
| |
| | |
| Der OpenSSH-Quelltext ist für jeden frei über das Internet erhältlich. Das ermutigt zur Wiederverwendung und weiteren Untersuchung des Quelltextes. Diese weitere Untersuchung stellt sicher, dass Fehler von jedem gefunden und korrigiert werden können. Das führt zu sicherem Code.
| |
| | |
| ====== Freie Lizenzpolitik ======
| |
| | |
| OpenSSH wird nicht von einer restriktiven Lizenz eingeschränkt. Es kann für jeglichen Zweck eingesetzt werden und das schließt auch jegliche kommerzielle Nutzung ein. [http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/LICENCE?rev=HEAD Die Lizenz] für OpenSSH ist selbstverständlich der Distribution beigefügt. Wir sind der Meinung, dass die Welt besser wäre, wenn Router, Netzwerkgeräte, Betriebssysteme und alle anderen Netzwerkkomponenten ssh integriert hätten.
| |
| | |
| Alle Komponenten restriktiver Natur (z. B. Patente, siehe [http://www.openbsd.org/cgi-bin/man.cgi?query=ssl&sektion=8 ssl]) wurden aus dem Quellcode entfernt: Jegliche lizenzierten oder patentierten Teile werden aus externen Quellen bezogen (z. B. [http://www.openssl.org/ OpenSSL]). Die symmetrische Chiffre IDEA ist nicht mehr verfügbar, da sie in vielen Ländern patentiert ist. Stattdessen empfehlen wir die Benutzung einer der anderen verfügbaren Chiffren. (Wir sehen keine Rechtfertigung für die Benutzung einer patentierten symmetrischen Chiffre, zumal es so viele andere freie gibt).
| |
| | |
| ====== Was ist mit Copyrights, Benutzung und Patenten? ======
| |
| | |
| Die OpenSSH Entwickler haben sehr hart versucht, OpenSSH frei von Patent- oder Copyrightproblemen zu halten. Dazu mussten einige Optionen aus OpenSSH entfernt werden. Nämlich die Unterstützung für patentierte Algorithmen.
| |
| | |
| OpenSSH unterstützt keinerlei patentierte Transportalgorithmen. Im SSH1-Modus sind nur 3DES und Blowfish möglich. Im SSH2-Modus können nur 3DES, Blowfish, CAST128, Arcfour und AES ausgewählt werden. Der patentierte IDEA-Algorithmus wird nicht unterstützt.
| |
| | |
| OpenSSH bietet Unterstützung für sowohl das SSH1- als auch das SSH2-Protokoll.
| |
| | |
| Seit das RSA-Patent ausgelaufen ist, gibt es keinerlei Beschränkungen mehr für Software, die den RSA-Algorithmus benutzen, inklusive OpenBSD.
| |
| | |
| ===== Starke Verschlüsselung =====
| |
| | |
| OpenSSH unterstützt 3DES, Blowfish, AES und Arcfour als Verschlüsselungsalgorithmen. Sie sind patentfrei. Triple DES ist ein sehr gut verstandener Chiffrieralgorithmus, der den Zahn der Zeit überstanden hat und eine starke Verschlüsselung bereitstellt.
| |
| | |
| Blowfish ist ein schneller Blockchiffrierer, der von Bruce Schneier entworfen wurde und von Leuten benutzt werden kann, die eine schnellere Verschlüsselung benötigen.
| |
| | |
| [http://www.nist.gov/aes AES] ist der verbesserte Verschlüsselungsstandard des US Federal Information Processing Standard (FIPS), der als Ersatz für DES entwickelt wurde. Dabei handelt es sich um eine Blockchiffre.
| |
| | |
| Arcfour ist eine schnelle Stromchiffre. Sie wird als kompatibel zu RC4[TM] angesehen, einer proprietären Chiffre von RSA Security Inc.
| |
| | |
| Die Verschlüsselung beginnt vor der Authentifizierung und es werden keine Passwörter oder andere Daten im Klartext übermittelt. Verschlüsselung wird auch benutzt, um sich gegen sogenannte Spoof-Angriffe zu verteidigen, bei denen sich eine Person als jemand anderes ausgibt.
| |
| | |
| ===== X11-Weiterleitung =====
| |
| | |
| X11-Weiterleitung erlaubt die Verschlüsselung von X-Windows-Netzwerkverkehr, also Netzwerkübertragung, auf eine Weise, die niemanden den Datenverkehr mitlesen oder bösartige Kommandos einschleusen lässt. Das Programm setzt DISPLAY automatisch auf dem Server und leitet jegliche X11-Verbindung über den sicheren Tunnel weiter. Gefälschte Xauthority-Informationen werden automatisch generiert und an die entfernte Maschine weitergeleitet; der lokale Client untersucht automatisch ankommende X11-Verbindungen und ersetzt die gefälschten Authorisierungsdaten mit den echten Daten (und gibt der entfernten Maschine nie die echten Informationen).
| |
| | |
| ===== Port-Weiterleitung =====
| |
| | |
| Port-Weiterleitung erlaubt die Weiterleitung von TCP/IP-Verbindungen zu einer entfernten Maschine über ein verschlüsseltes Protokoll. Standard-Internetapplikationen wie POP können damit sicherer gemacht werden.
| |
| | |
| ===== Starke Authentifizierung =====
| |
| | |
| Starke Authentifizierung schützt gegen verschiedene Sicherheitsprobleme, z. B. IP-Spoofing, gefälschte Routen, und DNS-Spoofing. Die Authentifizierungsmethoden sind: .rhosts zusammen mit RSA-basierter Hostauthentifizierung, pure RSA-Authentifizierung, Einmal-Passwörter mit s/key und letztlich Authentifizierung mittels [http://www.openbsd.org/cgi-bin/man.cgi?query=kerberos&sektion=8 Kerberos].
| |
| | |
| ===== Agentweiterleitung =====
| |
| | |
| Ein Authentifizierungsagent, der auf dem Laptop oder der lokalen Maschine des Anwenders läuft, kann benutzt werden, um den RSA- oder DSA-Authentifizierungsschlüssel des Anwenders bereitzuhalten. OpenSSH leitet die Verbindung automatisch an den Authentifizierungsagenten über jede Verbindung weiter, und es gibt keine Notwendigkeit, die RSA-Authentifizierungsschlüssel auf jeder Maschine im Netzwerk zu haben (mit Ausnahme der lokalen Maschine des Benutzers). Die Authentifizierungsprotokolle geben die Schlüssel niemals preis; sie können nur dazu benutzt werden, um abzufragen, ob der Benutzer einen entsprechenden Schlüssel hat. Eventuell könnte der Agent auf einer Smart-Card beruhen, die alle Authentifizierungsberechnungen macht.
| |
| | |
| ===== Interoperabilität =====
| |
| | |
| OpenSSH-Versionen vor 2.0 unterstützen die SSH-1.3- und -1.5-Protokolle, die es erlauben, mit den meisten Unix-, Windows- und anderen, kommerziellen SSH-Implementationen zu kommunizieren.
| |
| | |
| Seit der Version 2.0 unterstützt OpenSSH neben den SSH-Protokollversionen 1.3 und 1.5 auch die SSH-Protokollversion 2.0. Dieses Protokoll vermeidet die Benutzung des RSA-Algorithmus - da zur Zeit der Einführung des Protokolls 2.0 das RSA-Patent noch gültig war - und benutzt stattdessen die frei benutzbaren DH- und DSA-Algorithmen.
| |
| | |
| Daher gibt dir OpenSSH das Beste aus beiden Welten. Du kannst mit '''beiden''' Typen von SSH-Clients und -Servern arbeiten und kommunizieren!
| |
| | |
| ===== SFTP-Client- und -Serverunterstützung in sowohl dem SSH1- als auch dem SSH2-Protokoll =====
| |
| | |
| Seit OpenSSH 2.5.0 ist komplette SFTP-Unterstützung integriert; dazu wird das [http://www.openbsd.org/cgi-bin/man.cgi?query=sftp&sektion=1 sftp(1)]-Kommando als Client benutzt. Das [http://www.openbsd.org/cgi-bin/man.cgi?query=sftp-server&sektion=8 sftp-server(8)]-Subsystem arbeitet automatisch mit sowohl dem SSH1- als auch dem SSH2-Protokoll.
| |
| | |
| ===== Kerberos- und AFS-Ticketpassing =====
| |
| | |
| OpenSSH gibt auch Tickets für Kerberos und AFS an die entfernte Maschine weiter. Ein Benutzer kann daher auf alle seine Kerberos- und AFS-Dienste zugreifen, ohne sein Passwort wieder eintippen zu müssen.
| |
| | |
| ===== Datenkompression =====
| |
| | |
| Datenkompression vor der Verschlüsselung beschleunigt die Leistung über langsame Netzwerkverbindungen.
| |
| | |
| ==== Warum sollte SSH eingesetzt werden? ====
| |
| | |
| OpenSSH ist eine Sammlung von Werkzeugen, die dir hilft, deine Netzwerkverbindungen sicherer zu machen. Hier ist eine Liste der Funktionalitäten: * Starke Authentifikation. Schließt verschiedene Sicherheitslöcher (z. B. IP-, ,routing'-, und DNS-,spoofing').
| |
| * Verbesserte Privatsphäre. Alle Verbindungen werden automatisch und transparent verschlüsselt.
| |
| * Sichere X11-Sitzungen. Das Programm setzt DISPLAY auf der Servermaschine automatisch und leitet alle X11-Verbindungen über den sicheren Kanal weiter.
| |
| * Willkürliche TCP/IP-Ports können durch den verschlüsselten Kanal in beide Richtungen gelenkt werden (z. B. für e-cash-Transaktionen).
| |
| * Für normale Benutzer wird keine Schulung und kein Training benötigt.
| |
| * Vertraut nie dem Netzwerk. Minimales Vertrauen auf der Gegenseite der Verbindung. Minimales Vertrauen gegenüber den Domain Name Servern. Pure RSA-Authentifikation vertraut nichts und niemandem, bis auf den ,private key'.
| |
| * Der Client authentifiziert die Servermaschine am Beginn jeder Verbindung mit RSA, um ,trojanischen Pferden' (durch ,routing'- oder DNS-,spoofing') und ,man-in-the-middle'-Angriffen vorzubeugen, und der Server tut das Gleiche mit der Clientmaschine bevor er .rhosts- oder /etc/hosts.equiv-Authentifikation erlaubt (um DNS-, ,routing'- oder IP-,spoofing' vorzubeugen).
| |
| * Die ,host authentication key'-Distribution kann zentral laufen, wird jedoch automatisch, sobald die erste Verbindung zur Maschine geöffnet wird.
| |
| * Jeder Benutzer kann beliebig viele RSA-Authentifikationsschlüssel zur eigenen Verwendung erzeugen.
| |
| * Das Serverprogramm hat seinen eigenen RSA-Schlüssel, der jede Stunde automatisch neu erzeugt wird.
| |
| * Ein Authentifikationsagent, der auf dem Laptop oder der Workstation des Benutzers läuft, kann benutzt werden, um die RSA-Authentifikationsschlüssel des Anwenders zu halten.
| |
| * Die Software kann auch ohne root-Privilegien installiert und benutzt werden (mit eingeschränkter Funktionalität).
| |
| * Der Client ist in systemweiten und benutzerspezifischen Konfigurationsdateien anpassbar.
| |
| * Optionale Kompression aller Daten mittels gzip (inklusive ,forwarded X11'- und TCP/IP-Daten), was zu bedeutenden Beschleunigungen auf langsamen Verbindungen führen kann.
| |
| * Kompletter Ersatz für rlogin, rsh und rcp.
| |
| | |
| | |
| | |
| Zurzeit werden fast alle Übertragungen in Computernetzwerken unverschlüsselt durchgeführt. Als Konsequenz kann jeder, der Zugriff auf irgendeine Maschine in diesem Netzwerk hat, alle Verbindungen abhören. Das wird auch von Hackern, neugierigen Administratoren, Arbeitgebern, Kriminellen, Industriespionen und Regierungen so durchgeführt. Einige Netzwerke senden derartig viel elektromagnetische Strahlung ab, dass Daten sogar in großer Entfernung noch aufgefangen werden können.
| |
| | |
| Wenn du dich einloggst, wird dein Passwort im Klartext übertragen. Daher kann dann jeder Lauscher deinen Account zu jeglicher Tat benutzen. Es gibt weltweit viele Zeugnisse dafür, dass Cracker auf dem Rechner eines Opfers unbemerkt ein Programm gestartet haben, welches ohne Wissen des Anwenders einfach nur das Netzwerk belauscht und Passwörter gesammelt hat. Programme, die das tun, gibt es im Internet oder können von einem kompetenten Programmierer innerhalb weniger Stunden selbst geschrieben werden.
| |
| | |
| Firmen haben Geschäftsgeheimnisse, Patentanträge in Vorbereitung, Preisinformationen, Informationen über Vertragspartner, Kundendaten, Personendaten, Finanzdaten etc. Zurzeit kann jeder mit Zugriff auf das Netzwerk (jede Maschine im Netzwerk) alles belauschen, was im Netzwerk vor sich geht, und das noch ohne die normalen Zugriffsbeschränkungen.
| |
| | |
| Vielen Firmen ist nicht bewusst, dass Informationen so einfach aus ihrem Netzwerk gesammelt werden können. Sie vertrauen darin, dass ihre Daten sicher sind, da niemand wissen kann, dass dort vertrauliche Informationen kursieren, oder auch, weil dort so viele andere Daten übertragen werden. Dies ist keine sichere Einstellung.
| |
| | |
| ==== Alternativen zu OpenSSH ====
| |
| | |
| Putty ist eine freie Implementierung eines ssh-Clients, welche im Gegensatz zu dem in OpenSSH enthaltenen Client eine grafische Benutzeroberfläche bietet. Purry Version ist verfügbar unter [http://www.chiark.greenend.org.uk/%7Esgtatham/putty/ http://www.chiark.greenend.org.uk/~sgtatham/putty/].
| |
| | |
| Dann gibt es noch einige kommerzielle SSH-Varianten, z.B. auf [http://www.ssh.com/ http://www.ssh.com] und [http://www.f-secure.com/ http://www.f-secure.com] Zusätzlich zu den Möglichkeiten von OpenSSH enthalten sie Programme zur zentralen Konfiguration von Servern, Schlüsseln und Tunnels.
| |
| | |
| ===== Unix-Alternativen =====
| |
| | |
| Wenn du unter Unix nicht OpenSSH benutzen willst, stehen die folgenden ,freien' SSH-Implementationen zur Zusammenarbeit mit OpenSSH zur Verfügung:* [ftp://ftp.pdc.kth.se/pub/krypto/ossh/ OSSH] ist eine Nur-SSH1-Implementation. BSD-Lizenz.
| |
| * Björn Grönvall war die eigentliche Person, die unsere Gemeinschaft daran erinnert hat, dass sehr alte Versionen von ssh eine freie Lizenz hatten. Dies ist seine eigene Implementation und basiert auf dem alten Code von Tatu. OpenSSH basierte auf einer frühen Version von OSSH, aber OpenSSH fügte SSH2-Protokollunterstützung hinzu und erweiterte die Unterstützung des SSH1-Protokolls.
| |
| * [http://www.net.lut.ac.uk/psst/ LSH/psst] ist eine Nur-SSH2-Implementation von Niels Möller aus Schweden, GPL-Lizenz.
| |
| * "ssh benutzt kryptographische Techniken, um die Sicherheit von alltäglichen Zielen wie etwa Dateiübertragungen, ,remote logins' und ,remote Command execution' zu erhöhen. Es ist als sichere(re) Alternative zu telnet, ftp, rsh, rlogin und rexec gedacht - und braucht viel weniger Aufwand als Kerberos oder IPSEC momentan verlangen."
| |
| * [http://matt.ucc.asn.au/dropbear/dropbear.html Dropbear] ist eine kleine SSH2-nur-Serverimplementierung, die von Matt Johnston geschrieben wurde. Sie ist unter MIT-style Lizenz erhältlich.
| |
| | |
| | |
| | |
| ===== Windows =====
| |
| | |
| Die folgenden ,freien' SSH-Implementationen werden für die Zusammenarbeit von Windows-Maschinen mit OpenSSH empfohlen:* [http://www.chiark.greenend.org.uk/%7Esgtatham/putty/ PuTTY] ist eine SSH1+SSH2-Implementation. PSCP, ein [http://www.openbsd.org/cgi-bin/man.cgi?query=scp scp]-artiges Programm für Windows, ist auch verfügbar. PuTTY unterliegt der MIT-Lizenz (BSD-ähnlich). "PuTTY ist eine freie Implementation von Telnet und SSH für Win32-Plattformen, geschrieben und gepflegt hauptsächlich von Simon Tatham, der in Großbritannien lebt."
| |
| * [http://web.archive.org/web/20050702021104/http://www.zip.com.au/%7Eroca/ttssh.html TTSSH (SSH1)] ist eine Nur-SSH1-Implementation von Robert O'Callahan. "TTSSH ist ein freier SSH-Client für Windows. Er ist als Erweiterungs-DLL für Teraterm Pro implementiert. Teraterm Pro ist ein fantastischer freier Terminal-Emulator/Telnet-Client für Windows und sein Quellcode ist verfügbar. TTSSH fügt Teraterm Pro SSH-Fähigkeiten hinzu, ohne irgendwelche bestehenden Funktionen von Teraterm zu opfern. TTSSH kann ebenfalls frei heruntergeladen und benutzt werden und sein Quellcode ist ebenfalls mit freier Lizenz erhältlich. Weiterhin wurde TTSSH vollständig in Australien implementiert [...]." Eine alternative Variante von [http://ttssh2.sourceforge.jp/ UTF-8 TeraTerm Pro mit TTSSH2] ist ebenfalls erhältlich.
| |
| * [http://www.cygwin.com/ Cygwin (POSIX-Software als Aufsatz für Windows)] OpenSSH (Protokolle SSH1 und SSH2) mit Cygwin kann unter Windows mit Hilfe der [http://openssh.org/de/portable.html portablen Version von OpenSSH] laufen, welche entweder aus dem Quelltext übersetzt, oder als natives Cygwin-Paket installiert werden kann.
| |
| * [http://winscp.net/ WinSCP] WinSCP ist ein GUI-sftp(1)- und -scp(1)-Clientprogramm für Windows. Der Kern des SSH-Protokolls basiert auf PuTTY.
| |
| * [http://filezilla.sourceforge.net/ FileZilla] FileZilla ist ein mächtiger FTP-Client für Windows 9x, ME, NT4, 2000 und XP. Es wurde auf eine leichte Bedienung ausgelegt und soll dabei so viele Funktionalitäten wie möglich haben und trotzdem noch schnell und zuverlässig sein. Es unterstützt SFTP.
| |
| | |
| | |
| | |
| ===== Mac OS =====
| |
| | |
| Die folgenden Clients sind für die Interoperation mit OpenSSH von ,Mac OS'-Maschinen aus empfohlen. Bedenke, dass Mac OS X OpenSSH standardmäßig beinhaltet. * [http://www.lysator.liu.se/%7Ejonasw/freeware/niftyssh/ NiftyTelnet 1.1 SSH] ist eine Nur-SSH1-Implementation, welche mit einem [http://www.openbsd.org/cgi-bin/man.cgi?query=scp scp]-style Programm ausgeliefert wird. Geschrieben von Jonas Wallden.NiftyTelnet 1.1 SSH r3 ist eine erweiterte Version von Chris Newmans NiftyTelnet-1.1-Anwendung, welche die Unterstützung für verschlüsselte Terminalsitzungen unter Verwendung des SSH- (Secure Shell) Protokolls hinzufügt. Bitte lies die beigelegte Readme-Datei, bevor du diese Version verbreitest."
| |
| * [http://sourceforge.net/projects/macssh/ MacSSH] ist eine Nur-SSH2-Implementation. "MacSSH ist eine modifizierte Version von BetterTelnet mit SSH2-Unterstützung. [...] Den einzigen SSH2-Client für Mac OS, den ich finden konnte, war ein kommerzielles Produkt, das mehr als 100 $ kostet und meinen Mac abstürzen lässt, wenn ich eine Sitzung beende... Da es das Beste ist, Dinge selbst in die Hand zu nehmen, ist MacSSH hier."
| |
| * [http://rsug.itd.umich.edu/software/fugu/ Fugu] ist eine Implementation von SFTP und SCP für Mac OS X. "Fugu SSH ist eine Mac OS X grafische Oberfläche für OpenSSHs ,Secure File Transfer'-Anwendung (SFTP). Fugu erlaubt dir, die Vorteile von SFTPs Sicherheit zu nutzen, ohne die Benutzerfreundlichkeit einer GUI zu opfern. Fugu beinhaltet auch Unterstützung für SCP-Dateiübertragungen und die Möglichkeit, sichere Tunnel durch SSH zu erzeugen."
| |
| * [http://cyberduck.ch/ Cyberduck] ist ein SFTP- und FTP-Browser für Mac OS X. "Cyberduck ist ein Open-Source-SFTP- (SSH Secure File Transfer) und -FTP-Browser, der unter der GPL lizenziert ist. Es wurde von Grund auf mit Benutzerfreundlichkeit im Hinterkopf entwickelt, sodass eine einheitliche Oberfläche für das SFTP- und FTP-Browsen gegeben ist. Mehrere Verbindungen sind verfügbar. [...] Kernsystem-Technologien wie zum Beispiel [http://www.apple.com/macosx/features/security/ Keychain] und [http://www.apple.com/macosx/features/rendezvous/ Rendezvous] werden unterstützt."
| |
| | |
| | |
| | |
| ==== Was ist OpenSSH und wo kann ich sie herunterladen? ====
| |
| | |
| * OpenSSH bietet verschlüsselten Endpunkt-zu-Endpunkt-Ersatz für Anwendungen wie zum Beispiel telnet, rlogin und ftp. Im Gegensatz zu diesen überkommenen Anwendungen, übergibt OpenSSH niemals irgend etwas (einschließlich Benutzername und Passwort) in unverschlüsselter Form an den Draht, und bietet Hostauthentifizierung, um zu überprüfen, ob man wirklich mit dem System spricht, mit dem man zu sprechen glaubt, und um zu verhindern, das jemand anderes die Sitzung übernehmen kann.
| |
| * Die OpenSSH-Suite beinhaltet das [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh&sektion=1 ssh(1)]-Programm, das rlogin und telnet ersetzt, und [http://www.openbsd.org/cgi-bin/man.cgi?query=scp&sektion=1 scp(1)], das [http://www.openbsd.org/cgi-bin/man.cgi?query=rcp&sektion=1 rcp(1)] und [http://www.openbsd.org/cgi-bin/man.cgi?query=ftp&sektion=1 ftp(1)] ersetzt. OpenSSH beinhaltet auch [http://www.openbsd.org/cgi-bin/man.cgi?query=sftp&sektion=1 sftp(1)] und [http://www.openbsd.org/cgi-bin/man.cgi?query=sftp-server&sektion=8 sftp-server(8)], die eine einfache Lösung für Dateiübertragungen realisieren. Sie basieren auf dem [http://openssh.org/txt/draft-ietf-secsh-filexfer-02.txt secsh-filexfer]-IETF-Entwurf.
| |
| | |
| | |
| | |
| ==== OpenSSH besteht aus mehreren Programmen. ====
| |
| | |
| * [http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8 sshd(8)] - Serverprogramm, das auf der Servermaschine läuft. Es lauscht, ob es Verbindungswünsche von Clientmaschinen gibt und führt dann eine Authentifikation durch, bevor es den Client bedient. Das Verhalten wird von der Konfigurationsdatei [http://www.openbsd.org/cgi-bin/man.cgi?query=sshd_config&sektion=5 sshd_config(5)] verwaltet.
| |
| * [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh&sektion=1 ssh(1)] - Dies ist das Clientprogramm, das benutzt wird, um sich auf einer anderen Maschine einzuloggen oder dort Kommandos auszuführen. slogin ist ein weiterer Name für dieses Programm. Das Verhalten wird von der systemweiten Konfigurationsdatei [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh_config&sektion=5 ssh_config(5)] und den benutzerspezifischen $HOME/.ssh/config-Dateien verwaltet.
| |
| * [http://www.openbsd.org/cgi-bin/man.cgi?query=scp&sektion=1 scp(1)] - Kopiert Dateien sicher von einer Maschine zur anderen.
| |
| * [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-keygen&sektion=1 ssh-keygen(1)] - Wird benutzt, um ,Pubkey'-Authentifikations-Schlüssel (RSA oder DSA) zu erzeugen (Hostschlüssel und Benutzer-Authentifikationsschlüssel).
| |
| * [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-agent&sektion=1 ssh-agent(1)] - Authentifikationsagent. Er kann benutzt werden, um RSA-Schlüssel für die Authentifikation bereitzuhalten.
| |
| * [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-add&sektion=1 ssh-add(1)] - Wird benutzt, um neue Schlüssel beim Agenten zu registrieren.
| |
| * [http://www.openbsd.org/cgi-bin/man.cgi?query=sftp-server&sektion=8 sftp-server(8)] - SFTP-Server-Subsystem.
| |
| * [http://www.openbsd.org/cgi-bin/man.cgi?query=sftp&sektion=1 sftp(1)] - Sicheres Dateiübertragungsprogramm.
| |
| * [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-keyscan&sektion=1 ssh-keyscan(1)] - Sammelt ssh-Publickeys ein.
| |
| **
| |
| *** [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-keysign&sektion=8 ssh-keysign(8)] - ssh Hilfsprogramm für hostbasierte Authentifikation.
| |
| | |
| | |
| | |
| ===== Bestandteile =====
| |
| | |
| Die OpenSSH-Distribution enthält folgende Programme:
| |
| | |
| | |
| {| style="border-spacing:0;margin:auto;width:17.501cm;"
| |
| |-
| |
| | style="background-color:transparent;border-top:0.05pt solid #000000;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | '''Name'''
| |
| | style="background-color:transparent;border:0.05pt solid #000000;padding:0.101cm;" | '''Verwendung'''
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | <tt>ssh</tt>
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | ist der ssh-Client. Er baut die Verbindung zu einem ssh-Server auf. Er wird in den folgenden Kapiteln detailliert beschrieben.
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | <tt>sshd</tt>
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | ist der ssh-Server. Er nimmt die Verbindung von ssh-Clients auf. Details: siehe [http://www.jfranken.de/homepages/johannes/vortraege/ssh1_inhalt.de.html#serverconfig Konfigurationshinweise]
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | <tt>ssh-keygen</tt>
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | erstellt und konvertiert Schlüssel. Details: siehe [http://www.jfranken.de/homepages/johannes/vortraege/ssh1_inhalt.de.html#sshkeygen unten].
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | <tt>ssh-agent</tt>,<tt>ssh-add</tt>
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | hält den entschlüsselten Privatekey im Arbeitsspeicher, wo er von ssh-clients angesprochen werden kann. Details: siehe [http://www.jfranken.de/homepages/johannes/vortraege/ssh1_inhalt.de.html#sshagentadd unten].
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | <tt>ssh-keyscan</tt>
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | zeigt den Hostkey eines ssh-Servers an. Anwendungsbeispiel: siehe [http://www.jfranken.de/homepages/johannes/vortraege/ssh1_inhalt.de.html#sshkeyscan unten].
| |
| | |
| | |
| |-
| |
| |}
| |
| ===== Unterstützte Betriebssysteme =====
| |
| | |
| Obwohl OpenSSH unter [http://www.openbsd.org/ OpenBSD] entwickelt wird, gibt es eine breite Palette an Portierungen auf andere Betriebssysteme. Die portable Version von OpenSSH wird von [mailto:djm@openbsd.org Damien Miller] geleitet. Einen schnellen Überblick über die portable Version von OpenSSH gibt dir [http://openssh.org/de/portable.html http://www.openssh.com/portable.html]. Betriebssysteme, die zurzeit unterstützt werden, sind:
| |
| | |
| | |
| * OpenBSD
| |
| * NetBSD
| |
| * FreeBSD
| |
| * AIX
| |
| * HP-UX
| |
| * IRIX
| |
| * Linux
| |
| * NeXT
| |
| * SCO
| |
| * SNI/Reliant Unix
| |
| * Solaris
| |
| * Digital Unix/Tru64/OSF
| |
| * Mac OS X
| |
| * Cygwin
| |
| | |
| | |
| | |
| | |
| | |
| Eine Liste der Anbieter, die OpenSSH in ihre Distributionen einbinden, befindet sich auf der [http://openssh.org/de/users.html OpenSSH-Benutzerseite].
| |
| | |
| ==== Herunterladen ====
| |
| | |
| Die neueste Version von OpenSSH ist Teil der aktuellen Ausgabe von [http://www.openbsd.org/ OpenBSD], und wird stets zusammen mit der Basisinstallation installiert.
| |
| | |
| Heutzutage beinhalten die meisten anderen Betriebssysteme eine Version von OpenSSH (oft umetikettiert oder »geheim« gekennzeichnet), sodass die meisten Benutzer es unmittelbar benutzen können. Wie auch immer, manchmal sind die enthaltenen Versionen ziemlich alt, und lassen Merkmale vermissen, die die aktuelle Veröffentlichung von OpenSSH hat, sodass man gerne die aktuelle Version installieren möchte, oder man möchte sie auf einem der wenigen Betriebssysteme installieren, auf denen sie fehlt, und für die der Herausgeber des Betriebssystems keine moderne Version verfügbar macht. Vielleicht möchte man auch OpenSSH auch für eine eingebettete Anwendung nutzen.
| |
| | |
| Nicht-OpenBSD-Nutzer werden die [http://openssh.org/de/portable.html portable] Distribution von einem [http://openssh.org/de/portable.html#mirrors Spiegelserver] in ihrer Nähe herunterladen, und dann kompilieren und installieren wollen.
| |
| | |
| ===== Bezugsquellen =====
| |
| | |
| OpenSSH ist für sämtliche Betriebssysteme compiliert worden und im Lieferumfang der meisten Linux- oder BSD-Distributionen enthalten.
| |
| | |
| Ein exzellenter Windows-Port unter Verwendung der CygWin32 Bibliotheken ist erhältlich auf [http://www.networksimplicity.com/openssh/ http://www.networksimplicity.com/openssh/]
| |
| | |
| === ssh-Protokolle ===
| |
| | |
| [[Image:Grafik8.png|right]]Beim Einsatz von OpenSSH wird meist ein ssh-Client (<tt>/usr/bin/ssh</tt>) einen ssh-Server (<tt>/usr/sbin/sshd</tt>) ansprechen, der auf einem anderen Rechner laeuft und auf Port 22 lauscht.
| |
| | |
| Im Laufe der Kommunikation kommen die verschiedensten Protokolle zum Einsatz.
| |
| | |
| | |
| user@localhost:~ $ '''echo SSH-1.99-user| nc -w 1 gate 22'''
| |
|
| |
| SSH-1.99-OpenSSH_3.4p1Debian1:3.4p1-1\n[...]
| |
| diffie-hellman-group-exchange-sha1,diffie-hell
| |
| man-group1-sha1\0\0\0017ssh-rsa,ssh-dss\0\0\0faes128-cbc
| |
| ,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
| |
| ,rijndael-cbc@lysator.liu.se\0\0\0faes128-cbc,3des-cbc,blowfish-cbc
| |
| ,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.
| |
| liu.se\0\0\0Uhmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@opens
| |
| sh.com,hmac-sha1-96,hmac-md5-96\0\0\0Uhmac-md5,hmac-sha1,hmac-ripem
| |
| d160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96\0\0\0\tnone
| |
| ,zlib\0\0\0\tnone,zlib\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0
| |
| | |
| Die Liste zeigt die in der ssh-Protokollversion 2 enthaltenen Algorithmen.
| |
| | |
| Eine Untermenge war bereits in der ssh-Protokollversion 1 enthalten, die heute aus Sicherheitsgründen nicht mehr verwendet werden sollte. OpenSSH 3 spricht wahlweise die Protokollversionen 1 oder 2.
| |
| | |
| Details zu den einzelnen Algorithmen gibt es hier:* [[Image:Grafik69.png|right]][http://www.ietf.org/proceedings/00dec/I-D/draft-galb-secsh-gssapi-00.txt draft-galb-secsh-gssapi-00.txt]
| |
| * [http://www.ietf.org/proceedings/00dec/I-D/draft-galb-secsh-publickey-channel-00.txt draft-galb-secsh-publickey-channel-00.txt]
| |
| * [http://www.ietf.org/proceedings/00dec/I-D/draft-ietf-secsh-architecture-06.txt draft-ietf-secsh-architecture-06.txt]
| |
| * [http://www.ietf.org/proceedings/00dec/I-D/draft-ietf-secsh-auth-kbdinteract-01.txt draft-ietf-secsh-auth-kbdinteract-01.txt]
| |
| * [http://www.ietf.org/proceedings/00dec/I-D/draft-ietf-secsh-connect-08.txt draft-ietf-secsh-connect-08.txt]
| |
| * [http://www.ietf.org/proceedings/00dec/I-D/draft-ietf-secsh-transport-08.txt draft-ietf-secsh-transport-08.txt]
| |
| * [http://www.ietf.org/proceedings/00dec/I-D/draft-ietf-secsh-userauth-08.txt draft-ietf-secsh-userauth-08.txt]
| |
| * [http://www.ietf.org/proceedings/00dec/I-D/draft-nisse-secsh-srp-00.txt draft-nisse-secsh-srp-00.txt]
| |
| * [http://www.ietf.org/proceedings/00dec/I-D/draft-salowey-secsh-kerbkeyex-00.txt draft-salowey-secsh-kerbkeyex-00.txt]
| |
| | |
| | |
| | |
| === Verschlüsselung ===
| |
| | |
| ssh verschlüsselt die gesamte Kommunikation zum sshd, inkl. der Anmeldung und aller Tunnels. Man kann dabei zwischen verschiedenen Verschlüsselungsalgorithmen wählen, z.B. * <tt>3des</tt> gilt als besonders sicher, benötigt aber viel Rechenzeit
| |
| * <tt>blowfish</tt> arbeitet besonders schnell
| |
| | |
| | |
| | |
| Hier sind einige Möglichkeiten zur Auswahl des <tt>blowfish</tt>-Algorithmus im lokalen Netz, der die beteiligten Prozessoren entlastet und somit die Kommunikation beschleunigt:* <tt>ssh -c blowfish</tt> ...
| |
| * <tt>ssh -o Cipher=blowfish</tt>...
| |
| * Eintrag <tt>Cipher blowfish</tt> für einige oder alle Hosts in der <tt>~/.ssh/config</tt> oder <tt>/etc/ssh/ssh_config</tt>.
| |
| | |
| | |
| | |
| In Verbindung mit Portforwarding lassen sich unsichere Netzabschnitte für den Client völlig unsichtbar verschlüsseln, etwa um zwei Firmenstandorte über das Internet zu verbinden:
| |
| | |
| [[Image:Grafik72.png|top]]
| |
| | |
| ===== Symmetrische Verschlüsselung ===== | |
| | |
| | |
| {| style="border-spacing:0;margin:auto;width:17.501cm;" | |
| |-
| |
| || 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.
| |
| | align=right| [[Image:Grafik12.png|right|top]]
| |
| |-
| |
| |}
| |
| 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 =====
| |
| | |
| | |
| {| style="border-spacing:0;margin:auto;width:17.501cm;"
| |
| |-
| |
| || Um das Problem der Verteilung ''symmetrischen Verschlüssel'' zu umgehen, wird das Geheimnis für Ver- und Entschlüsselung hinter Algorithmen verborgen, damit es öffentlich verteilen kann.
| |
| | |
| Bei dieser ''asymmetrische Verschlüsselung'', wird ein Schlüsselpaar erzeugt, das mathematisch voneinander abhängt, aber nur mit sehr großem Aufwand voneinander abgeleitet werden kann.
| |
| | |
| Zwei zueinander passende Schlüssel wirken genau entgegengesetzt:
| |
| | |
| Was mit dem einen Schlüssel verschlüsselt wird, kann '''nur''' durch den anderen Schlüssel wieder entschlüsselt werden.
| |
| | align=right| [[Image:Grafik10.png|right|top]]
| |
| |-
| |
| |}
| |
| 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''.
| |
| | |
| Asymmetrischen Verschlüsselungsalgorithmen wie RSA oder DSA erfordert deutlich mehr Rechenleistung als symmetrische.
| |
| | |
| | |
| {| style="border-spacing:0;margin:auto;width:17.501cm;"
| |
| |-
| |
| || Es ist 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.
| |
| | align=right| [[Image:Grafik7.png|right|top]]
| |
| |-
| |
| |}
| |
| Secure Shell nutzt für viele seiner Funktionen Bibliotheken der OpenSSL-Suide.
| |
| | |
| === Grafische Verbindungsverwaltung ===
| |
| | |
| Wem es zu mühsam ist, in der Konsole die SSH-Verbindung zu einem Server aufzubauen, der sucht vielleicht ein grafisches Programm, um seine Verbindungsdaten zu verwalten.* '''kssh''' - Das Programm erlaubt, Server, Benutzernamen und Optionen zu speichern, und öffnet dann eine Konsole mit dem entsprechenden Login.
| |
| * '''gnome-rdp''' - Mit dem Programm kann man nicht nur [http://de.wikipedia.org/wiki/Remote_Desktop_Protocol RDP] und [http://wiki.ubuntuusers.de/VNC VNC] Verbindungen aufbauen, sondern auch normale SSH Terminal Sitzungen. Leider kann man in der aktuellen Version die Zugangspasswörter nicht speichern lassen und keine Angaben zum verwendeten Port machen, es funktioniert somit nur mit Servern die den Standard-SSH-Port nutzen.
| |
| * '''putty''' - Das eher unter Windows bekannte Programm gibt es sehr wohl auch unter Linux.
| |
| | |
| | |
| | |
| == Anwendungen ==
| |
| | |
| === Entferntes Konsolen-Login ===
| |
| | |
| ==== Der SSH-Client ====
| |
| | |
| | |
| {| style="border-spacing:0;margin:auto;width:17.501cm;"
| |
| |-
| |
| || Mit dem Konsolen-Programm <tt>'''ssh'''</tt> können folgende Aufgaben erledigt werden* Aufruf einer entfernten Shell
| |
| * Weiterleiten der Ausgabe grafischer Programme
| |
| * Entfernte Programmausführung
| |
| * Einrichtung von Tunneln
| |
| | |
| | |
| | align=right|
| |
| |-
| |
| | colspan="2" | ssh --h
| |
| usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
| |
| [-D [bind_address:]port] [-e escape_char] [-F configfile]
| |
| [-I pkcs11] [-i identity_file]
| |
| [-L [bind_address:]port:host:hostport]
| |
| [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
| |
| [-R [bind_address:]port:host:hostport] [-S ctl_path]
| |
| [-W host:port] [-w local_tun[:remote_tun]]
| |
| [user@]hostname [command]
| |
| |-
| |
| |}
| |
| Durch Eingabe von
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">ssh hostname</div>
| |
| | |
| eröffnet man eine Shell auf dem Rechner <tt>hostname</tt>.
| |
| | |
| Die Anmeldung erfolgt mit dem lokalen Usernamen
| |
| | |
| Wenn man sich auf dem anderen Rechner unter einem anderen Usernamen anmelden möchte, hilft entweder* <tt>ssh -l username hostname</tt>
| |
| * <tt>ssh username@hostname</tt>
| |
| * <tt>ssh -o User=username hostname</tt>
| |
| * <tt>ssh hostname</tt> und <tt>User hostname</tt> in der config-Datei.
| |
| | |
| | |
| | |
| ==== Escape-Kommandos ====
| |
| | |
| Während der ssh-Sitzung kann man nach Eingabe von <tt><Enter><Tilde></tt> mit den folgenden Tasten Funktionen des ssh-Clients aufrufen:
| |
| | |
| | |
| {| style="border-spacing:0;margin:auto;width:17.501cm;"
| |
| |-
| |
| | style="border-top:0.2pt double #000000;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:none;padding:0.049cm;" | <tt>.</tt>
| |
| | style="border:0.2pt double #000000;padding:0.049cm;" | Beendet die Sitzung inkl. aller Tunnels.
| |
| |-
| |
| | style="border-top:none;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:none;padding:0.049cm;" | <tt>&</tt>
| |
| | style="border-top:none;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:0.2pt double #000000;padding:0.049cm;" | beendet die Sitzung. Die Tunnels bleiben bestehen.
| |
| |-
| |
| | style="border-top:none;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:none;padding:0.049cm;" | <tt>C</tt>
| |
| | style="border-top:none;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:0.2pt double #000000;padding:0.049cm;" | Zeigt einen Prompt (<tt>ssh></tt>), an dem man mit den Befehlen <tt>-L</tt> und <tt>-R</tt> nachträglich Portforwarding einrichten kann (Details: siehe [http://www.jfranken.de/homepages/johannes/vortraege/ssh2.de.html Teil 2]).
| |
| |-
| |
| | style="border-top:none;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:none;padding:0.049cm;" | <tt><Strg-Z></tt>
| |
| | style="border-top:none;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:0.2pt double #000000;padding:0.049cm;" | Suspended die ssh. Man landet in der Shell, aus der man ssh aufgerufen hatte. Mit <tt>fg</tt> geht's weiter.
| |
| |-
| |
| | style="border-top:none;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:none;padding:0.049cm;" | <tt><nowiki>#</nowiki></tt>
| |
| | style="border-top:none;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:0.2pt double #000000;padding:0.049cm;" | zeigt alle Verbindungen an, die gerade über die aktuelle ssh tunneln.
| |
| |-
| |
| | style="border-top:none;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:none;padding:0.049cm;" | <tt>?</tt>
| |
| | style="border-top:none;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:0.2pt double #000000;padding:0.049cm;" | Hilfemenü. Zeigt auch die hier nicht genannten, eher unwichtigen Befehle an.
| |
| |-
| |
| |}
| |
| Wer ein Keyboard-Layout mit deadkeys verwendet, drückt für ein Tildezeichen zweimal auf die Tilde-Taste.
| |
| | |
| Wer mehrere ssh-Sitzungen ineinander geschachtelt hat, erreicht den Escape-Modus der n-ten Shell (von außen gezählt) durch <tt><Enter></tt> und n-fachen Druck (bei deadkeys 2n-fach) auf die Tilde-Taste. Wem das zu kompliziert ist, der kann mit dem <tt>-e</tt> Parameter für jede ssh einen eigenen Escape-Charakter (z.B. <tt><Strg-B></tt>) bestimmen:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">user@gateway:~ $ '''ssh -e ^B localhost'''
| |
| user@localhost:~ $ '''<Strg-B>.'''
| |
| Connection to localhost closed.
| |
| user@gateway:~ $</div>
| |
| | |
| ==== Interaktive Programme automatisch starten ====
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">ssh tp -t vim /etc/hosts</div>
| |
| | |
| ==== Aufruf einer entfernten Shell ====
| |
| | |
| Das funktioniert normalerweise in einen Terminal-Fenster so:
| |
| | |
| '''ssh user@server'''
| |
| user@server's password:
| |
| Last login: Sun Feb 12 07:38:50 2006 from client.local
| |
| Sun Microsystems Inc. SunOS 5.9 Generic_112234-03 November 2002
| |
| bash-2.05$
| |
| | |
| Und schon befindet man sich auf einem anderen Rechner, in diesem Fall mit dem Betriebssystem Solaris.
| |
| | |
| Die Angabe eines Benutzernamens ist nur notwendig, wenn er sich von dem des lokalen Systems unterscheidet.
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">'''ssh server'''
| |
| Password:
| |
| Last login: Sun Feb 12 07:38:23 2011 from client.local
| |
| user@server:~$ </div>
| |
| | |
| ==== Beenden der Sitzung ====
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">Strg + D</div>
| |
| <div style="margin-left:0cm;margin-right:0cm;">exit</div>
| |
| | |
| === Dateimanagement ===
| |
| | |
| 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'''.
| |
| | |
| ==== Secure Copy mit 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- bzw. Hostnamen ergänzt werden.
| |
| | |
| Dabei werden weggelassene Teile durch den aktuellen Benutzernamen, ''localhost'' bzw. das Homeverzeichnis (bzw. das aktuelle Verzeichnis) ergänzt, etwa so:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">scp benutzerx@server1:datei1 datei2 benutzery@server2: </div>
| |
| | |
| 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 [http://wiki.ubuntuusers.de/cp cp] 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.
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">ssh root@server 'cd verzeichnis; tar czvf - verz./dateien' | tar xzf - </div>
| |
| | |
| ==== Entfernte Dateisysteme einbinden (sshfs) ====
| |
| | |
| Man kann das Dateisystem eines entfernten Rechners in sein eigenes Dateisystem mittels [http://wiki.ubuntuusers.de/FUSE/sshfs sshfs] einbinden. Damit ist eine transparente Nutzung von Dateien auch über unsichere Netze hinweg möglich.
| |
| | |
| '''sshfs -p22 user@sshserver:/ /mnt'''
| |
| | |
| Bindet das root-Dateisystem von <tt>'''sshserver'''</tt> in /mnt ein. Bei langsamen Verbindungen kann es sinnvoll sein mit -C die Komprimierung der Datenübertragung einzuschalten.
| |
| | |
| ===== Fehlersuche =====
| |
| | |
| sshfs '''-odebug,sshfs_debug,loglevel=debug''' -p22 user@sshserver:/ /mnt
| |
|
| |
| | |
| ==== Secure File Transfer mit sftp ====
| |
| | |
| Die andere Möglichkeit des Dateitransfers lautet '''sftp'''. Das funktioniert genau so wie der normale Kommandozeilen-FTP-Client:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">'''sftp server'''
| |
| Connecting to server...
| |
| user@server's password:
| |
| sftp> pwd
| |
| Remote working directory: /export/home/user
| |
| sftp> '''ls'''
| |
| [...]
| |
| 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'''
| |
| $ ls -la wichtige_datei.txt
| |
| -rw-r--r-- 1 user user 63664 2006-03-10 17:26 wichtige_datei.txt
| |
| $ </div>
| |
| | |
| ===== Befehle in der SFTP-Shell =====
| |
| | |
| | |
| {| style="border-spacing:0;margin:auto;width:17.501cm;"
| |
| |-
| |
| | style="background-color:transparent;border-top:0.05pt solid #000000;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | <tt>'''bye oder exit'''</tt>
| |
| | style="background-color:transparent;border:0.05pt solid #000000;padding:0.101cm;" | sftp verlassen
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | <tt>'''cd'''</tt>
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | Entferntes Verzeichnis wechseln
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | <tt>'''chgrp grp path '''</tt>
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | Entfernte Gruppenrechte ändern
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | <tt>'''chmod mode path '''</tt>
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | Entfernte Zugriffsrechte ändern
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | <tt>'''chown own path '''</tt>
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | Besitzrechte ändern
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | <tt>'''df [-hi] [path] '''</tt>
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | Entfernten freien Speicherplatz anzeigen
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | <tt>'''exit oder quit'''</tt>
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | sftp verlassen
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | <tt>'''get remote [local] '''</tt>
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | Datei herunterladen
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | <tt>'''help oder ?'''</tt>
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | Hilfe anzeigen
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | <tt>'''lcd path '''</tt>
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | Lokales Verzeichnis ändern
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | <tt>'''lls [ls-options [path]] '''</tt>
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | Lokales Verzeichnis auflisten
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | <tt>'''lmkdir path'''</tt>
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | Lokales Verzeichnis erstellen
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | <tt>'''ln [-s] oldpath newpath '''</tt>
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | Entfernten Link erstellen
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | <tt>'''lpwd '''</tt>
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | Lokales Arbeitsverzeichnis anzeigen
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | <tt>'''ls [-1afhlnrSt] [path] '''</tt>
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | Entferntes Verzeichnis auflisten
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | <tt>'''lumask umask '''</tt>
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | Lokale umask setzen
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | <tt>'''mkdir path '''</tt>
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | Entferntes Verzeichnis erstellen
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | <tt>'''progress '''</tt>
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | Schaltet Fortschrittsbalken an/ab
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | <tt>'''put [-Ppr] local [remote] '''</tt>
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | Datei hochladen
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | <tt>'''pwd '''</tt>
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | Entferntes Arbeitsverzeichnis anzeigen
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | <tt>'''rename oldpath newpath '''</tt>
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | Entfernte Datei umbenennen
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | <tt>'''rm path '''</tt>
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | Entfernte Datei löschen
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | <tt>'''rmdir path '''</tt>
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | Entferntes Verzeichnis löschen
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | <tt>'''symlink oldpath newpath '''</tt>
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | Entfernten Symlink erstellen
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | <tt>'''version '''</tt>
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | SFTP-Version anzeigen
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | <tt>'''!command '''</tt>
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | Führt 'command' in lokaler Shell aus
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | <tt>'''! '''</tt>
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | Öffnet eine lokale Shell (kann mit exit verlassen werden)
| |
| |-
| |
| |}
| |
| Weitere Informationen können der man-page zu sftp(1) entnommen werden.
| |
| | |
| ==== Grafischer Dateimanagement ====
| |
| | |
| ===== KDE =====
| |
| | |
| ====== Zugriff per Dateimanager Dolphin ======
| |
| | |
| Die meisten User möchten keine grafischen Programme auf dem entfernten Rechner ausführen, sondern oftmals Daten vom Laptop zum Heimrechner transferieren.
| |
| | |
| KDE bringt dazu einen kio-slaves mit, der einen transparenten Zugriff aus allen KDE-Anwendungen zulässt.
| |
| | |
| Im Dateimanager Dolphin oder Konqueror kann folgende URL in der Adresszeile verwendet werden
| |
| | |
| fish://<benutzer>@<rechner>/pfad
| |
| fish://user@localhost/home/dirkwagner
| |
| | |
| Daraufhin wird das Benutzerpasswort des Rechners abgefragt und man ist im Home-Verzeichnis des entfernten Rechners und kann nach belieben Daten von einem Rechner zum anderen verschieben und kopieren.
| |
| | |
| | |
| | |
| | |
| ====== Zugriff aus anderen KDE-Anwendungen ======
| |
| | |
| Auch in '''Datei'' -> ''Öffnen'''-Dialogen kann in die Adresszeile eine ''fish:// ''- Adresse eingegeben werden
| |
| | |
| | |
| | |
| | |
| | |
| | |
| ====== Netzwerkordner ======
| |
| | |
| Im Dateimanager [http://wiki.ubuntuusers.de/Dolphin Dolphin] können über das Bookmark "Netzwerk" und den Assistenten "Netzwerkordner hinzufügen" neue ssh-basierte Netzwerkordner als feste Bookmarks erstellt werden.
| |
| | |
| ====== Probleme mit Umlauten ======
| |
| | |
| Wenn der Zielrechner ebenfalls ein UTF-8 codiertes Dateisystem hat, sind u.U. 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.
| |
| | |
| ===== Gnome =====
| |
| | |
| Der Gnome-Dateimanager [http://wiki.ubuntuusers.de/Nautilus Nautilus] 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.
| |
| | |
| Wenn man sich als ein anderer Benutzer anmelden möchte, verwendet man stattdessen eine Adresse der Form <tt>ssh://andererbenutzer@rechnername/pfad</tt> .
| |
| | |
| Diese Adressen funktionieren übrigens auch in einigen anderen Gnome-Anwendungen - z.B. bietet der Texteditor '''GEdit''' mittels ''"Datei -> Adresse öffnen"'' die Möglichkeit, über SSH direkt eine Datei auf einem anderen Rechner zu bearbeiten.
| |
| | |
| ===== Weitere grafische Programme =====
| |
| | |
| Die meisten grafischen FTP-Clients ([http://wiki.ubuntuusers.de/FTP FTP]) unterstützen auch sftp oder scp über das SSH-Protokoll. SSH-Verbindungen zu Datenverzeichnissen auf Fremdrechnern unterstützen auch Datensynchronisationsprogramme wie [http://wiki.ubuntuusers.de/Unison Unison] und Backupprogramme wie Keep.
| |
| | |
| ===== Windows (Cyberduck) =====
| |
| | |
| '''Cyberduck''' ist ein [http://de.wikipedia.org/wiki/Freie_Software freier] [http://de.wikipedia.org/wiki/FTP-Client FTP-Client], ursprünglich für [http://de.wikipedia.org/wiki/Mac_OS_X Mac OS X] entwickelt. Am 8. März 2011 erschien Version 4.0, die auch unter [http://de.wikipedia.org/wiki/Microsoft_Windows Microsoft Windows] lauffähig ist.
| |
| | |
| Cyberduck unterstützt Verbindungen per [http://de.wikipedia.org/wiki/File_Transfer_Protocol FTP], [http://de.wikipedia.org/wiki/FTP_über_SSL FTP/TLS], [http://de.wikipedia.org/wiki/WebDAV WebDAV] und [http://de.wikipedia.org/wiki/SSH_File_Transfer_Protocol SSH File Transfer Protocol] sowie einfaches [http://de.wikipedia.org/wiki/Hochladen Hoch-] und [http://de.wikipedia.org/wiki/Herunterladen Herunterladen] mittels [http://de.wikipedia.org/wiki/Drag_and_Drop Drag and Drop].
| |
| | |
| Auch die [http://de.wikipedia.org/wiki/Synchronisation Synchronisation] von Dateien und Ordnern und das Öffnen und Bearbeiten von Dateien in einem [http://de.wikipedia.org/wiki/Texteditor Texteditor] ist möglich.
| |
| | |
| Cyberduck enthält eine [http://de.wikipedia.org/wiki/Lesezeichen_%28Internet%29 Lesezeichenfunktion] und unterstützt den Netzwerkstandard [http://de.wikipedia.org/wiki/Bonjour_%28Apple%29 Bonjour] sowie den Passwortmanager ''Schlüsselbund''. Bestehende Lesezeichen aus anderen FTP-Clients, etwa [http://de.wikipedia.org/wiki/FileZilla FileZilla], können importiert werden.
| |
| | |
| Soweit installiert, wird der Benutzer mittels [http://de.wikipedia.org/wiki/Growl_%28Software%29 Growl] über den Verbindungsstatus und den Ladefortschritt informiert.
| |
| | |
| Cyberduck ist in einer großen Zahl von Sprachen verfügbar, darunter unter anderem Chinesisch, Deutsch, Englisch, Französisch, Japanisch und Spanisch.
| |
| | |
| Download: https://cyberduck.io
| |
| | |
| === Entfernte Befehlsführung ===
| |
| | |
| Man kann auch einfach einen Befehl anhängen, der anstelle der Terminal-Session ausgeführt wird. Nach der Ausführung des Befehls wird die SSH-Session dann automatisch beendet:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">'''ssh server 'cat /etc/issue''''
| |
| Password:
| |
| Debian GNU/Linux 3.1</div>
| |
| | |
| Oder etwas aufwendiger - eine Datensicherung machen ("backup"):
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">'''ssh root@server 'cd /etc; tar czvf - network/' | cat > etc_network_backup.tar.gz'''
| |
| Password:
| |
| network/
| |
| network/interfaces
| |
| network/if-post-down.d/
| |
| network/if-pre-up.d/
| |
| network/if-up.d/
| |
| network/if-down.d/
| |
| network/options
| |
| network/interfaces.pre-etherconf
| |
| network/interfaces.1
| |
| network/run
| |
| $ ll etc_network_backup.tar.gz
| |
| -rw-r--r-- 1 user user 10240 2006-03-07 02:17 etc_network_backup.tar.gz</div>
| |
| | |
| Bei einer langsamen Verbindung empfiehlt sich zusätzlich die Benutzung der Option <tt>-C</tt> (großes C), die zusätzlich zur Verschlüsselung eine transparente Kompression der übertragenen Daten aktiviert.
| |
| | |
| Bei einer schnellen Verbindung wird die Kompression aber vermutlich bremsen.
| |
| | |
| Woher weiß man nun aber, dass man tatsächlich mit dem richtigen Rechner verbunden ist, und nicht ein Angreifer die Verbindung umgeleitet hat?
| |
| | |
| Dafür gibt es den Host-Schlüssel, der jeden SSH-Server eindeutig identifiziert.
| |
| | |
| Greift man zum ersten Mal auf einen bestimmten Server zu, kennt man diesen Schlüssel natürlich noch nicht. (Außer man hat ihn sich auf anderen Wegen im Voraus besorgt.)
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">'''ssh server'''
| |
| The authenticity of host 'server (192.168.1.5)' can't be established.
| |
| RSA key fingerprint is b5:0e:ec:b7:16:06:e6:24:a6:39:18:58:4e:ec:3b:d1.
| |
| Are you sure you want to continue connecting (yes/no)? yes
| |
| Warning: Permanently added 'server' (RSA) to the list of known hosts.
| |
| Password: </div>
| |
| | |
| Wenn gerade in diesem Moment jemand die Verbindung gekapert hat, hat man natürlich Pech, außer man kann den Administrator des Servers nach dem richtigen Fingerprint des Host-Schlüssels fragen.
| |
| | |
| ===== Fingerprint =====
| |
| | |
| Den RSA-Fingerprint eines Servers kann man mit dem Systemprogramm ssh-keygen erfahren:
| |
| | |
| der Befehl <tt>ssh-keygen -f /etc/ssh/ssh_host_rsa_key.pub -l</tt> gibt den Fingerprint und einige weitere Informationen aus, z.B.
| |
| | |
| <tt>1024 b5:0e:ec:b7:16:06:e6:24:a6:39:18:58:4e:ec:3b:d1 /etc/ssh/ssh_host_rsa_key.pub</tt>
| |
| | |
| Wenn man auf Nummer-sicher gehen möchte, lässt man sich vom Administrator des Servers diese Ausgabe mitgeben (evtl. ausdrucken) und kann dann beim ersten Verbindungsversuch überprüfen, ob man sich tatsächlich zum richtigen SSH-Server verbunden hat und nicht zu einem dazwischengeschalteten Angreifer.
| |
| | |
| Bei allen weiteren Kontakten stellt das '''ssh'''-Programm jedoch von nun an über asymmetrische Kryptografie sicher, dass der Server auch über den richtigen privaten Schlüssel verfügt, der zum öffentlichen, in der Datei '''~/.ssh/known_hosts''' abgelegten passt, und verweigert im Zweifelsfall den Verbindungsaufbau.
| |
| | |
| Sollte sich dieser Schlüssel einmal aus legitimen Gründen geändert haben, bspw. weil das System neu aufgesetzt wurde, muss man den entsprechenden veralteten Schlüssel erstmal auf dem Client mit dem Befehl
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">ssh-keygen -R hostname </div>
| |
| | |
| aus der '''known_hosts'''-Datei entfernen.
| |
| | |
| Sollte die Verbindung nicht mehr reagieren, z.B. wenn der SSH-Server heruntergefahren wurde, lässt sich der ssh-Client mit der Eingabe von "~." (Nacheinander) beenden.
| |
| | |
| === Komprimierung ===
| |
| | |
| Wenn sich das Netz als Engpass herausstellt, kann man die Kommunikation zwischen ssh und sshd komprimieren. Das benötigt auf beiden Seitem etwas mehr Rechenzeit, spart jedoch etwa 50% der Netz-Pakete ein.
| |
| | |
| Um die Komprimierung zu aktivieren:* <tt>ssh -C ...</tt>
| |
| * <tt>ssh -o Compression=yes ...</tt>
| |
| * <tt>Compression yes</tt> in <tt>~/.ssh/config</tt> oder <tt>/etc/ssh/ssh_config</tt>einbauen.
| |
| | |
| | |
| | |
| Zusätzlich sollte auf dem Server in <tt>/etc/ssh/sshd_config</tt> die Zeile <tt>Compression yes</tt> stehen.
| |
| | |
| In Verbindung mit Portforwarding lassen sich langsame Netzabschnitte (z.B. DSL-Strecken) für den Client völlig unsichtbar beschleunigen:
| |
| | |
| === X11-forwarding ===
| |
| | |
| Unter Unix ist es üblich, Anwendungen ("X-Clients") auf anderen Rechnern aufzurufen und am eigenen Bildschirm ("X-Server") zu bedienen. Es gibt zwei Methoden des Verbindungsaufbaus:
| |
| | |
| ==== ohne X11-Tunne ====
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">'''xhost gate'''
| |
| gate being added to access control list
| |
| '''ssh gate'''
| |
| user@gateway: $ '''export DISPLAY=localhost:0'''
| |
| user@gateway: $ '''netscape &'''
| |
| [1] 17101</div>
| |
| | |
| ==== mit X11-Tunnel ====
| |
| | |
| <div style="margin-left:1.249cm;margin-right:0cm;">'''export DISPLAY=:0
| |
| ssh -X gate'''
| |
| user@gateway: $ '''echo $DISPLAY'''
| |
| localhost:10.0
| |
| user@gateway: $ '''netscape &'''
| |
| [1] 17153</div>Hierzu muß auf gate die <tt>libX.so</tt> und <tt>xauth</tt> installiert sein und <tt>X11Forwarding yes</tt> in <tt>/etc/ssh/sshd_config</tt> stehen.
| |
| | |
| Alternativ zu dem <tt>-X</tt>-Parameter kann man dem ssh den Parameter <tt>-o ForwardX11=yes</tt> übergeben oder in der <tt>~/.ssh/config</tt>-Datei <tt>ForwardX11 yes</tt> eintragen.'''Bewertung'''
| |
| | |
| | |
| {| style="border-spacing:0;margin:auto;width:17.501cm;"
| |
| |-
| |
| | style="background-color:transparent;border-top:0.2pt solid #000000;border-bottom:0.2pt solid #000000;border-left:0.2pt solid #000000;border-right:none;padding:0.101cm;" | '''Kriterium'''
| |
| | style="background-color:transparent;border-top:0.2pt solid #000000;border-bottom:0.2pt solid #000000;border-left:0.2pt solid #000000;border-right:none;padding:0.101cm;" | '''ohne X11-Tunnel'''
| |
| | style="background-color:transparent;border:0.2pt solid #000000;padding:0.101cm;" | '''mit X11-Tunnel'''
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.2pt solid #000000;border-left:0.2pt solid #000000;border-right:none;padding:0.101cm;" | Verschlüsselung
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.2pt solid #000000;border-left:0.2pt solid #000000;border-right:none;padding:0.101cm;" | '''-''' Die Kommunikation läuft unverschlüsselt über's Netz. Ein anderer Netzteilnehmer könnte z.B. alle Tastendrücke und eingegebenen Passwörter mitschneiden.
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.2pt solid #000000;border-left:0.2pt solid #000000;border-right:0.2pt solid #000000;padding:0.101cm;" | '''+''' Die Kommunikation erfolgt verschlüsselt. Der Zeitverlust für die Verschlüsselung wird durch die Kompression mehr als wett gemacht.
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.2pt solid #000000;border-left:0.2pt solid #000000;border-right:none;padding:0.101cm;" | X11-security
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.2pt solid #000000;border-left:0.2pt solid #000000;border-right:none;padding:0.101cm;" | '''-''' Der X-Server muß von aussen per tcp-port 6000 erreichbar sein, was weitere Gefahren bietet, z.B. unbefugtes Bildschirmauslesen
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.2pt solid #000000;border-left:0.2pt solid #000000;border-right:0.2pt solid #000000;padding:0.101cm;" | '''+''' Der X-Server darf mit <tt>-nolisten tcp</tt> aufgerufen sein, was vor unberechtigten Zugriffen anderer Netzteilnehmer schützt.
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.2pt solid #000000;border-left:0.2pt solid #000000;border-right:none;padding:0.101cm;" | Firewall/NAT
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.2pt solid #000000;border-left:0.2pt solid #000000;border-right:none;padding:0.101cm;" | '''-''' Diese Methode funktioniert nicht mehr, sobald eine Firewall dazwischen steht.
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.2pt solid #000000;border-left:0.2pt solid #000000;border-right:0.2pt solid #000000;padding:0.101cm;" | '''+''' Kein Problem mit Firewalls, solange sie ssh durchlassen.
| |
| |-
| |
| |}
| |
| Die Verwendung von X11-Tunnels über ssh bringt also klare Vorteile.
| |
| | |
| ==== X-Forwarding ====
| |
| | |
| -X schaltet das X-Forwarding ein. Mit der Option -X lassen sich also alle grafischen Programme auf dem entfernten Rechner starten und auf dem Clienten wiedergeben.
| |
| | |
| | |
| {| style="border-spacing:0;margin:auto;width:17.501cm;"
| |
| |-
| |
| || 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 <tt>-X</tt> '''(groß X)''' hinzufügen, die dem Programm eingeschränkte Rechte am eigenen Display einräumt.
| |
| | align=right| [[Image:Grafik27.png|right|middle]]
| |
| |-
| |
| |}
| |
| 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> '''(klein x)''' wird X11-Forwarding deaktiviert.
| |
| | |
| Die ausgeführten Programme sollten nun auf dem lokalen Bildschirm angezeigt werden.
| |
| | |
| ====== Serverkonfiguration ======
| |
| | |
| Auf dem Server muss das Paket '''xauth''' installiert sein. Außerdem muss dem SSH-Daemon des Servers mitgeteilt werden, dass X-Forwarding verwendet wird. Das wird über die Konfigurationsdatei erledigt.
| |
| | |
| /etc/ssh/sshd_config
| |
| | |
| Dort wird folgende Option gesetzt. Danach ist ein Neustart des Daemons erforderlich.
| |
| | |
| X11Forwarding yes
| |
| | |
| Zusätzlich müssen in der Client-Konfigurationsdatei '''/etc/ssh/ssh_config''' folgende Einträge einkommentiert werden.
| |
| | |
| ForwardX11 yes
| |
| ForwardX11Trusted yes
| |
| | |
| ===== Gesamter entfernter Desktop =====
| |
| | |
| Eine weitere Möglichkeit besteht darin, sich den gesamten entfernten Desktop grafisch in einem Fenster des Clienten zu holen. Das "Zauberwort" für diese Möglichkeit heißt "Xnest"
| |
| | |
| xnest befindet sich im Paket xorg-x11-server-extra, dass es mit Yast zu installieren gilt sofern es nicht schon auf dem Rechner ist. Für diese Vorgehensweise ist es erforderlich, dass der entfernte Rechner hochgefahren ist aber keine KDE-Anmeldung erfolgt ist.
| |
| | |
| Man sollte also auf dem Remote-Rechner den KDM-Anmeldungsmanager sehen. Logge Dich per ssh ein:
| |
| | |
| ssh -XC <user>@<remote-rechner>
| |
| | |
| Die hinzugefügte Option "C" dient dazu, dass die Daten komprimiert übertragen werden, weil beim Remote-Betrieb von X-Anwendungen sehr viel mehr Daten übertragen werden müssen. Dann gibt man ein:
| |
| | |
| Xnest :1 &
| |
| um Xnest eine X-Session starten zu lassen.
| |
| | |
| Man sieht nun ein leeres Fenster auf seinem Heimrechner. Gib dann ein:
| |
| | |
| export DISPLAY=localhost:1
| |
| | |
| Mit 1 legst Du eine Displaynummer fest; meist ist die 0 schon vergeben. Der Befehl soll im Hintergrund gestartet werden (&), weil noch weitere Eingaben folgen.
| |
| | |
| "export" legt fest, das alle folgenden grafischen Ausgaben dem Display 1 übergeben werden. Xnest lenkt sie auf das bisher leere Fenster auf Deinem Heimrechner um. Mit
| |
| | |
| startkde &
| |
| | |
| startet man auf dem entfernten Rechner KDE sofern es dort installiert ist. Ansonsten icewm-session & oder einen Startbefehl für einen anderen Windowmanager der dort installiert ist.
| |
| | |
| ===== X11 Forwarding =====
| |
| | |
| Nachdem ssh häufig in einer X11-Umgebung eingesetzt wird, in der graphische Programme auf einem Server aufgerufen werden, aber auf dem Bildschirm (genauer: auf dem X-Server) einer Workstation dargestellt werden sollen, hat ssh einen eingebauten Mechanismus, der eine sichere verschlüsselte Übertragung für solche Anwendungen bietet.
| |
| | |
| X11-Anwendungen erfahren aus der Umgebungsvariable DISPLAY, auf welchem Display, also auf welchem X-Server sie sich darstellen sollen. Außerdem arbeiten diese Anwendungen mit einem sogenannten Cookie, das ihre Berechtigung festlegt, auf dem Bildschirm eines anderen Rechners etwas darzustellen. All diese Arbeiten nimmt uns ssh komplett ab.
| |
| | |
| Normalerweise müssten wir auf dem Client folgenden Befehl eingeben, um das Programm xclock des Servers auf unserem Bildschirm zu sehen:
| |
| | |
| ssh SERVER /usr/X11R6/bin/xclock -display CLIENT:0.0
| |
| | |
| Diese Übertragung wäre - ganz nebenbei - auch nicht verschlüsselt, denn wir haben ja nur den Befehl verschlüsselt übertragen. Der Weg zurück, vom Server auf unseren Bildschirm, würde ja vom X11-Protokoll übertragen und wäre somit völlig unverschlüsselt. (Auch wenn die Übertragung einer Uhr in der Regel nicht so geheim sein wird...)
| |
| | |
| Wenn wir aber auf dem Server jetzt den '''sshd''' so konfigurieren, dass er in seiner Konfigurationsdatei <tt>/etc/ssh/sshd_config</tt> den Eintrag
| |
| | |
| X11Forwarding yes
| |
| | |
| aufweist und wir gleichzeitig auch unserem Client in der Datei <tt>/etc/ssh/ssh_config</tt> die Anweisung
| |
| | |
| ForwardX11 yes
| |
| | |
| verpassen, dann funktioniert obiger Befehl jetzt viel einfacher. Wir schreiben auf dem Client nur noch
| |
| | |
| ssh SERVER /usr/X11R6/bin/xclock
| |
| | |
| und schon ist die Uhr auf unserem Bildschirm. Die Vorteile sind jetzt im Einzelnen:* Verschlüsselte Übertragung der Daten (ssh-Tunnel, der das X11-Protokoll transportiert)
| |
| * Keine Angabe von DISPLAY, denn der ssh-Server hat automatisch einen "virtuellen" X-Server gestartet, der sozusagen das eine Ende des Tunnels darstellt. Die Umgebungsvariable DISPLAY auf dem Server ist jetzt standardmäßig auf <tt>localhost:10</tt> gesetzt.
| |
| * Keine Einstellungen für Cookies nötig. SSH stellt automatisch "gefälschte" Cookies zur Verfügung und erledigt andere Fragen der Authorisierung.
| |
| | |
| | |
| | |
| Wichtig ist, dass nicht vergessen werden darf, dass auch auf der Client-Seite von SSH die Einstellung <tt>ForwardX11 yes</tt> in der Datei <tt>/etc/ssh/ssh_config</tt> vorgenommen werden muß. Nicht verwechseln, es handelt sich nicht um die Datei der Servereinstellung (ssh'''d'''_config) sondern um die Clientkonfiguration (ssh_config)!
| |
| | |
| === Public key authentication ===
| |
| | |
| | |
| {| style="border-spacing:0;margin:auto;width:17.501cm;"
| |
| |-
| |
| || Wem die Authentifizierung über Passwörter trotz der Verschlüsselung zu unsicher ist, - immerhin könnte das Passwort ja erraten werden - der benutzt am besten das Public-Key-Verfahren.
| |
| | |
| Hierbei wird asymmetrische Verschlüsselung genutzt, um den Benutzer zu authentifizieren.
| |
| | align=right| [[Image:Grafik11.png|right]]
| |
| |-
| |
| |}
| |
| Der (oder die) öffentliche(n) Schlüssel des Benutzers befindet sich dabei in der Datei '''~/.ssh/authorized_keys''' des Zielsystems, der private Schlüssel in einer Datei (meist '''id_rsa''') im Verzeichnis '''~/.ssh''' auf dem lokalen System, wo er zusätzlich von einer "pass phrase" geschützt wird.
| |
| | |
| Wenn man sich nun mit der Public-Key-Methode auf einem SSH-Server anmelden möchte, so schickt der Server dem Klienten eine zufällig generierte ''Challenge''.
| |
| | |
| Der Klient verschlüsselt diesen Datenblock mit seinem privaten Schlüssel, (wofür nötigenfalls die Passphrase abgefragt wird,) und wenn der Server diesen Chiffre mit dem zugehörigen öffentlichen Schlüssel wieder entschlüsseln kann, ist die Identität des Benutzers bestätigt.
| |
| | |
| Die Publickey-Authentifizierung beruht auf dem Prinzip asymmetrischer Verschlüsselung: Der Client und der Server besitzen einen Schlüssel und können damit Nachrichten so verschlüsseln, dass nur der andere sie entschlüsseln kann.
| |
| | |
| Wenn einer nun seinen Schlüssel geheim hält ("private key"), kann der andere von der Authentizität seines Gegenüber ausgehen, sobald er eine Nachricht mit einem seiner eigenen Schlüssel ("public key") entschlüsseln kann.
| |
| | |
| [[Image:Grafik74.png|top]]
| |
| | |
| | |
| Hierzu stehen drei verschiedene Algorithmen zur Verfügung
| |
| | |
| | |
| {| style="border-spacing:0;margin:auto;width:17.501cm;"
| |
| |-
| |
| | style="background-color:#ddddff;border-top:0.2pt double #000000;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:none;padding:0.049cm;" | '''Algorithmus'''
| |
| | style="background-color:#ddddff;border-top:0.2pt double #000000;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:none;padding:0.049cm;" | '''Parameter für '''<tt>ssh-keygen</tt>
| |
| | style="background-color:#ddddff;border-top:0.2pt double #000000;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:none;padding:0.049cm;" | '''Dateinamen'''
| |
| | style="background-color:#ddddff;border:0.2pt double #000000;padding:0.049cm;" | '''Publickey beginnt mit'''
| |
| |-
| |
| | style="border-top:none;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:none;padding:0.049cm;" | RSAfür SSH ab Version 2
| |
| | style="border-top:none;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:none;padding:0.049cm;" | <tt>-t rsa</tt>
| |
| | style="border-top:none;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:none;padding:0.049cm;" | <tt>~/.ssh/id_rsa[.pub]</tt>
| |
| | style="border-top:none;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:0.2pt double #000000;padding:0.049cm;" | <tt>ssh-rsa</tt>
| |
| |-
| |
| | style="border-top:none;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:none;padding:0.049cm;" | RSAfür SSH Version 1
| |
| | style="border-top:none;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:none;padding:0.049cm;" | <tt>-t rsa1</tt>
| |
| | style="border-top:none;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:none;padding:0.049cm;" | <tt>~/.ssh/identity[.pub]</tt>
| |
| | style="border-top:none;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:0.2pt double #000000;padding:0.049cm;" | <tt>1024 35</tt> o.ä, (bits exponent)
| |
| |-
| |
| | style="border-top:none;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:none;padding:0.049cm;" | DSA
| |
| | style="border-top:none;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:none;padding:0.049cm;" | <tt>-t dsa</tt>
| |
| | style="border-top:none;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:none;padding:0.049cm;" | <tt>~/.ssh/id_dsa[.pub]</tt>
| |
| | style="border-top:none;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:0.2pt double #000000;padding:0.049cm;" | <tt>ssh-dss</tt>
| |
| |-
| |
| |}
| |
| Auf die Spezialitäten der einzelnen Algorithmen gehe ich hier nicht weiter ein, als dass DSA die meiste Rechenlast erzeugt und RSA1 besonders leicht verwundbar ist. In vielen Fällen bietet RSA einen guten Kompromiss.
| |
| | |
| Jeder Publickey (z.B. <tt>~/.ssh/id_rsa.pub</tt>) setzt sich wie folgt zusammen:* Der Key-Type (z.B. <tt>ssh-rsa</tt>, siehe Tabelle oben)
| |
| * Ein Leerzeichen
| |
| * Der Modulus (das ist die lange Folge von Buchstaben/Ziffern)
| |
| * optional: Ein Leerzeichen, gefolgt von einem Kommentar
| |
| | |
| | |
| | |
| Er wird mittels uuencode auf 6 bit Ascii codiert. Damit sieht er wie eine lange Text-Zeile aus und lässt sich leicht im Text einer Mail verschicken:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAxtWFO8XbyT6+IlBAWYyOb
| |
| /VWraJ7iymKVsb0TNmieBSzF6fgustkT0nX3udbSqTqiEC/wXFKqeyl27
| |
| bkd+rEcFba+s+wgv9MKRaiV0kOFVQrAvwrKnS1QI6YZWZIhSP7KS5QE0H
| |
| Rra+gy/47vGwHUn0RxksGOQ6YsKP5lNN8H3E= user@localhost</div>
| |
| | |
| ==== Schlüsselgenerierung ====
| |
| | |
| Grundsätzlich werden die notwendigen Schlüsselpaare mit dem Programm '''ssh-keygen''' erstellt. Dieses Programm erstellt sowohl die Schlüsselpaare der User für die oben genannte Authentifizierung, als auch die Hostschlüssel, die zur Verschlüsselung des Datentransfers selbst verwendet werden.
| |
| | |
| ====== Generierung der User-Schlüsselpaare ======
| |
| | |
| Jeder User kann seine ssh-Schlüssel selbst anlegen. Das Programm '''ssh-keygen''' erwartet als Parameter mindestens die Angabe, um welchen Typ von Schlüssel es sich hierbei handeln soll. Folgende Typen stehen zur Verfügung:
| |
| | |
| <tt>'''-t rsa1'''</tt>
| |
| | |
| Generiert wird ein RSA-Schlüsselpaar, das für die Protokollversion 1 von ssh geeignet ist. Der Private-Key wird in die Datei <tt>$HOME/.ssh/identity</tt> geschrieben, der Public-Key liegt in <tt>$HOME/.ssh/identity.pub</tt>
| |
| | |
| <tt>'''-t rsa'''</tt>
| |
| | |
| Hiermit wird ein RSA-Schlüsselpaar für die Protokollversion 2 des SSH-Protokolls erzeugt. Der Private-Key wird nach <tt>$HOME/.ssh/id_rsa</tt> geschrieben, der Public-Key liegt in <tt>$HOME/.ssh/id_rsa.pub</tt>
| |
| | |
| <tt>'''-t dsa'''</tt>
| |
| | |
| Hiermit wird ein DSA-Schlüsselpaar für die Protokollversion 2 des SSH-Protokolls erzeugt. Der Private-Key wird nach <tt>$HOME/.ssh/id_dsa</tt> geschrieben, der Public-Key liegt in <tt>$HOME/.ssh/id_dsa.pub</tt>
| |
| | |
| Der Befehl
| |
| | |
| ssh-keygen -t rsa
| |
| | |
| erzeugt also das Schlüsselpaar vom Typ RSA für die Version 2 des SSH-Protokolls.
| |
| | |
| Beim Anlegen der Schlüsselpaare wird jeweils nach einem Passwort gefragt, das auch leer gelassen werden kann.
| |
| | |
| Der Inhalt der Datei, die den Public-Key enthält, kann jetzt an die Datei <tt>$HOME/.ssh/authorized_keys</tt> auf dem Server angehängt werden. Das kann einfach mit dem cat-Befehl erfolgen, entweder über den Transport via Datenträger oder eleganter auch über ssh, indem ein Befehl in der Art
| |
| | |
| cat ''PublicKeyDatei'' | ssh ''Servername'' "cat >> .ssh/authorized_keys"
| |
| | |
| eingegeben wird. Zu beachten sind die Anführungszeichen, damit die Umleitungssymbole nicht von der lokalen Shell interpretiert werden, sondern von der des Servers. Das erste Mal, wenn dieser Befehl ausgeführt wird, muss noch ein Passwort eingegeben werden, da ja die Authentifizierung über die Schlüssel noch nicht funktioniert, schon direkt nach dem ersten Befehl sollte aber ein ssh-Befehl kein Passwort mehr verlangen.
| |
| | |
| ====== Generierung eines Hostschlüsselpaares ======
| |
| | |
| Die Generierung des Hostschlüsselpaares läuft im Pronzip genauso ab, wie die der Userschlüssel. Allerdings sind hier ein paar Besonderheiten zu beachten: * Der Hostschlüssel darf kein Passwort benutzen, die Frage nach dem Passwort muss also leer gelassen werden.
| |
| * Der Hostschlüssel wird in der Regel im Verzeichnis <tt>/etc/ssh</tt> gespeichert, ältere Versionen erwarten ihn in <tt>/etc</tt> selbst.
| |
| * Der Namen der Hostschlüsseldatei ist in der Regel <br/><tt>'''ssh_host_key</tt> und <tt>ssh_host_key.pub'''</tt> <br/>Die RSA1 Schlüssel für Protokollversion 1 <br/><tt>'''ssh_host_rsa_key</tt> und <tt>ssh_host_rsa_key.pub'''</tt> <br/>Die RSA Schlüssel für Protokollversion 2 <br/><tt>'''ssh_host_dsa_key</tt> und <tt>ssh_host_dsa_key.pub'''</tt> <br/>Die DSA Schlüssel für Protokollversion 2 <br/>Welche Namen tatsächlich verwendet werden, wird in der Serverkonfigurationsdatei <tt>sshd_config</tt> eingestellt (siehe unten).
| |
| | |
| | |
| | |
| Im Normalfall wird das Hostschlüsselpaar bei der Installation von SSH automatisch durch ein Script erzeugt, die entsprechenden Befehle ausführt:
| |
| | |
| ssh-keygen -f /etc/ssh/ssh_host_key -N "" -t rsa1
| |
| ssh-keygen -f /etc/ssh/ssh_host_rsa_key -N "" -t rsa
| |
| ssh-keygen -f /etc/ssh/ssh_host_dsa_key -N "" -t dsa
| |
| | |
| Das <tt>-N ""</tt> bedeutet, dass das neue Passwort leer ist, mit <tt>-f Dateiname</tt> wird der Name der Datei angegeben, in die der Schlüssel abgelegt werden soll.
| |
| | |
| Falls es notwendig sein sollte, ein neues Schlüsselpaar von Hand zu erzeugen, können diese Befehle vom Systemverwalter jederzeit auch manuell eingegeben werden.
| |
| | |
| ==== Schlüsselpaar erzeugen (ssh-keygen) ====
| |
| | |
| Damit man dieses Verfahren überhaupt verwenden kann, muss man sich zunächst mit Hilfe des Kommandozeilenprogramms <tt>ssh-keygen</tt> ein entsprechendes Schlüsselpaar erzeugen:
| |
| | |
| '''ssh-keygen -t rsa'''
| |
| Generating public/private rsa key pair.
| |
| Enter file in which to save the key (/home/user/.ssh/id_rsa):
| |
| Enter passphrase (empty for no passphrase):
| |
| Enter same passphrase again:
| |
| Your identification has been saved in /home/user/.ssh/id_rsa.
| |
| Your public key has been saved in /home/user/.ssh/id_rsa.pub.
| |
| The key fingerprint is:
| |
| 24:55:ee:67:83:72:82:55:5f:b9:b4:09:2a:fa:56:a1 user@client.local
| |
| The key's randomart image is:
| |
| +--[ RSA 2048]----+
| |
| | |
| |
| | |
| |
| | |
| |
| | + . |
| |
| | S E |
| |
| | . + + |
| |
| | .o . o.|
| |
| | o.oo. oo|
| |
| | <nowiki>==o.BO+|</nowiki>
| |
| +-----------------+
| |
| $
| |
| | |
| Der voreingestellte Dateiname ('''id_rsa''') kann einfach mit der Taste ⏎ bestätigt werden, außer man möchte sich ein weiteres Schlüsselpaar erzeugen.
| |
| | |
| Von der Benutzung einer leeren Passphrase ist jedoch abzuraten, weil sonst jeder, der evtl. in den Besitz dieser Datei kommt, sofortigen Zugriff auf alle zugehörigen Systeme erhält.
| |
| | |
| Nun muss noch der öffentliche Schlüssel, zu erkennen an der Endung ''.pub'' ('''id_rsa.pub'''), auf dem Zielsystem deponiert werden.
| |
| | |
| Dazu dient das Programm '''ssh-copy-id'''.
| |
| | |
| Zu diesem Zeitpunkt muss die Authentifizierung per Passwort noch erlaubt sein ('''PasswordAuthentication yes'''):
| |
| | |
| '''ssh-copy-id -i ~/.ssh/id_rsa.pub user@server'''
| |
| Password:
| |
| Now try logging into the machine, with "ssh 'user@server'", and check in:
| |
| .ssh/authorized_keys
| |
| to make sure we haven't added extra keys that you weren't expecting.
| |
| | |
| Sollte der Port nicht gerade 22 sein, dann muss der Befehl wie folgt aussehen:
| |
| | |
| '''ssh-copy-id '-p 12345 -i ~/.ssh/id_rsa.pub user@server' '''
| |
| | |
| Sollte ssh-copy-id nicht funktionieren kann man den öffentlichen Schlüssel auch anders auf das Zielsystem kopieren und in die Datei '''~/.ssh/authorized_keys''' einfügen.
| |
| | |
| Wenn ein vom Standard abweichender Dateiname für den Key gewählt wurde, muss er mittels der Kommandozeilenoption <tt>-i ~/pfad/dateiname</tt> gesondert angegeben werden.
| |
| | |
| Für die dauerhafte Nutzung empfiehlt sich ein Eintrag in der [[#ssh-config|~/.ssh/config:]] mittels <tt>IdentityFile</tt>-Parameter.
| |
| | |
| Anschließend kann man sich ohne Passwort anmelden:
| |
| | |
| '''ssh user@server'''
| |
| Enter passphrase for key '/home/user/.ssh/id_rsa':
| |
| Linux server.local 2.6.12-10-686 #1 Mon Feb 13 12:18:37 UTC 2006 i686 GNU/Linux
| |
| The programs included with the Ubuntu system are free software;
| |
| the exact distribution terms for each program are described in the
| |
| individual files in /usr/share/doc/*/copyright.
| |
| Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
| |
| applicable law.
| |
| Last login: Fri Mar 3 03:51:14 2006
| |
| user@server:~$
| |
| | |
| ====== Hinweis ======
| |
| | |
| Falls es noch nicht klappt kann es daran liegen, dass die Rechte beim Server nicht korrekt sind.
| |
| | |
| sshd achtet darauf, dass das <tt>Homeverzeichnis</tt>, das dem Login-Namen entspricht (also die "Mappe" selbst), das <tt>.ssh</tt>-Verzeichnis und <tt>authorized_keys</tt> nur für den Eigentümer Schreibrechte hat.
| |
| | |
| Hintergrund ist wohl, die Gefahr zu verringern, dass <tt>authorized_keys</tt> manipuliert wird und man keinen Zugriff mehr hat, wenn der Passwortzugang (s.u.) gesperrt ist.
| |
| | |
| Wer also bei bestimmten ''Accounts'' beim Server auch einer Gruppe Schreibrechte gewähren will, muss evtl. die Optionen in <tt>/etc/ssh/sshd.conf prüfen</tt>.
| |
| | |
| Jetzt ist es aber immer noch möglich sich mit dem Passwort anzumelden.
| |
| | |
| Damit man sich nur noch mit dem Key anmelden kann, sollte man noch die Optionen
| |
| | |
| PasswordAuthentication no
| |
| UsePAM no
| |
| | |
| in der Datei '''/etc/ssh/sshd_config''' setzen und mit einem
| |
| | |
| <nowiki># </nowiki>'''/etc/init.d/ssh reload '''
| |
| | |
| die Konfiguration neu einlesen lassen.
| |
| | |
| Alternativ: Auf der Serverseite eingeben <tt>passwd -l <user></tt>. Damit sind Passwörter nur für ausgewählte Accounts sperrbar.
| |
| | |
| Und nochmals der Hinweis: Sollte sich dieser Schlüssel einmal aus legitimen Gründen geändert haben, bspw. weil das System neu aufgesetzt wurde, muss man den entsprechenden veralteten Schlüssel erstmal auf dem Client mit dem Befehl
| |
| | |
| '''ssh-keygen -R hostname '''
| |
| | |
| aus der '''known_hosts'''-Datei entfernen.
| |
| | |
| Jeder Authentifikationsalgorithmus benötigt ein eigenes Schlüsselpaar, das man mit dem Befehl <tt>ssh-keygen</tt> erstellen kann. Mit dem <tt>-t</tt>-Parameter bestimmt man den Algorithmus, zu dem man das Schlüsselpaar erzeugen möchte.
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">'''ssh-keygen -t rsa'''
| |
| Generating public/private rsa key pair.
| |
| Enter file in which to save the key (/export/home/user/.ssh/id_rsa):
| |
| Enter passphrase (empty for no passphrase):
| |
| Enter same passphrase again:
| |
| Your identification has been saved in /export/home/user/.ssh/id_rsa.
| |
| Your public key has been saved in /export/home/user/.ssh/id_rsa.pub.
| |
| The key fingerprint is:
| |
| 7c:02:29:1c:d4:8a:90:ad:f2:b0:65:9e:71:92:ef:0f user@localhost</div>
| |
| | |
| Der Fingerprint ist eine gemeinsame Eigenschaft von Private- und Publickey und ermöglicht es später festzustellen, welcher Privatekey zu einem Publickey passt:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">'''ssh-keygen -l -f .ssh/id_rsa'''
| |
| 1024 5a:b6:c4:50:ce:ec:18:78:e9:b2:e7:5b:04:c2:e4:c7 .ssh/id_rsa.pub</div>
| |
| | |
| Man kann die Passphrase des Privatekey nachträglich ändern:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">'''ssh-keygen -p -f ~/.ssh/id_rsa'''
| |
| Enter old passphrase:
| |
| Key has comment '/export/home/user/.ssh/id_rsa'
| |
| Enter new passphrase (empty for no passphrase):
| |
| Enter same passphrase again:
| |
| Your identification has been saved with the new passphrase.</div>
| |
| | |
| Wer seinen Publickey verlegt hat, kann sich aus dem Privatekey einen neuen Publickey erzeugen:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">'''ssh-keygen -y -f ~/.ssh/id_rsa'''
| |
| ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA5+UaqG/zI...</div>
| |
| | |
| Aber nicht vergessen, es gibt keine Möglichkeit, einen verlorenen Privatekey aus dem Publickey zu erstellen.
| |
| | |
| ==== Hostkeys verwenden ====
| |
| | |
| ===== known_hosts =====
| |
| | |
| Wer beim Aufbau einer ssh-Verbindung ganz sicher gehen möchte, dass der erreichte Server auch der richtige ist, gibt die Option <tt>-o StrictHostkeyChecking=yes</tt> an oder trägt in der <tt>~/.ssh/config</tt> für die betreffenden Hosts <tt>StrictHostkeyChecking yes</tt> ein.
| |
| | |
| Der Client bricht dann die Verbindung ab, wenn der geheime Hostkey des Servers nicht zu dem Public-Key passt, der bereits auf dem Client in <tt>~/.ssh/known_hosts</tt> oder <tt>/etc/ssh/ssh_known_hosts</tt> abgelegt worden ist:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">'''ssh -o StrictHostkeyChecking=yes gate'''
| |
| @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
| |
| @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
| |
| @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
| |
| IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
| |
| Someone could be eavesdropping on you right now (man-in-the-middle attack)!
| |
| It is also possible that the RSA host key has just been changed.
| |
| The fingerprint for the RSA key sent by the remote host is
| |
| 5c:6e:b2:99:3d:44:03:32:fb:e8:c1:ca:4f:cb:9e:8f.
| |
| Please contact your system administrator.
| |
| Add correct host key in /export/home/user/.ssh/known_hosts to get rid of this message.
| |
| Offending key in /export/home/user/.ssh/known_hosts:45
| |
| RSA host key for gate has changed and you have requested strict checking.
| |
| Host key verification failed.</div>
| |
| | |
| oder, wenn dieser Host noch gar nicht in der <tt>known_hosts</tt> eingetragen ist:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">'''ssh -o StrictHostkeyChecking=yes gate'''
| |
| No RSA host key is known for gate and you have requested strict checking.
| |
| Host key verification failed.</div>
| |
| | |
| Wer nicht alle Hostkeys manuell in die <tt>known_hosts</tt>-Datei aufnehmen möchte, sondern nur bei Veränderungen gewarnt werden möchte, sollte <tt>StrictHostkeyChecking</tt> auf <tt>ask</tt> setzen:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">'''ssh -o StrictHostkeyChecking=ask gate'''
| |
| The authenticity of host 'gate (192.168.42.1)' can't be established.
| |
| RSA key fingerprint is 5c:6e:b2:99:3d:44:03:32:fb:e8:c1:ca:4f:cb:9e:8f.
| |
| Are you sure you want to continue connecting (yes/no)? '''yes'''
| |
| Warning: Permanently added 'gate,192.168.42.1' (RSA) to the list of known hosts.
| |
| user@gateway $</div>
| |
| | |
| Die Zeilen der <tt>known_hosts</tt> haben folgendes Format:# Liste von Hostnamen oder IP-Adressen eines Servers, durch Komma getrennt. Wildcards <tt><nowiki>*?</nowiki></tt> und Negation <tt>!</tt> sind erlaubt
| |
| # Ein Leerzeichen
| |
| # Der Publickey dieses Servers (ohne Kommentar)
| |
| # optional: ein Leerzeichen, gefolgt von einem Kommentar
| |
| | |
| | |
| | |
| Die Hostkeys befinden sich auf dem Server an folgenden Stellen:* <tt>/etc/ssh/ssh_host_dsa_key[.pub]</tt> (DSA-Format)
| |
| * <tt>/etc/ssh/ssh_host_rsa_key[.pub]</tt> (RSA-Format f. SSH version 2+)
| |
| * <tt>/etc/ssh/ssh_host_key[.pub]</tt> (im RSA-Format f. SSH version 1)
| |
| | |
| | |
| | |
| Man kann diese Schlüssel mit <tt>ssh-keygen</tt> herstellen. Dabei ist zu beachten. dass man dem Privatekey eine leere Passphrase gibt. Bei vielen Distributionen wird diese Aufgabe beim Einspielen des sshd-Pakets automatisch erledigt.
| |
| | |
| Ändert sich der Hostkey eines Servers (z.B. nach einem SSH Versions-Update), muß man auf dem Client die entsprechenden Zeile aus der <tt>known_hosts</tt> entfernen oder aktualisieren.
| |
| | |
| ====== known_hosts verwalten ======
| |
| | |
| Host 192.168.0.197 aus known_hosts entfernen
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">'''user@localhost:~> ssh-keygen -R 192.168.0.197 -f''' /home/dirkwagner/.ssh/known_hosts
| |
| <nowiki># Host 192.168.0.197 found: line 39 type ECDSA</nowiki>
| |
| /home/dirkwagner/.ssh/known_hosts updated.
| |
| Original contents retained as /home/dirkwagner/.ssh/known_hosts.old</div>
| |
| | |
| ===== ssh-keyscan =====
| |
| | |
| Wer viele Hostkeys in eine <tt>known_hosts</tt>-Datei eintragen muss, kann diese mit <tt>ssh-keyscan</tt> von jedem Client aus abfragen und die Ausgabe direkt an die <tt>known_hosts</tt> anhängen.
| |
| | |
| Da Fehler beim Auslesen des Hostkeys auf Netz- oder Serverprobleme hinweisen, kann man <tt>ssh-keyscan</tt> zur schnellen Diagnose solcher Probleme einsetzen: Wenn es den Hostkey nicht anzeigt, besteht ein Problem.
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">'''ssh-keyscan localhost'''
| |
| <nowiki># localhost SSH-2.0-OpenSSH_6.2</nowiki>
| |
| localhost ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBO2J+IntEBJAdMWRid7ngHLehy1os8pOD/NCXnFfDCzA6nrCm1zXRS5Q5IYpe0Vd/fE5aIFi+ogvUGcB5XbEZQE=
| |
| <nowiki># localhost SSH-2.0-OpenSSH_6.2</nowiki>
| |
| localhost ssh‑rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCngPhrnc6QbxUwO8OQPdK9TIbPY2NBHimgs4WPDSfsf8FqHCrjyMyjHdlbeYTJFa3WqV/yEnSInReGKFzP7EvoM4zHbwWRb+0AMkB5+1c1qvl7uq5P9get7PMRmFXqq/aXAfdRBWyhlLPPCEauHt6IB5O/mvC4U4Rm/Ke4kurQLjcPv85dFFLQzbgVQiea5WUohfng12qHC1pjKuHVtpbhHIA5/JJdTFey/z7/wycS3W1RaNgiry/mc+fIxCzroiL37I4gqegzUBN1JmRkLXARmRUaJgnFKFQR7XNBVV6J68CnqWycwQn4Nj2e4QABu7UpJ07dFSQhzc1k968OM2G</div>
| |
| | |
| ====== Create a Known Hosts File with ssh-keyscan ======
| |
| | |
| # As the starting point for the ssh-keyscan tool, create an ASCII file containing all the hosts from which you will create the known hosts file, e.g. sshhosts.
| |
| # Each line of this file states the name of a host (alias name or TCP/IP address) and must be terminated with a carriage return line feed (Shift + Enter), e.g.<br/>linuxos2.hobsoft.com
| |
| sunultra.hobsoft.com
| |
| # Execute ssh-keyscan with the following parameters to generate the file sshknownhost:<br/>ssh-keyscan -t rsa,dsa -f /home/user/sshhosts >/home/user/sshknownhosts<br/>The parameter -t rsa,dsa defines the host’s key type as either rsa or dsa.<br/>The parameter -f /home/user/sshhosts states the path of the source file sshhosts, from which the host names are read.<br/>The parameter >/home/user/sshknownhosts states the output path of the known host file to be created (sshknownhosts).
| |
| | |
| | |
| | |
| ====== Known Host format ======
| |
| | |
| Each line of the created file contains the following information:
| |
| | |
| hostname sshparameter hostpublickey* hostname: States the host’s name.
| |
| * Shhparameter: States the key type used by the host.
| |
| * Hostpublickey: States the public key of the corresponding host; this is BASE64-coded.
| |
| | |
| | |
| | |
| | |
| | |
| '''Weitere Informationen'''ssh-keyscan(1)
| |
| | |
| ==== Identity-Keys verwenden ====
| |
| | |
| ===== authorized_keys =====
| |
| | |
| Alternativ zu der Eingabe eines Passwortes kann man ein Schlüsselpaar zur Authentifikation verwenden, wobei der Privatekey wiederum mit einer Passphrase geschützt sein kann.
| |
| | |
| Vorteile der Publickey- gegenüber Passwort-Authentifikation:* Die Schlüssel sind mit Brute-Force wesentlich aufwendiger zu erraten als Passwörter
| |
| * Wer meinen Publickey hat, kann mich leicht auf seinen Server einladen.
| |
| * Ich muß mir für alle Zugänge nur eine einzige Passphrase merken, die ich jederzeit mit einem Kommando ändern kann
| |
| * Auf dem Server liegt nur mein Public-Key, mit dem allein noch niemand auf andere Systeme zugreifen kann. Es besteht insbesondere nicht das Risiko, dass jemand mit Brute-Force auf <tt>/etc/shadow</tt> mein Passwort ertestet.
| |
| * Wenn mehrere User auf den selben Account zugreifen, kann jeder seine eigene Passphrase verwenden.
| |
| | |
| | |
| | |
| Die Verwendung von Public-keys ist einfach: Zunächst erstellt man auf dem Client beispielsweise mit <tt>ssh-keygen -t rsa</tt> ein Schlüsselpaar, wie oben beschrieben. Den Public-key kopiert man dann als eine lange Zeile in die Datei <tt>~/.ssh/authorized_keys</tt> auf dem Server.
| |
| | |
| Am Zeilenanfang der Einträge in der <tt>~/.ssh/authorized_keys</tt> kann man zusätzlich dem sshd jeweils mitteilen, von welchen Rechnern man sich mit diesem Schlüssel einloggen darf und welche Besonderheiten (Environmentvariablen, Shell, ssh-Optionen) dabei gelten. Die genaue Syntax der Zeilen lautet:# Optional eine Liste von Optionen, durch Komma getrennt, gefolgt von einem Leerzeichen. Beispiele:
| |
| ## <tt>environment="SSHKEY=user"</tt>(ab openssh ≥3.5p1 muß man hierzu <tt>PermitUserEnvironment=yes</tt> in <tt>/etc/ssh/sshd_config</tt> setzen.)
| |
| ## <tt>command="./menu.pl"</tt>
| |
| ## <tt>from="*.user.de,egal.our-isp.org"</tt>
| |
| ## <tt>no-port-forwarding</tt>
| |
| ## <tt>no-X11-forwarding</tt>
| |
| ## <tt>permitopen="host:port"</tt>
| |
| ## <tt>no-agent-forwarding</tt>
| |
| ## <tt>no-pty</tt>
| |
| # Der Public-Key (siehe *.pub-Datei) ohne Kommentar
| |
| # optional: Ein Leerzeichen und ein Kommentar
| |
| | |
| | |
| | |
| Wenn dann noch auf dem Server in der <tt>/etc/ssh/sshd_config</tt> die Option <tt>PasswordAuthentication No</tt> eingestellt ist, kann man sich nur noch mit dem Schlüssel anmelden, was ziemlich gute Sicherheit gegen Brute-ForceAngriffe bietet.
| |
| | |
| | |
| '''Weitere Informationen'''sshd(8)
| |
| | |
| ===== ssh-copy-id =====
| |
| | |
| Wer öfters seinen Publickey auf Servern platzieren muß, wird gerne auf ein kleines Shellscript namens <tt>ssh-copy-id</tt> zurückgreifen, das über eine ssh-pipe einfach den Publickey an die <tt>authorized_keys</tt> auf dem Server anhängt.
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">'''./ssh-copy-id user@localhost'''
| |
| user@localhost's password:
| |
| Now try logging into the machine,
| |
| with "ssh 'user@localhost'", and check in:
| |
| .ssh/authorized_keys
| |
| to make sure we haven't added extra keys that you weren't expecting.</div>
| |
| | |
| '''Weitere Informationen'''ssh-copy-id(1)
| |
| | |
| ==== Login ohne Passwortabfrage ====
| |
| | |
| ===== Leere Passphrase =====
| |
| | |
| Wenn die Passphrase eines Privatekey leer und der Publickey in der <tt>~/.ssh/authorized_keys</tt> auf dem Server enthalten ist, lässt sich <tt>ssh</tt> wunderbar in Scripte einbauen. Dann sollte man jedoch darauf achten, dass kein Unbefugter Zugriff auf die Privatekey-Datei hat, insbesondere wenn dieser auf einem NFS- oder CIFS-Fileserver liegt.
| |
| | |
| ==== SSH ohne Passwort ====
| |
| | |
| Die SSH ist Ersatz für rsh, rlogin, rcp, ... und bietet * mehr Sicherheit bei der Authentisierung/Authorisierung
| |
| * verschlüsselte Sessions
| |
| * einfachen transparenten Zugriff auf fremde Rechner
| |
| * ad-hoc VPN (über tun-Devices)
| |
| | |
| | |
| | |
| ssh/slogin/scp kann als Ersatz für rsh/rlogin/rcp genutzt werden. Bei vorhandener .rhosts auf dem Zielrechner kann sie sich wie die r* commands verhalten.
| |
| | |
| Sollten dann doch Passwörter übertragen werden, sind diese verschlüsselt. Bei der Nutzung von .rhosts ist die Authentisierung nicht sonderlich sicher, das Paar aus `host' und `user' ist doch ziemlich leicht durch Fremde zu nachzuempfinden.
| |
| | |
| Sie beruhen ausschliesslich auf Vertrauen gegenüber dem DNS und dem fremden Host. Die ssh nutzt host- und userspezifische Keys zur Authentisierung. Spoofing wird damit schwerer.
| |
| | |
| Für die Nutzung der ssh als Ersatz für telnet und rlogin sind folgende Dinge zu tun:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">ssh-keygen -t rsa1 <nowiki># für Protokol 1</nowiki> (!! nicht mehr verwenden !!)
| |
| ssh-keygen -t rsa <nowiki># für Protokol 2</nowiki>
| |
| ssh-keygen -t dsa <nowiki># für Protokol 2</nowiki></div>
| |
| | |
| Damit werden eigene Schlüsselpaare erzeugt. (Für Protokol 2 gibt es RSA und DSA Keys, eigentlich reicht normalerweise einer von beiden.) Die Passphrase sollte nicht ''zu'' lang sein, denn sie wird doch das eine oder andere Mal abgefragt. Zeitweise wurden DSA-Keys für unsicher gehalten, da wohl der Algorithmus schlecht implementiert war.
| |
| | |
| Es entstehen Dateien mit den Schlüsselpaaren: Für Protokoll 1 (RSA1) ''~/.ssh/identity'' und ''~/.ssh/identity.pub'', für Protokoll 2 (RSA, DSA) ''~/.ssh/id_{rsa,dsa}'' und ''~/.ssh/id_{rsa,dsa}.pub''.
| |
| | |
| Die ''<nowiki>*.pub</nowiki>''-Dateien können nun auf den Zielhost kopiert werden und dort an ''~/.ssh/authorized_keys'' angehängt werden:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">ssh-copy-id user@remote-system
| |
| ssh-copy-id -i ~/.ssh/id_rsa.pub user@remote-system
| |
| ssh-copy-id -i ~/.ssh/id_dsa.pub user@remote-system</div>
| |
| | |
| Oder, wenn <tt>ssh-copy-id</tt> nicht vorhanden ist:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">cat ~/.ssh/*.pub | ssh user@remote-system 'umask 077; cat >>.ssh/authorized_keys'</div>
| |
| | |
| Sonst ist das andere Theater witzlos.
| |
| | |
| Nutzt man nun ''slogin'', ''ssh'', oder ''scp'', will der Server auf der anderen Seite den Beweis, daß man zu einem der dort in der <tt>authorized_keys</tt> liegenden öffentlichen Schlüssel den privaten Teil hat.
| |
| | |
| Der lokale Client verlangt also nach der Passphrase, um den (lokal in <tt>id_{dsa,rsa}</tt>) gespeicherten privaten Schlüssel zu "aktivieren". Passen beide Schlüssel zusammen, ist der Server davon überzeugt, daß wir einer derjenigen sind, die Zugang erhalten sollen.
| |
| | |
| Um das beständige Nachfragen nach der Passphrase zu unterdrücken, ist es möglich, einen ''ssh-agent'' beim Login zu starten. Dieser Agent bekommt die Passphrase übergeben, kann den privaten Schlüssel aktivieren und in Zukunft alle Fragen nach diesem Schlüssel stellvertretend beantworten.
| |
| | |
| Für normale Konsolen-Logins geht das etwa so: (in der .profile oder wie immer die heißt) -- meine Login-Shell ist eine Bash.
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">test "$SSH_AUTH_SOCK" || exec ssh-agent $SHELL -c "ssh-add; exec $SHELL -login"</div>
| |
| | |
| Für X11-Nutzer: in meiner .xsession findet sich z.B. folgendes:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">test "$SSH_AUTH_SOCK" || exec ssh-agent $SHELL -c "ssh-add </dev/null; exec fvwm2"
| |
| exec fvwm2</div>
| |
| | |
| Natürlich gibt's noch die "classic-Variante" mit <tt>eval `ssh-agent`</tt> und einem anschließenden <tt>ssh-add</tt>. Aber es bleiben dann Probleme beim Killen der nach Sessionende übrigbleibenden Agents.
| |
| | |
| ===== Problembehebung =====
| |
| | |
| Falls das passwortlose Login nicht funktionert, sollte folgendes geprüft werden* Ist der <tt>ssh</tt>-Zugriff überhaupt möglich? (Ein beliebtes Problem ist <tt>... key_exchange ... connection closed by foreign host</tt>. Das liegt dann meist daran, daß die Reverse-Auflösung der eigenen IP-Adresse nicht mit dem Namen für den eigenen Host übereinstimmt.
| |
| * Auf der anderen Seite in <tt>/etc/hosts.deny</tt> die <tt>ALL: PARANOID</tt> Zeile auskommentieren. Oder DNS in Ordnung bringen!
| |
| * Passwort wird verlangtMeistens ein Problem der Permissions auf der eigenen und/oder der anderen Seite: Das Verzeichnis <tt>.ssh/</tt> und die die Datei <tt>.ssh/authorized_keys</tt> darf nur für den Eigentümer, der auch der "angepeilte" Nutzer sein muß, schreibbar sein. Auch das Home-Verzeichnis des angepeilten Nutzers darf ausschließlich für den Eigenümer beschreibbar sein.
| |
| * <tt>ssh -v ...</tt> hilft, diese Art von Problemen zu diagnostizieren.
| |
| * Die SSH2 verlangt die Keys in ''~/.ssh/authorized_keys2''. M.W. ist die SSH2 auf Debian/GNU-Linux gepatcht und sucht die wie gehabt in ''~/.ssh/authorized_keys'', aber u.a. auf SuSE-Systemen habe ich schon gesehen, daß eben diese '''2''' angehängt werden muß.
| |
| | |
| | |
| | |
| ===== Erzwingen der Verwendung von Schlüsseln =====
| |
| | |
| Wenn das jetzt alles so schön funktioniert, wollen wir ja auch die Anmeldung mit den Schlüsseln erzwingen. Wenn es nur den Root-Account betrifft, ist das relativ einfach:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;"><nowiki># /etc/ssh/sshd_config</nowiki>
| |
|
| |
| PermitRootLogin ''without-password''</div>
| |
| | |
| Wenn auch andere Nutzer von der Schlüsselnutzung überzeugt werden sollen, dann sieht es etwas komplexer aus:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;"><nowiki># /etc/ssh/sshd_config</nowiki>
| |
| …
| |
| PasswordAuthentication ''no''
| |
| ChallengeResponseAuthentication ''no''
| |
| UsePAM ''yes''
| |
| ...</div>
| |
| | |
| Wenn eine schlüsselfreie Anmeldung erkannt wird, versucht die SSH zuerst, PAM zu nutzen (<tt>UsePAM</tt> und <tt>ChallengeResponseAuthentication</tt>), zu erkennen am Passwort-Prompt <tt>Password:</tt>. Wenn das nicht funktioniert, versucht die SSH anschließend noch mal selbst, das Passwort zu prüfen (<tt>PasswordAuthentication</tt>), der Passwort-Prompt ändert sich zu <tt>user@host's password:</tt>.
| |
| | |
| PAM auszuschalten wäre auch möglicht, ist aber nicht nützlich, weil dann z.B. Session-Management über PAM nicht mehr funktioniert, einige Umgebungsvariablen nicht gesetzt werden usw. usf. Waren die oben angegebenen Manipulationen erfolgreich, so darf keinesfalls nach einem Passwort, sondern nur nach einer Passphrase (das ist dann die für den privaten Schlüssel) gefragt werden. Natürlich muss für derlei Versuche der SSH-Agent ausgeschaltet, oder wenigstens "gelähmt" sein (<tt>ssh-add -x</tt>).
| |
| | |
| ===== PermitUserEnvironment =====
| |
| | |
| Wenn mehrere Benutzer mit dem selben Account (z.B. root) eine Maschine zugreifen müssen und es sollen noch personenspezifische Dinge (History, Begrüßung, ... ) konfiguriert werden, dann gibt es eine clevere Lösung:
| |
| | |
| An den Anfang der dem Nutzer entsprechenden Zeile in wird eine Option eingetragen. Diese Zeile sieht dann etwa so aus:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">enviroment="REMOTE_USER=heinz" 1024 37 1452609839509....</div>
| |
| | |
| Diese Umgebungsvariable lässt sich auswerten. In der Manualseite zum ''sshd'' wird dies genauer beschrieben.
| |
| | |
| Bei neueren SSH (>3.4) muss in der Konfiguration erlaubt werden, dass Environment-Variablen gesetzt werden dürfen. Sonst werden die betroffenen Zeilen der <tt>authorized_keys</tt> einfach ignoriert. Die entsprechende Option heißt <tt>PermitUserEnvironment</tt>.
| |
| | |
| === Authentifizierungsagent ssh-agent ===
| |
| | |
| Das Programm '''ssh-agent''' ist ein Programm, das geeignet ist, die Private-Keys zu verwalten, die dazu benötigt werden, um sich mit Public-Keys zu authentifizieren. Die Idee dahinter ist die, dass '''ssh-agent''' am Anfang einer ssh-Sitzung (oder einer X-Sitzung, die über ssh getunnelt wird) gestartet wird und alle weiteren zu startenden Programme als Clients des SSH-Agenten laufen. Damit kann festgelegt werden, dass nicht jeder Rechner im Netz die entsprechenden Private-Keys gespeichert haben muss, es reicht wenn sie auf dem Rechner liegen, auf dem der Agent läuft.
| |
| | |
| ==== SSH-Agent ====
| |
| | |
| Praktisch wäre es, wenn man nicht jedesmal die "pass phrase" eingeben müsste. Dann würde die Verwendung von Public-Keys nicht nur zur Sicherheit beitragen, sondern auch zur Bequemlichkeit (selten genug, dass sich das beides unter einen Hut bringen lässt).
| |
| | |
| Hier kommt der SSH-Agent ins Spiel. Im SSH-Agenten kann man seine(n) privaten Schlüssel ablegen, so dass sich der Agent von nun an um die Authentifizierung kümmert. Man muss also nur einmal seine "pass phrase" angeben, und der Agent behält dann den Schlüssel bis zu seiner Beendigung (normalerweise beim Abmelden des Benutzers ("logout")) im Speicher.
| |
| | |
| Der SSH-Agent wird bei einer Ubuntu-Desktop-Sitzung automatisch im Hintergrund gestartet. Zur Interaktion mit dem SSH-Agenten dient das Programm '''ssh-add''', wobei die Option '''-l''' die augenblicklich gespeicherten Schlüssel auflistet:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">'''ssh-add -l'''
| |
| The agent has no identities.
| |
| $ '''ssh-add'''
| |
| Enter passphrase for /home/user/.ssh/id_rsa:
| |
| Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa)
| |
| $ '''ssh-add -l'''
| |
| 1024 24:55:ee:67:83:72:82:55:5f:b9:b4:09:2a:fa:56:a1 /home/user/.ssh/id_rsa (RSA)
| |
| $ ssh server
| |
| Last login: Wed Mar 8 11:11:58 2006 from 192.168.4.56
| |
| user@server:~$ </div>
| |
| | |
| Wenn man nicht über Gnome (oder eine andere graphische Benutzeroberfläche, die unter dem ssh-agent läuft) eingeloggt ist, funktioniert das so leider nicht. Dann muss man vorher noch ein
| |
| | |
| '''user@server1:~$ exec ssh-agent bash '''
| |
| | |
| ausführen um eine Shell zu öffnen, die mit dem ssh-agent kommunizieren kann.
| |
| | |
| ==== SSH-Askpass ====
| |
| | |
| Wenn eines der Pakete '''ssh-askpass''', '''ssh-askpass-gnome''', '''ssh-askpass-fullscreen''' oder '''gtk-led-askpass''' installiert ist, kann '''ssh-add''' die Passphrase in Ermangelung eines Terminals auch über ein Dialogfenster abfragen.
| |
| | |
| Das nutzt man sinnvollerweise, um seinen Schlüssel gleich nach der Anmeldung auf einem grafischen System zu laden.
| |
| | |
| Für KDE-Nutzer gibt es ab Intrepid das Paket '''ksshaskpass''', das für ssh-add eine graphische Oberfläche zur Verfügung stellt.
| |
| | |
| ===== ssh-agent, ssh-add =====
| |
| | |
| Der <tt>ssh-agent</tt> bietet eine Lösung für User, die es leid sind, immer wieder die selbe Passphrase einzugeben, aber aus Sicherheitsgründen auch nicht ganz auf eine Passphrase verzichten möchten. Damit muß ein Hacker zumindest Zugriff auf den lokalen Rechner und die Socketdatei erlangen, wenn er den Privatekey benutzen möchte.
| |
| | |
| Wenn man den <tt>ssh-agent</tt> ohne Parameter aufruft, erstellt er einen Unix-Domain-Socket, teilt mit, wie man ihn dort erreichen kann und lauscht im Hintergrund darauf:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">'''ssh-agent > myagent.sh
| |
| cat myagent.sh'''
| |
| SSH_AUTH_SOCK=/tmp/ssh-XXcMloql/agent.21753; export SSH_AUTH_SOCK;
| |
| SSH_AGENT_PID=21754; export SSH_AGENT_PID;
| |
| echo Agent pid 21754;</div>
| |
| | |
| Mit <tt>ssh-add</tt> bringt man dem <tt>ssh-agent</tt> seine Privatekeys bei:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">'''. ./myagent.sh'''
| |
| Agent pid 21754;
| |
| '''ssh-add ~/.ssh/id_rsa'''
| |
| Enter passphrase for /export/home/user/.ssh/id_rsa:
| |
| Identity added: /export/home/user/.ssh/id_rsa (/export/home/user/.ssh/id_rsa)</div>
| |
| | |
| Wenn man keinen Privatekey angibt, werden die Standard-keys (<tt>identity</tt>,<tt>id_rsa</tt> und <tt>id_dsa</tt>) geladen.
| |
| | |
| Eine Übersicht der in den agent geladenen Keys erhält mit <tt>ssh-add -l</tt>, und die zugehörigen Publickeys mit <tt>ssh-add -L</tt>.
| |
| | |
| Der <tt>ssh</tt>-Client wird dann bei jedem Verbindungsaufbau die Privatekeys aus dem <tt>ssh-agent</tt> probieren, statt denen aus den Identity-Dateien:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">'''. ./myagent.sh'''
| |
| Agent pid 21754;
| |
| '''ssh gate'''
| |
| […]
| |
| debug1: userauth_pubkey_agent: testing agent key /export/home/user/.ssh/id_rsa
| |
| debug1: input_userauth_pk_ok: pkalg ssh-rsa blen 149 lastkey 0x80926f8 hint -1
| |
| […]</div>
| |
| | |
| Alternativ zu der <tt>myagent.sh</tt> kann man die Werte für die Environment-Variablen auch mit <tt>lsof</tt> bestimmen:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">'''/usr/sbin/lsof -a -u user -U -c ssh-agent'''
| |
| COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
| |
| ssh-agent 477 user 3u unix 0xc1da1aa0 1155 /tmp/ssh-XXWzoqlO/agent.452
| |
| '''export SSH_AUTH_SOCK=/tmp/ssh-XXWzoqlO/agent.452 SSH_AGENT_PID=477'''</div>
| |
| | |
| Wer möchte, dass die Variablen sich automatisch bei jedem Login auf den laufenden ssh-agent einstellen, kann das Programm [http://www.gentoo.org/proj/en/keychain.xml keychain] in seine <tt>~/.bash_profile</tt> aufnehmen.
| |
| | |
| '''Weitere Informationen'''ssh-agent(1) , ssh-add(1)
| |
| | |
| === Single-Sign-On ===
| |
| | |
| Wem immer noch zu umständlich ist, beim Login nacheinander erst das Login-Passwort und dann die SSH-Passphrase einzugeben, der installiert sich stattdessen das Paket '''libpam-ssh'''.
| |
| | |
| Mit den richtigen Einstellungen wird man beim Login nach der Eingabe des Benutzernamens nicht mehr nach dem Passwort, sondern nach der SSH-Passphrase gefragt und kann sich danach ohne nervige Passwortabfrage mittels SSH auf seinen Systemen bewegen.
| |
| | |
| Nur wenn man die Passphrase nicht richtig eintippt, kann man sich stattdessen auch mit seinem normalen Passwort authentifizieren.
| |
| | |
| Zu beachten ist allerdings, dass der [http://wiki.ubuntuusers.de/GNOME_Schlüsselbund GNOME-Schlüsselbund] dann nicht mehr automatisch freigeschaltet wird.
| |
| | |
| ====== Vorsicht ======
| |
| | |
| Macht man hier einen Fehler, kann man sich eventuell nicht mehr am System anmelden. Sollte das passiert sein, ist es normalerweise noch möglich, sich per SSH einzuloggen und den Fehler zu beheben. Wenn auch das nicht mehr hilft, muss man das System zum Reparieren im Single-User-[http://de.wikipedia.org/wiki/Runlevel Runlevel] oder von einer Live-CD starten.
| |
| | |
| ==== Opensuse ====
| |
| | |
| TODO
| |
| | |
| ==== Ubuntu 9.10 ====
| |
| | |
| Zur Anmeldung mit einer Passphrase muss man die Dateien '''login''' (für Konsolenzugang) und '''gdm''' (wahlweise '''kdm''' oder '''xdm'''<nowiki>; für den grafischen Login) im Verzeichnis </nowiki>'''/etc/pam.d''' anpassen. Dort muss man die Zeile
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">@include common-auth</div>
| |
| | |
| durch
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">auth sufficient pam_ssh.so
| |
| auth required pam_unix.so nullok_secure use_first_pass</div>
| |
| | |
| ersetzen und außerdem direkt hinter die Zeile ''@include common-session'' ein ''session optional pam_ssh.so'' setzen.
| |
| | |
| '''/etc/pam.d/gdm''' sieht dann in etwa so aus:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">auth requisite pam_nologin.so
| |
| auth required pam_env.so
| |
| auth sufficient pam_ssh.so
| |
| auth required pam_unix.so nullok_secure use_first_pass
| |
| @include common-account
| |
| session required pam_limits.so
| |
| @include common-session
| |
| session optional pam_ssh.so
| |
| @include common-password</div>
| |
| | |
| Danach wird in der Konsole nach der SSH-Passphrase gefragt, hier kann jedoch auch problemlos das normale Passwort eingegeben werden.
| |
| | |
| Alternative Einstellmöglichkeiten finden sich bei Debian z.B. in der Datei '''/usr/share/doc/libpam-ssh/README.Debian'''.
| |
| | |
| ==== Ubuntu 9.04 und früher ====
| |
| | |
| Zur Anmeldung mit einer Passphrase muss man die Dateien '''login''' (für Konsolenzugang) und '''gdm''' (wahlweise '''kdm''' oder '''xdm'''<nowiki>; für den grafischen Login) im Verzeichnis </nowiki>'''/etc/pam.d''' anpassen.
| |
| | |
| Dort muss man jeweils direkt vor die Zeile ''@include common-auth'' ein ''@include pam-ssh-auth'' setzen, und direkt nach die Zeile ''@include common-session'' ein ''@include pam-ssh-session''. '''/etc/pam.d/gdm''' sieht dann bspw. in etwa so aus:
| |
| | |
| <nowiki>#%PAM-1.0</nowiki>
| |
| auth requisite pam_nologin.so
| |
| auth required pam_env.so
| |
| @include pam-ssh-auth
| |
| @include common-auth
| |
| @include common-account
| |
| session required pam_limits.so
| |
| @include common-session
| |
| @include pam-ssh-session
| |
| @include common-password
| |
| | |
| ('''/etc/pam.d/login''' ist etwas länger...)
| |
| | |
| === {{anchor|RefHeading522856845909}} SSH-Tunnel ===
| |
| | |
| Je nach SSH-Konfiguration können das auch grafische Anwendungen sein (X-Anwendungen).
| |
| | |
| Falls beim obigen Anmelden eine Fehlermeldung kommt wie:
| |
| | |
| Error: Can`t open display:
| |
| | |
| beendet man den Login-Versuch mit
| |
| | |
| <Strg><D>
| |
| | |
| und verbindet sich erneut mit eingefügtem Parameter <-X>
| |
| | |
| ssh -X <benutzer>@<rechner>
| |
| | |
| ==== SSH-Tunnel ====
| |
| | |
| | |
| {| style="border-spacing:0;margin:auto;width:17.501cm;"
| |
| |-
| |
| || Mit SSH lässt sich jedes Protokoll durch eine verschlüsselte Kanal tunneln.
| |
| | |
| Das bedeutet, dass auch potentiell unsichere Protokolle sicher über nicht vertrauenswürdige Verbindungen genutzt werden können.
| |
| | align=right| [[Image:Grafik2.png|right|middle]]
| |
| |-
| |
| |}
| |
| Die Syntax für den SSH-Tunnelbau ist jedoch 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 nur''' zwischen dem ssh-Client und dem ssh-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> bzw. <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 '''<nowiki>*</nowiki>''' 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 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.
| |
| | |
| ==== Tunneling unsicherer Anwendungen ====
| |
| | |
| Um sichere Tunnels zwischen zwei Rechnern aufzubauen, wird der SSH-Client benutzt. Eigentlich handelt es sich um eine Art Port-Forwarding, denn es wird ein lokaler (oder entfernter) Port auf einen entfernten (oder lokalen) Port abgebildet und dazwischen wird eine ssh Verbindung aufgebaut.
| |
| | |
| '''ssh -L ''localerPort'':''fremderRechner'':''fremderPort User@Rechner'''''
| |
| | |
| Mit diesem Befehl wird veranlasst, dass der angegebene Port des lokalen Rechners (''localerPort'') mit dem Port ''fremderPort'' des Rechners ''fremderRechner'' verbunden wird und das diese Verbindung über ssh verschlüsselt läuft. Die Angabe User@Rechner bezieht sich auf den Eigentümer der Verbindung und den Rechner, auf dem der lokale Port läuft. Um also den Port 12345 des Rechners einstein mit dem Port 80 des Rechners bohr zu verbinden, schreibt der User root auf einstein
| |
| | |
| <div style="margin-left:1cm;margin-right:0cm;"> ssh -L 12345:bohr:80 root@einstein</div>
| |
| | |
| '''ssh -R ''fremderPort'':''fremderRechner'':''lokalerPort User@Rechner'''''
| |
| | |
| Das ist sozusagen die Umkehrung des vorherigen Prinzips.
| |
| | |
| ==== Beispiele ====
| |
| | |
| Weiterleitung von Port 8000 auf dem lokalen System an den Webserver (Port 80) auf ''server'':
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">'''ssh -L 8000:localhost:80 server -N &'''
| |
| [1] 10843
| |
| $ '''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. </div>
| |
| | |
| Dasselbe, aber es wird nicht nur vom lokalen Host weitergeleitet, sondern von allen Schnittstellen:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">'''ssh -L *:8000:localhost:80 server -N -4 &'''
| |
| [1] 10906
| |
| $ '''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 </div>
| |
| | |
| Umgekehrte Richtung. Benutzern auf ''server'' wird ermöglicht, über ''localhost:3306'' auf den MySQL-Server auf ''client'' zuzugreifen:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">'''ssh -R 3306:localhost:3306 server'''
| |
| Last login: Sat Mar 11 23:24:20 2006 from 192.168.4.56
| |
| user@server:~$ 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. </div>
| |
| | |
| Zur Veranschaulichung folgt hier noch einmal eine grafische Darstellung dieser Beispiele:
| |
| | |
| | |
| {| style="border-spacing:0;margin:auto;width:17.501cm;"
| |
| |-
| |
| || Doppelter SSH-Tunnel über zwei Konsolen:
| |
| | align=right| [[Image:Grafik5.png|right|middle]]
| |
| |-
| |
| | colspan="2" align=right| [[Image:Grafik6.png|top]]
| |
| |-
| |
| |}
| |
| <div style="margin-left:0cm;margin-right:0cm;">'''supportpc$ ssh -L 54321:localhost:54321 zwischennutzer@zwischen'''
| |
| $ '''zwischen$ ssh -L 54321:localhost:8080 zielnutzer@ziel '''</div>
| |
| | |
| SSH-Tunnel über Zwischenrechner mit Zielrechner verbinden:
| |
| | |
| [[Image:Grafik9.png|top]]
| |
| | |
| '''supportpc$ ssh -L 54322:ziel:22 zwischennutzer@zwischen '''
| |
| | |
| ==== Pipes ====
| |
| | |
| Wenn man ssh einen Befehl übergibt und nicht den <tt>-t</tt>-Parameter setzt, leitet ssh stdin/stdout/stderr des Befehls unverändert an die aufrufende Shell weiter. Auf diese Weise kann man ssh in Pipes einbauen: * Die folgende Befehlsfolge zeigt den Füllstand der Rootpartition des Rechners <tt>gate</tt> an:
| |
| | |
| | |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">'''ssh gate df | awk '/\/$/ {print $5}''''
| |
| 64%</div>* Die folgende Befehlsfolge kopiert das Verzeichnis <tt>mydir</tt> in das <tt>/tmp</tt>-Verzeichnis des Rechners <tt>gate</tt>
| |
| | |
| | |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">'''tar cf - mydir/ | ssh gate 'cd /tmp && tar xpvf -''''</div>
| |
| | |
| ===== imap (fetchmail, mutt) =====
| |
| | |
| Imap ist ein Protokoll zum Übertragen von Mails. Leider sendet es die Mails dabei unverschlüsselt über's Netz. Wer Shellzugriff auf seinen Mailserver hat, sollte es über ssh tunneln, was die Übertragung wesentlich sicherer (Verschlüsselung, Publickey-Authentifikation) und schneller (Kompression) macht. Am einfachsten geht das, indem der Mailuseragent auf dem Mailserver einen imapd im PreAuth-Modus aufruft und sich über stdin/stdout der ssh mit diesem unterhält:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">'''ssh gate imapd'''
| |
| <nowiki>* PREAUTH [231.36.30.64] IMAP4rev1 v12.264 server ready</nowiki></div>
| |
| | |
| Beispiele zur Konfiguration einiger Mailuseragents: * '''fetchmail''': Alle Mail an die Domain <tt>user.de</tt> landet bei meinem Provider (<tt>our-isp.org</tt>), von wo fetchmail sie regelmäßig über imap auf meinen lokalen Mailserver (<tt>gate.user.de</tt>) abholt. Mit der folgenden <tt>~/.fetchmailrc</tt> tunnelt fetchmail die imap-Kommunikation über ssh:
| |
| | |
| | |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">poll johannes.our-isp.org
| |
| with options proto imap,
| |
| preauth ssh,
| |
| plugin "ssh -x -C user@%h /usr/local/bin/imapd Maildir 2>/dev/null",
| |
| smtphost gate,
| |
| fetchall</div>* '''mutt''': Meine Mail liegt also auf <tt>gate</tt>, und ich greife normalerweise lokal mit mutt über imap darauf zu. Falls ich dies von einem anderen Rechner versuche (z.B. mit dem Notebook über's Internet), tunnelt mutt die imap-Kommunikation zu <tt>gate</tt> über ssh. Folgende Zeilen in der <tt>~/.muttrc</tt> ermöglichen das:
| |
| | |
| | |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">set tunnel="imapd || ssh -qC user@gateway.user.de imapd"
| |
| set folder="{gate}~/Mail"</div>
| |
| | |
| ===== smtp (exim) =====
| |
| | |
| Einige Domains nehmen keine Mails von Dialin-Systemen entgegen. Die folgende <tt>/etc/exim/exim.conf</tt> bringt exim (Version 3.35) dazu, die Mails an diese Domains über eine ssh-verbindung zu <tt>johannes.our-isp.org</tt> zu leiten, der über eine feste IP-Adresse verfügt:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">ssh:
| |
| driver = pipe
| |
|
| |
| bsmtp = all
| |
| bsmtp_helo = true
| |
| use_crlf = true
| |
| prefix = ""
| |
| suffix = ""
| |
|
| |
| command = ssh johannes.our-isp.org netcat -w 1 localhost smtp
| |
| user = user
| |
|
| |
| timeout = 300s
| |
| temp_errors = 1
| |
| return_fail_output = true
| |
|
| |
| t_online:
| |
| driver = domainlist
| |
| transport = ssh </div>
| |
| | |
| ===== rsync =====
| |
| | |
| rsync ist ein geniales Tool zum inkrementellen Spiegeln von Verzeichnissen, z.B. über verschiedene lokale Festplatten, nfs oder smbfs. Wenn man es mit dem Parameter <tt>-e ssh</tt> aufruft, tunnelt es sämtliche Kommunikation über eine ssh-Pipe, gerne auch über's Internet. Mit folgendem Aufruf übertrage ich die Webseiten auf meinen Webserver:
| |
| | |
| '''rsync --delete -a -e ssh ./ user@www.user.de:public_html/'''
| |
| | |
| | |
| '''Weitere Informationen'''http://rsync.samba.org/
| |
| | |
| ===== cvs =====
| |
| | |
| <tt>cvs</tt> ist ein Programm zur Versionsverwaltung beliebiger Dateien. Zusätzlich löst es die Konflikte, die dadurch entstehen, dass mehrere User gleichzeitig an den selben Dateien Änderungen vornehmen.
| |
| | |
| Zum Abgleich greift <tt>cvs</tt> entweder über das Filesystem (also lokal, nfs, samba etc.) auf ein gemeinsames Verzeichnis zu, oder kommuniziert mit einem CVS-Server, den man beispielsweise über ssh ansprechen kann.
| |
| | |
| Zur Einrichtung eines CVS-Servers empfehle ich, auf dem Repository-Rechner einen User <tt>cvs</tt> anzulegen, in dessen Homedir das Repository liegt und ihm in seiner <tt>~/.ssh/authorized_keys</tt> für jeden Benutzer eine Zeile anzulegen, die einen CVS-Server-Prozess startet:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">no-port-forwarding,no-X11-forwarding,command="/usr/bin/cvs server" ssh-rsa AAAAB3NzaC1yc2...</div>
| |
| | |
| Um den CVS-Server über ssh anzusprechen, geben Benutzer zuerst folgende Befehle ein:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">'''export CVS_RSH=ssh
| |
| export CVSROOT=:ext:cvs@host:/export/home/cvs'''</div>
| |
| | |
| und können dann wie gewohnt mit cvs arbeiten:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">'''cvs co module'''</div>
| |
| | |
| ==== Port forwarding ====
| |
| | |
| ===== Local port forwarding =====
| |
| | |
| [[Image:Grafik77.png|top]]
| |
| | |
| Wenn ich auf localhost <tt>ssh -g -L 4321:www.ibm.com:80 gate</tt> aufrufe, baut ssh eine Verbindung zu <tt>gate</tt> auf, lauscht währenddessen auf Port <tt>4321</tt> und reicht alle dort ankommenden TCP-Verbindungen an den <tt>sshd</tt> an <tt>gate</tt> weiter, der sie an Port <tt>80</tt> von <tt>www.ibm.com</tt> weiterleitet. Der Rückweg funktioniert entsprechend. Ich habe einen Tunnel von <tt>localhost:4321</tt> auf <tt>www.ibm.com:80</tt> gelegt.
| |
| | |
| Im Browser würde <tt>http://localhost:4321</tt> also genauso aussehen wie die Webseite von IBM. Man muss auf <tt>localhost</tt> Rootrechte haben, wenn man einen lokalen Port <1024 öffnen möchte.
| |
| | |
| Wenn man den <tt>-g</tt> Parameter weglässt, können Clients den Port nur über die IP-Adresse <tt>127.0.0.1</tt> oder entsprechende Aliase (z.B. <tt>localhost</tt>) erreichen, müssen also auf dem selben Rechner wie der ssh-Client laufen, oder aus einem anderen Tunnel dort umsteigen.
| |
| | |
| Sollen die Benutzer auf dem sshd-Rechner keinen Shellzugriff, sondern nur Portforwarding können, kann man zunächst in der <tt>/etc/ssh/sshd_config</tt> die Option <tt>PasswordAuthentication=no</tt> setzen und dann für jeden betreffenden Publickey in der <tt>~/.ssh/authorized_keys</tt> am Zeilenanfang einen Aufruf wie <tt>command="/bin/cat"</tt> oder <tt>command="sleep 2000d"</tt> einfügen.
| |
| | |
| Wer zusätzlich einen keepalive einbauen möchte, damit die Natting-Tabelle der Firewall im Leerlauf die Tunnels nicht kappt, schreibt an den Beginn der Publickeyzeilen jeweils:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">command="while :;do date;sleep 10;done"</div>
| |
| | |
| Um die möglichen Portforwoarding-Ziele zu beschränken, kann man eine Liste von <tt>permitopen</tt>-Optionen vor den jeweiligen Publickeys einfügen, z.B.:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">permitopen="192.168.42.5:80",permitopen="127.0.0.1:8080"</div>
| |
| | |
| ===== Remote port forwarding =====
| |
| | |
| [[Image:Grafik78.png|top]]
| |
| | |
| Wenn ich auf localhost <tt>ssh -R 9030:intranet:80 gate</tt> eingebe, nimmt der <tt>sshd</tt> auf <tt>gate</tt> die Verbindung entgegen, lauscht auf Port <tt>9030</tt> und reicht alle dort ankommenden Verbindungen an den <tt>ssh</tt>-Client auf <tt>localhost</tt> weiter, der sie auf den Port <tt>80</tt> von <tt>intranet</tt> weiterleitet. Der Rückweg funktioniert entsprechend. Ich habe einen Tunnel von <tt>gate:9030</tt> nach <tt>intranet:80</tt> gelegt.
| |
| | |
| Wer im Browser <tt>http://gate:9030</tt> aufruft, landet auf dem Intranetserver.
| |
| | |
| Man muss auf <tt>gate</tt> Rootrechte haben, wenn man remote Port <1024 öffnen möchte. Wer den Rootzugriff per <tt>ssh</tt> nicht erlauben möchte, kann den ssh-Tunnel auf einen hohen Port (z.B. 9030) legen und mit <tt>xinetd</tt>, <tt>netcat</tt> oder Firewallregeln auf Port 80 umleiten.
| |
| | |
| Dies leisten folgende <tt>/etc/inetd.conf</tt>:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">80 stream tcp nowait nobody /bin/nc /bin/nc -w 3 localhost 9030</div>
| |
| | |
| oder <tt>/etc/xinetd.d/intranet</tt>:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">service intranet
| |
| {
| |
| type <nowiki>= UNLISTED</nowiki>
| |
| flags <nowiki>= REUSE</nowiki>
| |
| socket_type <nowiki>= stream</nowiki>
| |
| protocol <nowiki>= tcp</nowiki>
| |
| user <nowiki>= root</nowiki>
| |
| wait <nowiki>= no</nowiki>
| |
| instances <nowiki>= UNLIMITED</nowiki>
| |
| port <nowiki>= 80</nowiki>
| |
| redirect <nowiki>= localhost 9030</nowiki>
| |
| disable <nowiki>= no</nowiki>
| |
| }</div>
| |
| | |
| oder ein Firewallscript:
| |
| | |
| echo 1 > /proc/sys/net/ipv4/ip_forward # turns on forwarding
| |
| iptables -F -t nat # Flush existing translation tables
| |
| iptables -t nat -A PREROUTING -p tcp --dport 9030 -j DNAT --to localhost:80
| |
| iptables -t nat -A POSTROUTING -j MASQUERADE
| |
| | |
| Der <tt>sshd</tt> bindet die remote Tunnels in seiner Standardkonfiguration an das loopback-Interface; er nimmt also nur Verbindungen von localhost entgegen. Wer möchte, dass seine Tunnels auf allen Netzinterfaces erreichbar sind, trage in der <tt>/etc/ssh/sshd_config</tt> auf <tt>gate</tt> die Zeile <tt>GatewayPorts yes</tt> ein oder leite den Port wie oben beschrieben mit ssh oder xinetd um.
| |
| | |
| ===== Tunnels ineinander stecken =====
| |
| | |
| Mit dem <tt>-p</tt> Parameter weise ich den <tt>ssh</tt>-Client an, den <tt>sshd</tt> auf einem anderen Zielport als 22 anzusprechen. Das ist z.B. sinnvoll, wenn ich eine ssh-Verbindung über einen bereits bestehenden Tunnel aufbauen möchte.
| |
| | |
| Mit jedem weiteren Tunnel erhöhe ich die Reichweite um bis zu zwei Hosts:
| |
| | |
| | |
| {| align="center" style="border-spacing:0;width:5.429cm;"
| |
| |-
| |
| | style="background-color:transparent;border-top:0.05pt solid #000000;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | '''Zahl der Tunnels'''
| |
| | style="background-color:transparent;border:0.05pt solid #000000;padding:0.101cm;" | '''Max. hops'''
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | 0
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | 1
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | 1
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | 3
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | 2
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | 5
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | 3
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | 7
| |
| |-
| |
| |}
| |
| | |
| | |
| Die folgende Abbildung zeigt, wie man mit zwei ineinander gesteckten Tunnels bereits fünf hosts beteiligen kann, etwa um eine VNC-Verbindung durch drei Firewalls zu tunneln, die VNC sonst nicht durchließen:
| |
| | |
| [[Image:Grafik79.png|top]]
| |
| | |
| ===== Verwenden der Portweiterleitung =====
| |
| | |
| Wenn sshd(8) auf dem Server auf der Gegenseite läuft, kann es möglich sein, bestimmte Dienste durch ssh zu ,tunneln'. Das kann wünschenswert sein, um beispielsweise POP- und SMTP-Verbindungen zu verschlüsseln, selbst wenn die Software keine eigene Unterstützung für verschlüsselte Verbindungen hat. Das Tunneln verwendet Portweiterleitung, um eine Verbindung zwischen dem Client und dem Server herzustellen. Die Client-Software muss hierfür in der Lage sein, auf einen nicht standardisierten Port verbinden zu können.
| |
| | |
| Die Idee dahinter ist, dass der Client sich mit dem entfernten System über ssh verbindet und angibt, welcher Port auf der Maschine des Clients dazu verwendet werden soll, Verbindungen zum Server weiterzuleiten. Danach ist es möglich, die Dienste, die verschlüsselt werden sollen (z. B. fetchmail, irc), auf dem Client mit der Angabe des gleichen Ports, der an ssh übergeben wurde, zu starten, und die Verbindung wird durch ssh getunnelt. Standardmäßig wird das System, das das Weiterleiten durchführt, nur eigene Verbindungen zulassen.
| |
| | |
| Die wichtigsten Optionen zum Tunneln sind die Optionen -L und -R, welche dem Benutzer das Portweiterleiten erlauben, die Option -D, welche das dynamische Portweiterleiten erlaubt, die Option -g, die es anderen Hosts erlaubt, Portweiterleitung zu benutzen, und die Option -f, welche ssh zuweist, nach der Authentifizierung im Hintergrund weiterzuarbeiten. Lies die [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh&sektion=1 ssh(1)]-Handbuchseite, um weitere Details zu erfahren.
| |
| | |
| Dies ist ein Beispiel für eine getunnelte IRC-Sitzung von der Clientmaschine ,127.0.0.1' (localhost) zum entfernten Server ,server.example.com':
| |
| | |
| ssh -f -L 1234:server.example.com:6667 server.example.com sleep 10
| |
| irc -c '#users' -p 1234 pinky 127.0.0.1
| |
| | |
| Dies tunnelt eine Verbindung zum IRC-Server server.example.com und tritt mit dem Nick ,pinky' dem Channel ,#users' bei. Der lokale Port, der in diesem Beispiel verwendet wurde, ist 1234. Es tut nichts zur Sache, welcher Port benutzt wird, so lange er größer ist als 1023 (bedenke, nur root kann Sockets auf privilegierten Ports öffnen) und keine Störung mit bereits verwendeten Ports auftritt. Die Verbindung wird zum Port 6667 auf dem entfernten Server weitergeleitet, da das der Standardport für IRC-Dienste ist.
| |
| | |
| Der Remote-Befehl ,sleep 10' wurde angegeben, um dem Dienst, der getunnelt werden soll, eine gewisse Zeit (10 Sekunden in diesem Beispiel) zu geben, um zu starten. Wenn in der angegebenen Zeit keine Verbindung aufgebaut wurde, wird ssh sich beenden. Falls mehr Zeit benötigt wird, kann der sleep(1)-Wert entsprechend erhöht werden oder alternativ könnte das oben aufgelistete Beispiel als eine Funktion in die Benutzershell eingefügt werden. Siehe ksh(1) und csh(1) für weitere Details über benutzerdefinierte Funktionen.
| |
| | |
| ssh besitzt des Weiteren die Option -N, welche praktisch für das Portweiterleiten ist: Wenn -N übergeben wurde, ist es nicht notwendig, einen Remote-Befehl (»sleep 10« in dem Beispiel oben) anzugeben. Allerdings führt die Benutzung dieser Option dazu, dass ssh für immer wartet (anstatt zu beenden, wenn ein Remote-Befehl ausgeführt wurde), sodass der Benutzer darauf achten muss, den Prozess hinterher manuell mit kill(1) zu beenden.
| |
| | |
| ==== Reverse SSH-Tunnel ====
| |
| | |
| Um einen Wartungszugang zu einem Rechner, der hinter einer Firewall steht, zu erhalten, kann ein SSH-Tunnel aufgebaut werden. Dieser Tunnel ist nun in beide Richtungen zu benutzen. Dadurch ist es möglich, aus der Entfernung auf einen Rechner zuzugreifen, ohne daß die Firewall, die ihn beschützt, zu öffnen.
| |
| | |
| Der hinter der Firewall stehende Rechner wird hier als „Client“ bezeichnet, der Rechner, zu dem die Verbindung aufgebaut wird, ist der „Server“. Dies ist nur zur Verdeutlichung, tatsächlich sind natürlich beide Rechner sowohl Cient als auch Server.
| |
| | |
| ===== Aufbauen des Tunnels =====
| |
| | |
| Verbinden Sie sich vom Client aus mit dem Befehl
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">ssh -R 21361:localhost:22 meinserver.meinedomain</div>
| |
| | |
| Es steht nun ein Tunnel und Sie können sich mit dem Befehl
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">ssh -p 21361 localhost</div>
| |
| | |
| auf den Rechner verbinden. Hier müssen Sie natürlich das Passwort noch eingeben.
| |
| | |
| ===== Hinweise =====
| |
| | |
| * Es müssen auf beiden Rechnern die SSH-Server laufen.
| |
| * Nutzen Sie beim Aufbauen des Tunnels wo immer möglich den FQDN, auch und gerade bei wechselden IP-Adressen (dyndns.org). Der Kunde wird sonst jedes Mal, wenn er die Verbindung aufbaut, die Sicherheitsabfrage vom SSH-Client bekommen.
| |
| * Der oben angegebene Port 21361 ist nur ein Beispielport. Sie können jeden Highport benutzen, privilegierte Ports nur als root.
| |
| * Unter Umständen ist es sinnvoll, für jeden Kunden einen anderen Port zu benutzen, falls zwei Ihrer Kunden gleichzeitig Support benötigen.
| |
| | |
| | |
| | |
| ===== Remote Control via VNC =====
| |
| | |
| [[Image:Grafik90.png|right]]Fernwartung ist gerade für Administratoren oder Helpdesk-Mitarbeiter in der Firmenzentrale ein hilfreiches Mittel, um entfernte Benutzer bei Problemen zu unterstützen, ohne sich erst auf den Weg machen zu müssen.
| |
| | |
| Und das ist ohnehin nicht immer möglich, weil der Nutzer unter Umständen zu weit entfernt ist. Programme wie VNC oder PC Anywhere bieten die entsprechenden Funktionen.
| |
| | |
| VNC ist zwar Freeware, dafür bietet es jedoch keine Verschlüsselung. Mit OpenSSH lässt sich dieses Manko beheben.
| |
| | |
| Der VNC-Server wartet im Allgemeinen auf Port 5900 auf eingehende Verbindungen.
| |
| | |
| Es müsste also eigentlich reichen, irgendeinen lokalen Port auf diesen Port am entfernten Rechner umzuleiten.
| |
| | |
| Die Client-Anwendung VNCviewer nimmt allerdings keine Portnummer als Parameter an, sondern erlaubt lediglich eine so genannte Display-Nummer, zum Beispiel:
| |
| | |
| zielrechner:0. Display-Nummern größer 0 verweisen auf die Ports nach 5900, also Display 2 auf Port 5902. Der Trick ist also, den lokalen Port 5902 auf den entfernten Port 5900 umzuleiten
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">ssh benutzer@sshrechner -L 5902:sshrechner:5900</div>
| |
| | |
| und dann den VNCviewer mit localhost:2 zu starten. Dieser versucht nun, über den Port 5902 eine Verbindung zu einem lokalen Server aufzubauen, der allerdings von SSH auf den entfernten Rechner umgeleitet wird.
| |
| | |
| VNC is a very useful program for accessing a computer remotely. These are instructions for accessing a remote machine using OS X, Chicken of the VNC, and Vine Server when there is a firewall in the way.
| |
| | |
| Normally it is a fairly straightforward process to connect from a VNC client to a VNC server running on a remote machine. A firewall in the middle can complicate the process a bit.
| |
| | |
| ====== Normal ======
| |
| | |
| MY MACHINE -> VNC CLIENT < - -> VNC SERVER < - REMOTE MACHINE
| |
| | |
| ====== Behind firewall: ======
| |
| | |
| REMOTE MACHINE -> VNC SERVER -> SSH TUNNEL < - -> VNC CLIENT < - MY MACHINE# On MY MACHINE, create a local SSH user account and password – call it vnc_user
| |
| # On MY MACHINE, determine my public IP address – go to [http://whatismyip.com/ whatismyip.com] (MY_IP_ADDRESS)
| |
| # On REMOTE MACHINE, turn on the Vine Server and set the password
| |
| # On REMOTE MACHINE, open up Terminal and enter the following command:
| |
| # <tt>ssh vnc_user@MY_IP_ADDRESS -R 5900:127.0.0.1:5900</tt>
| |
| # where MY_IP_ADDRESS is the IP address of MY MACHINE.
| |
| # Enter the password for the vnc_user. You should now be connected to MY MACHINE over SSH.
| |
| # On MY MACHINE, open up Chicken of the VNC. Connect to '''localhost''' and enter the password for the REMOTE MACHINE.
| |
| # You should now be connected to REMOTE MACHINE’s VNC server and be seeing their screen.
| |
| | |
| '''Notes:'''*
| |
| **
| |
| ***
| |
| **** Make sure that you are not running a VNC server on MY MACHINE, or that it is turned off
| |
| **** If you are running a firewall on your own network, you may need to enable port forwarding for SSH to ensure that SSH requests on port 22 are connected to MY MACHINE and not blocked by your own firewall.
| |
| | |
| Thanks to [http://www.macosxhints.com/article.php?story=20050222062346277 this article] that describes how to do this and also includes an Applescript that makes the connection.
| |
| | |
| ==== ppp over ssh ====
| |
| | |
| Das Point-to-point-Protokoll beschreibt Verbindungsaufbau und IP-Kommunikation zwischen zwei virtuellen Netzinterfaces. Mit etwas Aufwand kann man es auch über ssh tunneln, und so beliebige IP-Pakete über eine ssh-Verbindung routen.
| |
| | |
| [[Image:Grafik80.png|top]]
| |
| | |
| '''Konfiguration des Servers:'''# Installation ppp (z.B. Version 2.4.1.uus-4 aus Debian GNU/Linux 3.0)
| |
| # Dateirechte prüfen:<br/>'''ls -l /usr/sbin/pppd'''
| |
| -rwsr-xr-- 1 root dip 230604 10. Dez 2001 /usr/sbin/pppd*
| |
| # Einen Benutzer anlegen, der zum Aufruf des pppd berechtigt ist:<br/>'''adduser --group dip pppuser'''
| |
| # PAP-Passwort und IP-Adressbereich vergeben:<br/>'''echo 'pppuser * geheim *' >> /etc/ppp/pap-secrets'''
| |
| # In der <tt>~pppuser/.ssh/authorized_keys</tt> den RSA-keys IP-Adressen zuordnen (Eine Zeile pro Publickey):<br/>no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="/usr/sbin/pppd remotename pppuser refuse-chap refuse-mschap refuse-mschap-v2 refuse-eap require-pap 192.168.45.1:192.168.45.2 notty debug linkname pppoverssh" ssh-rsa AAAAB3NzaC1...
| |
| # Die <tt>/etc/ppp/ip-up.d/*</tt>-Scripts von allen störenden Routing- und Firewall-Initialisierungen bereinigen, welche die Distribution für die Interneteinwahl vorgesehen hatte. Wenn auf dem Rechner weitere PPP-Verbindungen (z.B. DSL-Einwahl ins Internet) erforderlich sind, können sich die Scripts an der $LINKNAME-Variablen orientieren, die den Wert "pppoverssh" hat.
| |
| | |
| | |
| | |
| ===== Konfiguration des Clients =====
| |
| | |
| # Installation ppp (z.B. Version 2.4.1.uus-4 aus Debian GNU/Linux 3.0)
| |
| # Sicherstellen, dass der User den pppd setsuid aufrufen kann:<br/>'''ls -l /usr/sbin/pppd'''
| |
| -rwsr-xr-- 1 root dip 230604 10. Dez 2001 /usr/sbin/pppd*
| |
| '''usermod -G dip user'''
| |
| # Einen neuen Provider anlegen:<br/>'''cat >/etc/ppp/peers/ssh <<EOF
| |
| pty 'ssh -e none pppuser@'''''SERVER-HOSTNAME''''' false'
| |
| user pppuser
| |
| nodetach
| |
| linkname pppoverssh
| |
| <nowiki># debug</nowiki>
| |
| EOF'''
| |
| # Das PAP-Passwort des Serves eintragen:<br/>'''echo 'pppuser * geheim' >> /etc/ppp/pap-secrets'''
| |
| # <tt>/etc/ip-up.d/*</tt> ggf. anpassen (z.B. defaultroute auf <tt>$PPP_IFACE</tt> umsetzen)
| |
| | |
| | |
| | |
| '''So sieht der Verbindungsaufbau aus, wenn alles geklappt hat:'''
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">user@localhost:~ $ '''/usr/sbin/pppd call ssh'''
| |
| Using interface ppp0
| |
| Connect: ppp0 <--> /dev/ttyp4
| |
| Remote message: Login ok
| |
| kernel does not support PPP filtering
| |
| Deflate (15) compression enabled
| |
| Cannot determine ethernet address for proxy ARP
| |
| local IP address 192.168.45.2
| |
| remote IP address 192.168.45.1</div>
| |
| | |
| | |
| '''Mehr zum Thema pppd-Optionen:'''pppd(8)
| |
| | |
| ==== Umgang mit Netz-Timeouts ====
| |
| | |
| ===== Keepalives =====
| |
| | |
| Man kann konfigurieren, ob und wie <tt>ssh</tt> und <tt>sshd</tt> Verbindungsabbrüche feststellen sollen:
| |
| | |
| | |
| {| style="border-spacing:0;margin:auto;width:17.501cm;"
| |
| |-
| |
| | style="background-color:transparent;border-top:0.05pt solid #000000;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.15cm;" | '''Seite'''
| |
| | style="background-color:transparent;border-top:0.05pt solid #000000;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.15cm;" | '''Option'''
| |
| | style="background-color:transparent;border:0.05pt solid #000000;padding:0.15cm;" | '''Auswirkung'''
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.15cm;" | '''ssh'''
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.15cm;" | <tt>ProtocolKeepAlives=</tt>''n''
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.15cm;" | ssh sendet nach der Authentifizierung alle ''n'' Sekunden ein 32 Byte langes Leerpaket an den sshd.
| |
| | |
| Das interessiert den sshd nicht weiter, aber der TCP-Stack des Servers muss ja TCP-Pakete regelmäßig mit ACKs beantworten.
| |
| | |
| Wenn der TCP-Stack des Clients kein ACK auf dieses oder ein späteres Paket erhält, retransmitted er eine Zeit lang und signalisiert dann dem ssh ein Connection-Timeout, worauf dieser sich beendet.Linux 2.4 sendet 15 Retransmits und benötigt dafür etwa '''14 Minuten'''. Die Zahl der Retransmits ist in <tt>/proc/sys/net/ipv4/tcp_retries2</tt> und <tt>/etc/sysctl.conf</tt> konfigurierbar.
| |
| | |
| TCP wartet zwischen den Retransmits 3,6,12,24,48,60,60,60,... Sekunden auf Antwort.
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.15cm;" | '''ssh,sshd'''
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.15cm;" | <tt>KeepAlive=</tt>''(yes|no)''
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.15cm;" | Der Prozess setzt beim Öffnen der TCP-Verbindung die Keepalive-Socketoption.
| |
| | |
| Wenn der TCP-Stack darauf länger (z.B. 2 Stunden) nichts empfängt, sendet er nochmal ein altes Segment, zu dem er bereits ein ACK erhalten hat.
| |
| | |
| Wenn die Gegenseite dadurch zum Wiederholen ihres letzten ACKs provoziert wird und dieses (z.B. innerhalb von 75 Sekunden) eintrifft, ist die Verbindung OK.
| |
| | |
| Sonst wiederholt der TCP-Stack den Test einige (z.B. 9) mal und signaliert dann dem Prozess ein Connection-Timeout.
| |
| | |
| Die genannten Werte sind bei Linux 2.4 in <tt>/proc/sys/net/ipv4/tcp_keepalive_intvl</tt>, <tt>/proc/sys/net/ipv4/tcp_keepalive_probes</tt> und <tt>/proc/sys/net/ipv4/tcp_keepalive_time</tt> bzw. in <tt>/etc/sysctl.conf</tt> konfigurierbar. Mit den o.g. Standardwerten dauert die Diagnose der verlorenen Verbindung insg. '''2h11'15"'''!
| |
| |-
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.15cm;" | '''sshd'''
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.15cm;" | <tt>ClientAliveInterval=</tt>''s''<tt>ClientAliveCountMax=</tt>''n''
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.15cm;" | Wenn sshd ''s'' Sekunden nichts empfangen hat, bittet er den ssh-Client im Abstand von ''s'' Sekunden um ein Lebenszeichen und beendet die Verbindung nach ''n'' erfolglosen Versuchen.
| |
| |-
| |
| |}
| |
| '''Feststellungen'''* Da es keinen <tt>ServerAliveInterval</tt>-Parameter für den Client gibt, bleibt der Client bei einigen Netzproblemen (z.B. NAT-Timeouts) mindestens eine Viertelstunde hängen, was für die getunnelten Verbindungen besonders lästig ist.
| |
| * Wenn man <tt>ProtocolKeepAlives=0</tt>, <tt>KeepAlive=no</tt> und <tt>ClientAliveInterval=0</tt> setzt und nach der Authentifizierung nichts mehr sendet, kann man die Netzverbindung trennen und beliebig (z.B. Jahre) später fortsetzen.
| |
| | |
| | |
| | |
| ===== autossh =====
| |
| | |
| autossh ist ein C-Programm von Carson Harding <harding@motd.ca> (siehe [http://www.harding.motd.ca/autossh/ http://www.harding.motd.ca/autossh/]). Es löst das Problem hängender Tunnels, indem es # den ssh-Client startet ,
| |
| # sich dabei mit zwei Portforwardings eine Testschleife einrichtet ,
| |
| # regelmäßig die Verbindung über die Testschleife prüft und
| |
| # den ssh-Client bei Problemen stoppt und erneut aufruft .
| |
| | |
| | |
| | |
| [[Image:Grafik81.png|right|top]]
| |
| | |
| Mit dem folgenden Aufruf stelle ich meinen IMAP-Server lokal zur Verfügung. autossh prüft ssh-Verbindung nach den ersten 30 Sekunden alle 15 Sekunden:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">'''export AUTOSSH_GATETIME=30
| |
| export AUTOSSH_POLL=15
| |
| autossh -M 20000 -g -N -C -L 143:localhost:143 gate.user.de'''</div>
| |
| | |
| Wer häufig ssh-Tunnels errichtet, kann sich ein bash-Alias auf <tt>ssh</tt> legen:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">'''alias ssh=':& a=$! ; port=$(( $a%45536 +20000 ))
| |
| AUTOSSH_GATETIME=30 AUTOSSH_POLL=15 autossh -M $port'
| |
| ssh -g -N -C -L 143:localhost:143 gate.user.de'''
| |
| [1] 6418</div>
| |
| | |
| Hierbei wird die nächste PID in $a geschrieben, durch Addieren von 20000 oder -25536 daraus ein Wert zwischen 20000 und 65535 ermittelt und dieser als Monitoringport an autossh übergeben.
| |
| | |
| === Firewalls durchdringen ===
| |
| | |
| | |
| {| style="border-spacing:0;width:17cm;"
| |
| |- style="background-color:#ffaaaa;border:none;padding:0.049cm;"
| |
| || '''Achtung:'''Das Umgehen fremder Sicherheitssysteme ist verboten. Hier soll ein Verständnis für Sicherheitslücken vermitteln werden, damit sie abgesichert werden können.
| |
| | |
| | |
| |-
| |
| |}
| |
| ==== Motivation ====
| |
| | |
| ssh-Verbindungen stellen für Firmen ein enormes Risiko dar, schließlich können darüber Tunnels an Virenscannern und Logfiles vorbei gelegt und Dateien übertragen werden.
| |
| | |
| Viele Firmen haben daher auf ihren Routern oder Firewalls den Zugriff auf Port 22 aller Internetteilnehmer verboten. Da heute jedoch praktisch kein Unternehmen auf einen Internetanschluß verzichten kann, bestehen meist doch gewisse Löcher in der Firewall.
| |
| | |
| Mit den Kenntnissen aus Kapitel 14.3.9 SSH-Tunnel (S. 84) (insb. ppp-over-ssh) ist es damit trivial, beliebige IP-Verbindungen durch nahezu jede Firewall zu betreiben.
| |
| | |
| ==== Offene Ports benutzen ====
| |
| | |
| Zunächst soll geprüft, welche Ports die Firewall immer durchlässt. Dazu kann der <tt>nmap</tt>-Portscanner genutzt werden:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">root@localhost$ '''nmap -sA -p 1-65535 www.user.de'''
| |
| Starting nmap V. 2.54BETA22 ( www.insecure.org/nmap/ )
| |
| Interesting ports on www.user.de (195.88.176.20):
| |
| (The 21 ports scanned but not shown below are in state: filtered)
| |
| Port State Service
| |
| 25/tcp UNfiltered smtp
| |
| 80/tcp UNfiltered http
| |
| 443/tcp UNfiltered https
| |
| Nmap run completed -- 1 IP address (1 host up) scanned in 5138 seconds</div>
| |
| | |
| Sobald auch nur ein Port <tt>unfiltered</tt> ist (hier z.B. 80), kann ich auf meinem Server für diesen Port einen <tt>sshd</tt> starten: <span style="color:#ff3333;">oder den Port auf dem Server mit </span><span style="color:#ff3333;"><tt>ssh</tt></span><span style="color:#ff3333;">, </span><span style="color:#ff3333;"><tt>inetd</tt></span><span style="color:#ff3333;">/</span><span style="color:#ff3333;"><tt>nc</tt></span><span style="color:#ff3333;">, </span><span style="color:#ff3333;"><tt>xinetd</tt></span><span style="color:#ff3333;"> oder Firewallregeln auf Port 22 umleiten: </span>
| |
| | |
| Beispiel: siehe Kapitel 14.3.9 SSH-Tunnel (S. 84)
| |
| | |
| Dem Client gibt man entweder bei jedem Aufruf den Parameter <tt>-p 80</tt> oder trägt den Port dauerhaft in die <tt>~/.ssh/config</tt> ein:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">Host www.user.de
| |
| Port 80
| |
| User user</div>
| |
| | |
| ==== Vorhandene Proxyserver benutzen ====
| |
| | |
| Wenn der eigene Rechner (laut <tt>nmap</tt>) keinen einzigen Port im Internet erreichen, aber auf einen Proxyserver zugreifen kann, liegt doch nichts näher, als die ssh-Verbindungen über diesen Proxyserver ins Internet zu leiten.
| |
| | |
| ===== ssh over http =====
| |
| | |
| ====== httptunnel ======
| |
| | |
| <tt>httptunnel</tt> stellt einen tcp Port eines entfernten Servers lokal zur Verfügung. Für die Verbindung sorgen zwei kleine Programme (<tt>hts</tt> und <tt>htc</tt>), die im Netz wie Browser und Webserver über http kommunizieren.
| |
| | |
| [[Image:Grafik85.png|top]]
| |
| | |
| Setup:* auf dem Server (als root, weil port 80 < 1024):
| |
| | |
| | |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">hts --no-daemon --forward-port localhost:22 80</div>* auf dem Client:
| |
| | |
| | |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">htc --no-daemon --forward-port 8888 --proxy proxy:8080 --proxy-authorization user:geheim localhost:80 &
| |
| ssh -p 8888 -o NoHostAuthenticationForLocalhost=yes localhost</div>Problematisch ist zurzeit (httptunnel Version 3.3) , dass* nur eine Verbindung gleichzeitig über den Tunnel möglich ist
| |
| * ein Bug dafür sorgt, dass bei Verwendung eines Proxyservers der <tt>hts</tt> das Ende der Verbindung nicht mitbekommt. Man muß ihn nach jeder Verbindung stoppen und starten.
| |
| | |
| | |
| | |
| ====== Aus dem Alltag eines Sysadmin: Httptunnel ======
| |
| | |
| Aus dieser Zeit stammt Httptunnel. Obwohl Admins das Tool heute durch ein paar IPtables-Zeilen ersetzen könnten, bleibt es benutzerfreundlich und gehört zur Serienausstattung der meisten Distributionen.
| |
| | |
| Ich werde Httptunnel im Urlaub verwenden, der mich in zwölf Stunden nach Okzitanien bringt, einer Gegend mit netten Menschen, herrlicher Landschaft und Internetcafés, deren Betreiber unter einem Netzzugang ausschließlich HTTP verstehen.
| |
| | |
| Ich dagegen will im IRC die Ergebnisse des in Okzitanien ausgetragenen internationalen Quallenweitwurfs vermelden, also brauche ich SSH.
| |
| | |
| [[Image:Grafik87.png|top]]
| |
| | |
| [http://www.linux-magazin.de/var/linux_magazin/storage/images/media/linux-magazin/ausgabe/2009/09/coole-sau/abb1.jpg/443038-1-ger-DE/abb1.jpg_reference.jpg ]Abbildung 1: Charly legt im Frankreichurlaub einen Tunnel quer durch Firewalls, um im IRC über Quallenweitwurf berichten zu können.
| |
| | |
| HTC, die Clientkomponente von Httptunnel, lauscht auf einem Port, (der über 1024 liegen muss, wenn ich nur als User arbeite).
| |
| | |
| Dort eingehende Verbindungen verpackt der Client in HTTP und schickt sie auf einem Firewall-Piercing-fähigen Port zum Ziel. Ich versuche Port 443:
| |
| | |
| htc -w -F 4711 kintyre.kuehnast.com:443
| |
| | |
| Beim Ausprobieren hilft mir der Parameter »-w«, der verhindert, dass der Prozess sich als Daemon im Hintergrund abduckt.
| |
| | |
| Später werde ich ihn weglassen. Das »-F« steht für Forward, dahinter folgen Quelle und Ziel der Weiterleitung.
| |
| | |
| Da die Quelle ein Port auf dem Localhost ist, gebe ich keinen Hostnamen an, sondern nur den Port. Beim Ziel darf ich nicht nur IP-Adressen, sondern wie im Beispiel auch Hostnamen verwenden.
| |
| | |
| ====== Im Krebsgang ======
| |
| | |
| Auf dem Ziel läuft das Ganze rückwärts. Die Serverkomponente HTS nimmt auf dem Port 443 eingehende Verbindungen entgegen, schält sie aus dem HTTP heraus und leitet sie an den konfigurierten Zielport weiter. In dem Beispiel ist das 22, denn ich möchte ja einen SSH-Login haben: »hts -w -F localhost:22 443«.
| |
| | |
| Unlogischerweise muss ich den Zielport 22 zuerst angeben, danach den Port, auf dem HTS auf Verbindungen lauscht. Aber egal, es kann losgehen.
| |
| | |
| Auf dem Client öffne ich eine SSH-Verbindung gegen Localhost, Port 4711, mit
| |
| | |
| ssh -p 4711 charly@localhost
| |
| | |
| und kann mich auf dem Server einloggen.
| |
| | |
| Das mit dem Quallenweitwurf war natürlich ein Witz - aber seit das Languedoc nicht mehr Industriealkohol, sondern richtig gute Weine produziert, mache ich die Daheimgebliebenen anderweitig neidisch.
| |
| | |
| | |
| '''Weitere Informationen'''http://www.nocrew.org/software/httptunnel.html
| |
| | |
| ===== ssh over https =====
| |
| | |
| [[Image:Grafik86.png|top]]
| |
| | |
| ====== ssh-https-tunnel ======
| |
| | |
| Das Perlscript [http://www.snurgle.org/%7Egriffon/ssh-https-tunnel ssh-https-tunnel] weist einen Proxy-Server per CONNECT-Anweisung an, eine TCP-Verbindung zu einem remote Host zu öffnen und ermöglicht die Kommunikation dorthin über stdin/stdout.
| |
| | |
| Eine [http://www.aschemann.net/download/ssh-https-tunnel/ Erweiterung] von Gerd Aschemann <tt><gerd@aschemann.net></tt> vereinfacht die Konfiguration dahingehend, dass man den Proxyserver nicht mehr im Sourcecode eintragen muß, sondern dass dieser aus der Environment-Variable <tt>HTTP_PROXY</tt> oder der Datei <tt>~/.ssh/https-proxy.conf</tt> ausgelesen wird:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">'''HTTP_PROXY=http://proxy:8080 ./ssh-https-tunnel gate.user.de 25'''
| |
| 220 gate.user.de ESMTP Exim 3.35 #1 Fri, 13 Sep 2002 18:08:13 +0200
| |
| '''HELO abc'''
| |
| 250 gate.user.de Hello proxy.user.de [192.168.42.2]
| |
| '''QUIT'''
| |
| 221 gate.user.de closing connection</div>
| |
| | |
| Das Proxy-Log zeigt nach dem Beenden der Verbindung:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">proxy:~# '''tail -1 /var/log/squid/access.log| fmt'''
| |
| 1031933305.366 11857 192.168.42.20 TCP_MISS/200 213 CONNECT
| |
| gate.user.de:25 - DIRECT/192.168.42.1 -</div>
| |
| | |
| Durch so einen Tunnel kann man natürlich auch ssh fahren. Wenn der Proxyserver gut konfiguriert ist oder hinter einer Firewall steht, sind https-Verbindungen möglicherweise nur auf Port 443 möglich. In dem Fall reicht es, einen weiteren ssh-Dämon auf Port 443 zu starten, oder (z.B. per <tt>ssh -gL 443:localhost:22 localhost</tt> or xinetd) den Port auf den bereits auf Port 22 laufenden sshd zu forwarden.
| |
| | |
| Setup:* in <tt>~/.ssh/config</tt> folgende Zeilen anfügen:
| |
| | |
| | |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">host gate.user.de
| |
| ProxyCommand ~/.ssh/ssh-https-tunnel %h %p
| |
| Port 443</div>* den Proxyserver in die Datei <tt>~/.ssh/https-proxy.conf</tt> eintragen:
| |
| | |
| | |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">host=proxy
| |
| port=8080</div>
| |
| | |
| Und schon läuft die Verbindung über den Proxyserver an den ssh-Dämon, der auf <tt>gate</tt> auf Port 443 lauscht:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">'''ssh -v gate.user.de'''
| |
| OpenSSH_3.4p1 Debian 1:3.4p1-2, SSH protocols 1.5/2.0, OpenSSL 0x0090605f
| |
| debug1: Reading configuration data /export/home/user/.ssh/config
| |
| debug1: Applying options for gate.user.de
| |
| debug1: Applying options for *
| |
| […]
| |
| debug1: Executing proxy command: ~/.ssh/ssh-https-tunnel gate.user.de 443
| |
| […]
| |
| debug1: Remote protocol version 1.99, remote software version OpenSSH_2.9.9p2
| |
| […]
| |
| Last login: Fri Sep 13 18:28:31 2002 from p5080d740.dip.t-dialin.net
| |
| Have a lot of fun...</div>
| |
| | |
| ====== transconnect ======
| |
| | |
| <tt>transconnect</tt> ist eine C-Bibliothek, welche die connect-Funktion der glibc ersetzt, so dass der Verbindungsaufbau per https über einen Proxyserver läuft. Das funktioniert damit nur für dynamisch gelinkte Binaries (das kann man mit <tt>ldd</tt> prüfen). Der Vorteil gegenüber einem vorher einzurichtenden Tunnel liegt darin, dass die Anwendung flexibel in der Auswahl des Ports ist.
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">'''LD_PRELOAD=~/.tconn/tconn.so netcat localhost daytime'''
| |
| Sat Sep 14 11:25:49 2002</div>
| |
| | |
| [http://transconnect.sourceforge.net/ transconnect Project Home Page]
| |
| | |
| ====== proxytunnel ======
| |
| | |
| <tt>proxytunnel</tt> ist ein C-Programm, das mit Hilfe einer https-Verbindung zu einem Proxyserver einen remote Port wahlweise als Pipe oder lokalen Port verfügbar macht. Letzteren kann man sogar entweder als Daemon oder (automatisch bei Bedarf) über inetd/tcpd bereitstellen.
| |
| | |
| Die Syntax ist einfach:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">'''./proxytunnel-linux-i386 --help'''
| |
| Proxytunnel 1.1.0
| |
| Jos Visser (Muppet) <josv@osp.nl>, Mark Janssen (Maniac) <maniac@maniac.nl>
| |
|
| |
| Purpose:
| |
| Build generic tunnels trough HTTPS proxy's, supports HTTP authorization
| |
|
| |
| Usage: Proxytunnel [OPTIONS]...
| |
| -h --help Print help and exit
| |
| -V --version Print version and exit
| |
| -c --config=FILE Read config options from file (FIXME)
| |
| -i --inetd Run from inetd (default=off)
| |
| -a INT --standalone=INT Run as standalone daemon on specified port
| |
| -f --nobackground Don't for to background in standalone mode (FIXME)
| |
| -u STRING --user=STRING Username to send to HTTPS proxy for auth
| |
| -s STRING --pass=STRING Password to send to HTTPS proxy for auth
| |
| -g STRING --proxyhost=STRING HTTPS Proxy host to connect to
| |
| -G INT --proxyport=INT HTTPS Proxy portnumber to connect to
| |
| -d STRING --desthost=STRING Destination host to built the tunnel to
| |
| -D INT --destport=INT Destination portnumber to built the tunnel to
| |
| -n --dottedquad Convert destination hostname to dotted quad
| |
| -v --verbose Turn on verbosity (default=off)
| |
| -q --quiet Suppress messages (default=off)
| |
|
| |
| Examples:
| |
| Proxytunnel [ -h | -V ]
| |
| Proxytunnel -i [ -u user -s pass ] -g host -G port -d host -D port [ -n ] [ -v | -q ]
| |
| Proxytunnel -a port [ -u user -s pass ] -g host -G port -d host -D port [ -n ] [ -v | -q ]</div>
| |
| | |
| Beispiele zur Verwendung* als pipe:
| |
| | |
| | |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">'''ssh -o ProxyCommand=./proxytunnel-linux-i386 -g proxy -G 8080 -d %h -D %p' gate'''
| |
| Connected to proxy:8080
| |
| Starting tunnel
| |
| Linux gate 2.2.19 #5 Wed May 1 20:15:01 CEST 2002 i586 unknown
| |
| You have mail.
| |
| Last login: Sat Sep 14 10:38:58 2002 from tp.user.de</div>* als portforwarder:
| |
| | |
| | |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">'''./proxytunnel-linux-i386 -a 8888 -g proxy -G 8080 -d localhost -D 22'''
| |
| Forked into the background with pid 1524
| |
| '''ssh -p 8888 -o NoHostAuthenticationForLocalhost=yes localhost'''
| |
| Last login: Sat Sep 14 10:54:42 2002 from gate.user.de</div>
| |
| | |
| Das kann man natürlich auch dauerhaft in <tt>~/.ssh/config</tt> konfigurieren:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">Host gate-via-proxy
| |
| Hostname gate.user.de
| |
| ProxyCommand "proxytunnel-linux-i386 -g proxy -G 3128 -d %h -D %p"</div>
| |
| | |
| | |
| '''Weitere Informationen'''http://proxytunnel.sourceforge.net/
| |
| | |
| ==== Empfehlungen ====
| |
| | |
| Der beste Schutz vor ungewollten ssh-Verbindungen ins Internet besteht darin, den Internetzugriff im LAN zu verbieten und beispielsweise den Browser aus einer DMZ über X11, Citrix Metaframe, VNC o.ä. auf dem Client darzustellen.
| |
| | |
| === SSH per Socket beschleunigen ===
| |
| | |
| If you connect twice or more to the same server and you don’t want to reauthenticate again, you can use a socket to bypass it. You need OpenSSH 4.x or higher.
| |
| | |
| ==== Normale Situation ====
| |
| | |
| ===== Erste Sitzung =====
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">$ ssh ruben@pc-rgonzalez
| |
| ruben@pc-rgonzalez’s password:</div>
| |
| | |
| ===== Zweite Sitzung =====
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">ssh user@pc
| |
| user@pc password:</div>
| |
| | |
| This is the normal behavior, so you need the put credentials twice. Using ssh socket feature bypass it, so on the CLIENT side you need to add these lines.
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">/etc/ssh/ssh_config
| |
| <nowiki># socket speed up</nowiki>
| |
| Host *
| |
| ControlMaster auto
| |
| ControlPath ~/.ssh/socket-%r@%h:%p</div>
| |
| | |
| ==== Verbesserte Situation ====
| |
| | |
| ===== Erste Sitzung =====
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">$ ssh user@pc
| |
| user@pc password:</div>
| |
| | |
| ===== Zweite Sitzung =====
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">$ ssh user@pc
| |
| $ (no password needed!)</div>
| |
| | |
| It’s also create a socket in your home like this:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">file /home/user/.ssh/socket-user\@pc\:22
| |
| /home/user/.ssh/socket-user@pc-user:22: socket</div>
| |
| | |
| If you close your ssh session , socket will be deleted until you create a new one using another ssh session. It works nice if you need to exec a command behind a firewall like:
| |
| | |
| (create a session in background, it also creates the socket)
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">$ ssh -N -f user@firewall</div>
| |
| | |
| then
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">ssh user@firewall “ssh -t user@anothermachine”
| |
| ssh user@firewall “ssh -t user@anothermachine2″
| |
| etc ...</div>
| |
| | |
| == Konfiguration ==
| |
| | |
| === Überblick ===
| |
| | |
| [[Image:Grafik39.png|right|middle]]
| |
| | |
| === Client-Konfiguration ===
| |
| | |
| Der ssh-Client liest seine Konfiguration aus * Kommandozeilenparametern
| |
| * <tt>~/.ssh/config</tt>
| |
| * <tt>/etc/ssh/ssh_config</tt>
| |
| | |
| | |
| | |
| Der erste Treffer zählt. Die config-Dateien erlauben die Definition von Host-Bereichen. z.B.:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">Host stunnel.our-isp.org
| |
| ProxyCommand ~/.ssh/ssh-https-tunnel %h %p
| |
| Port 443
| |
|
| |
| Host hera 141.*
| |
| User franken
| |
| Protocol 1
| |
|
| |
| Host 192.* gate mausi localhost tp
| |
| Compression no
| |
| Cipher blowfish
| |
| Protocol 2
| |
|
| |
| Host *
| |
| ForwardAgent yes
| |
| ForwardX11 yes
| |
| Compression yes
| |
| Protocol 2,1
| |
| Cipher 3des
| |
| EscapeChar ~</div>
| |
| | |
| Wenn man sich auf der Konsole mit einem anderen Server verbinden möchte, muss man evtl. z.B. Port und Benutzernamen angeben. Um das Ganze zu vereinfachen, kann man Voreinstellungen für ssh in der config-Datei '''$HOME/.ssh/config''' hinterlegen. Hier ein Beispiel:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;"><nowiki># ssh (secure shell) configuration file</nowiki>
| |
| Host test1
| |
| HostName 123.456.789.0
| |
| Port 980
| |
| User MeinBenutzerName
| |
| Host test2
| |
| HostName test.mynet.local
| |
| User test
| |
| CheckHostIP no
| |
| Cipher blowfish</div>
| |
| | |
| Nun reicht ein kurzer Befehl für den Verbindungsaufbau:
| |
| | |
| ssh test1 <nowiki># statt</nowiki>
| |
| ssh MeinBenutzerName@123.456.789.0 -p980
| |
| | |
| Die Manpage von [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh_config ssh_config(5)] enthält eine vollständige Übersicht aller Direktiven.
| |
| | |
| === Server-Konfiguration ===
| |
| | |
| Der ssh-Server liest seine Konfiguration aus* Kommandozeilenparametern und
| |
| * <tt>/etc/ssh/sshd_config</tt>
| |
| | |
| | |
| | |
| Der erste Treffer zählt.
| |
| | |
| ==== Konfiguration des Servers in sshd_config ====
| |
| | |
| Die zentrale Konfigurationsdatei des SSH-Servers '''sshd''' liegt in <tt>/etc/ssh/sshd_config</tt> (in älteren Versionen auch direkt in <tt>/etc/sshd_config</tt>).
| |
| | |
| Diese Datei enthält alle nötigen Einstellungen des Servers. Jede Zeile (die nicht leer oder Kommentar ist) besteht aus einem Schlüsselwort (Gross/Kleinschreibung wird nicht unterschieden) und einem Wert (Gross/Kleinschreibung wird unterschieden).
| |
| | |
| ===== Die wichtigsten Konfigurationsbefehle =====
| |
| | |
| ====== Allgemeine Einstellungen ======
| |
| | |
| '''Port ''Portnummer'''''
| |
| | |
| Gibt die Portnummer an, auf der '''sshd''' lauschen soll. Voreingestellt ist Port 22. Es können mehrere dieser Anweisungen angegeben sein, wenn sshd auf mehreren Ports arbeiten soll.
| |
| | |
| '''Protocol ''Protokollnummer(n)'''''
| |
| | |
| Gibt das SSH-Protokoll an, mit dem gearbeitet werden soll. Mögliche Werte sind 1 oder 2. Wenn mehrere Protokolle verwendet werden sollen, dann müssen sie durch Kommas getrennt angegeben werden. Voreingestellt ist 2,1.
| |
| | |
| '''HostKey ''Dateiname'''''
| |
| | |
| Gibt den Dateinamen mit Pfad des Private-Host-Keys an. Voreingestellt sind die oben genannten Dateinamen. Es können mehrere dieser Anweisungen in der Datei enthalten sein, etwa um die drei verschiedenen Schlüsseltypen für rsa1, rsa und dsa zu spezifizieren. sshd weigert sich die angegebenen Dateien zu benutzen, wenn sie Dateien für Gruppen oder Rest lesbar sind. Sie sollten also ein Zugriffsrecht von 600 besitzen.
| |
| | |
| '''KeepAlive <tt>yes|no'''</tt>
| |
| | |
| Gibt an, ob der Server TCP-KeepAlive Meldungen an den Client schicken soll. Wenn solche Meldungen geschickt werden, so kann erkannt werden, ob eine Verbindung physikalisch abgebrochen wurde oder einer der Kommunikationspartner abgestürzt ist.
| |
| | |
| Allerdings heisst das auch, dass eine Verbindung abbricht, wenn kurzzeitig eine Route ausfällt. Auf der anderen Seite wird so vermieden, dass sich Sessions aufhängen und trotzdem Reste im System hängenbleiben. Voreingestellt ist yes (KeepAlive Meldungen werden geschickt).
| |
| | |
| ===== Authentifizierungsbefehle =====
| |
| | |
| '''LoginGraceTime ''Sekunden'''''
| |
| | |
| Der Server trennt die Verbindung nach der angegebenen Anzahl von Sekunden, wenn ein User sich bis dahin nicht erfolgreich eingeloggt hat. Voreingestellt sind 600 (Sekunden). Steht hier eine 0, dann gibt es kein Zeilimit.
| |
| | |
| '''PermitRootLogin <tt>yes|no|without-password|forced-commands-only'''</tt>
| |
| | |
| Gibt an, ob und wie sich der Systemverwalter über ssh einloggen darf. Voreingestellt ist yes. Steht diese Einstellung auf <tt>without-password</tt>, so wird die Passwortabfrage für root abgeschalten. Das bedeutet, er kann sich nur einloggen, wenn er über ein entsprechend anderes Authentifizierungsverfahren verfügt. Steht der Wert auf <tt>forced-commands-only</tt>, so darf root nur Befehle ausführen (die an den ssh-Befehl angehängt werden), sich aber nicht regulär einloggen.
| |
| | |
| '''RhostsAuthentication <tt>yes|no'''</tt>
| |
| | |
| Gibt an, ob Authentifizierung über <tt>.rhosts</tt> oder <tt>/etc/hosts.equiv</tt> erlaubt sein soll. Voreingestellt ist no. Diese Option gilt nur für Protokollversion 1.
| |
| | |
| '''RhostsRSAAuthentication <tt>yes|no'''</tt>
| |
| | |
| Gibt an, ob Authentifizierung über <tt>.rhosts</tt> oder <tt>/etc/hosts.equiv</tt> zusammen mit RSA Host-Authentifizierung erlaubt sein soll. Voreingestellt ist no. Diese Option gilt nur für Protokollversion 1.
| |
| | |
| '''RSAAuthentication <tt>yes|no'''</tt>
| |
| | |
| Gibt an, ob reine RSA Authentifizierung erlaubt sein soll. Voreingestellt ist yes. Diese Option gilt nur für Protokollversion 1.
| |
| | |
| '''HostbasedAuthentication <tt>yes|no'''</tt>
| |
| | |
| Gibt an, ob Authentifizierung über <tt>.rhosts</tt> oder <tt>/etc/hosts.equiv</tt> zusammen mit RSA Host-Authentifizierung erlaubt sein soll. Voreingestellt ist no. Diese Option gilt nur für Protokollversion 2 und entspricht der Einstellung von '''RhostsRSAAuthentication''' für Version 1.
| |
| | |
| '''PubkeyAuthentication <tt>yes|no'''</tt>
| |
| | |
| Gibt an, ob Authentifizierung über Public-Keys erlaubt sein soll. Voreingestellt ist yes. Diese Option gilt nur für Protokollversion 2.
| |
| | |
| '''IgnoreRhosts <tt>yes|no'''</tt>
| |
| | |
| Gibt an, dass die Dateien <tt>.rhosts</tt> und <tt>.shosts</tt> nicht verwendet werden dürfen, wenn '''RhostsAuthentication, RhostsRSAAuthentication''' oder '''HostbasedAuthentication''' verwendet werden. Die Dateien <tt>/etc/hosts.equiv</tt> und <tt>/etc/shosts.equiv</tt> werden weiterhin abgearbeitet.
| |
| | |
| '''PasswordAuthentication <tt>yes|no'''</tt>
| |
| | |
| Gibt an, ob Authentifizierung über Passwörter erlaubt ist. Voreingestellt ist yes.
| |
| | |
| '''PermitEmptyPasswords <tt>yes|no'''</tt>
| |
| | |
| Gibt an, ob es bei erlaubtem '''PasswordAuthentication''' auch erlaubt sein soll, wenn User leere Passwörter haben. Voreingestellt ist no.
| |
| | |
| '''AllowUsers ''Muster|Liste'''''
| |
| | |
| Hier kann eine durch Leerzeichen getrennte Liste von Usernamen/Mustern angegeben werden. Nur die hier angegebenen User dürfen sich einloggen. Für die Musterbildung stehen * und ? zur Verfügung wie auf der Shell. Es werden nur Namen, keine UserIDs interpretiert. Möglich ist auch, Einträge in der Form ''Username@Hostname'' zu machen, um nur User von bestimmten Rechnern aus zuzulassen. Voreingestellt ist, dass alle User sich einloggen dürfen.
| |
| | |
| '''AllowGroups ''Muster|Liste'''''
| |
| | |
| Hier kann eine durch Leerzeichen getrennte Liste von Gruppennamen/Mustern angegeben werden. Nur User, die Mitglied der hier angegebenen Gruppen sind, dürfen sich einloggen. Für die Musterbildung stehen * und ? zur Verfügung wie auf der Shell. Es werden nur Namen, keine GroupIDs interpretiert. Voreingestellt ist keine Einschränkung auf bestimmte Gruppen.
| |
| | |
| ===== Tunneling Optionen =====
| |
| | |
| '''AllowTcpForwarding <tt>yes|no'''</tt>
| |
| | |
| Gibt an, ob TCP-Forwarding erlaubt sein soll. Voreingestellt ist yes. Nachdem sich jeder User mit Shellzugriff seine eigenen Forwarder installieren kann, macht eine Einschränkung dieser Einstellung nur dann Sinn, wenn der User keinen Shellzugriff hat.
| |
| | |
| '''X11Forwarding <tt>yes|no'''</tt>
| |
| | |
| Gibt an, ob X11-Forwarding erlaubt sein soll. Voreingestellt ist no.
| |
| | |
| '''X11UseLocalhost <tt>yes|no'''</tt>
| |
| | |
| Gibt an, ob '''sshd''' den (virtuellen) X11-Forwarding Server an die Loopback-Adresse binden soll, oder an die Wildcard-Adresse. Voreingestellt ist yes (Loopback-Adresse). Damit wird der Hostnamenteil der DISPLAY-Variable auf <tt>localhost</tt> gesetzt. Damit wird verhindert, dass fremde Clients auf den virtuellen X-Server zugreifen können. Allerdings können ein paar ältere X11-Clients mit dieser Einstellung Schwierigkeiten haben. In diesem Fall kan diese Einstellung auf no gesetzt werden.
| |
| | |
| '''X11DisplayOffset ''Zahl'''''
| |
| | |
| Gibt die Servernummer für den virtuellen X-Server an, um Verwechslungen mit echten X-Servern zu vermeiden. Voreingestellt ist 10.
| |
| | |
| '''XAuthLocation ''Pfad'''''
| |
| | |
| Gibt den Pfad zum '''xauth''' Programm an. Voreingestellt ist <tt>/usr/bin/X11/xauth</tt>.
| |
| | |
| Natürlich muss der SSH-Daemon '''sshd''' nach einer Veränderung der Konfigurationsdatei entweder neu gestartet werden, oder es wird ihm ein HUP-Signal geschickt, das den Server zwingt, die Konfigurationsdatei neu zu laden.
| |
| | |
| '''Weitere Informationen'''
| |
| | |
| sshd(8), sshd_config(5)
| |
| | |
| === Start des Servers ===
| |
| | |
| Um auf einen Rechner mit SSH zugreifen zu können, muss auf diesem ein SSH-Server gestartet, konfiguriert und und erreichbar sein. Die Konfiguration des SSH-Servers '''sshd''' findet über die Datei '''/etc/ssh/sshd_config''' statt. Die Voreinstellungen sind aber durchweg akzeptabel.
| |
| | |
| Wer den '''sshd''' auf einem Gateway oder Router betreibt oder aus einem anderen Grund mehrere Netzwerkschnittstellen verwendet (bspw. WLAN), der möchte dort vielleicht die '''ListenAddress'''-Direktive benutzen, um den Server nur an bestimmten Netzwerk-Schnittstellen laufen zu lassen.
| |
| | |
| Außerdem kann es sinnvoll sein, '''PermitRootLogin''' auf '''no''' zu setzen. Dann kann sich niemand direkt als ''root'' einloggen, sondern man meldet sich unter seinem Benutzernamen an und ruft dann '''su''' oder '''sudo -s''' auf.
| |
| | |
| Mit den Direktiven '''AllowUsers''' und '''AllowGroups''' bzw. '''DenyUsers''' und '''DenyGroups''' lässt sich noch genauer festlegen, welche Benutzer sich anmelden dürfen und welche nicht.
| |
| | |
| Dies empfiehlt sich besonders bei Servern. '''AllowGroups admin''' verbietet bspw. allen Benutzern, die keine Mitglieder der Gruppe ''admin'' sind, den Zugriff. Wer sich ausschließlich über das noch sicherere [[#Authentifizierung-ueber-Public-Keys|Public-Key-Verfahren]] anmelden will, der sollte die Benutzung von Passwörtern mit '''PasswordAuthentication no''' abschalten.
| |
| | |
| Falls lange Wartezeiten bei der Anmeldung am SSH-Server auftreten, könnte das an einer fehlgeschlagenen Namensauflösung liegen. Da man SSH normalerweise sowieso über die IP benutzt, können diese DNS-Anfragen in der '''sshd_config''' deaktiviert werden. Der dafür nötige Eintrag wäre '''UseDNS no'''.
| |
| | |
| Nach erfolgter Änderung der Datei '''sshd_config''' muss der Server mit dem Befehl:
| |
| | |
| <nowiki># /etc/init.d/sshd restart</nowiki>
| |
| | |
| neugestartet werden, damit die Änderungen wirksam werden.
| |
| | |
| ==== Opensuse ====
| |
| | |
| Da Linux ein Netzwerkbetriebssystem ist, ist der ssh-Server auf jeder Distribution bereits vorinstalliert, aber bei SUSE per default ausgeschaltet.
| |
| | |
| Bei Suse startet man den ssh-Daemon unter Yast -> System -> Systemdienste (Runlevel); hierzu sshd starten. Den SSH-Server konfiguriert man am besten mit Yast. Dazu installieren wir uns das Paket: yast2-sshd
| |
| | |
| Unter Yast -> Netzwerkdienste -> SSHD-Einrichtung können wir ssh einrichten.* Im Register Allgemein lassen wir die Standardeinstellungen und aktivieren den Haken bei Firewall freigeben.
| |
| * Im Register Anmeldeeinstellungen entfernen wir als erstes aus Sicherheitsgründen den Root-Zugriff.
| |
| * Zusätzlich aktivieren wir für einen ersten Test RSA Authentication; dies bewirkt, dass wir uns auf dem entfernten Rechner mit unseren normalen Benutzerdaten dort einloggen können.
| |
| * Später sichern wir unseren SSH-Server ab und lassen nur noch das PublikKey Authentication zu, was dann ein Hacken von ausserhalb unmöglich machen wird.
| |
| | |
| | |
| | |
| == Troubleshooting ==
| |
| | |
| === Sitzung friert ein oder wird beendet ===
| |
| | |
| Dies kann durch NAT-Router (beendet die TCP-Verbindung wegen Inaktivität) oder restriktive Serverkonfiguration (Abbau inaktiver Sitzungen) verursacht werden.
| |
| | |
| Mit '''ClientAliveInterval''' in [http://www.openbsd.org/cgi-bin/man.cgi?query=sshd_config&sektion=5 sshd_config] am Server oder '''ServerAliveInterval''' in [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh_config&sektion=5 ssh_config] am Client kann dieses Problem gelöst werden. Die Einstellung sollte kleiner sein, als die Zeit bis zum Abbruch der Sitzung.
| |
| | |
| === usermapping ===
| |
| | |
| -o idmap=user
| |
| | |
| === Verbindung kann nicht aufgebaut werden ===
| |
| | |
| * Server ist nicht gestartet
| |
| * Port an der Firewall ist nicht freigeschaltet
| |
| * SSHGuard (o.ä.) ist aktiv und es gab zu viele fehlerhafte Login-Versuche
| |
| | |
| | |
| | |
| === SSH bleibt beim Logout hängen ===
| |
| | |
| Bei dem Befehl
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">'''ssh host command''' </div>
| |
| | |
| '''muss''' ssh abwarten bis sicher ist, * dass <tt>command</tt> keine Eingaben mehr erfordert
| |
| * dass <tt>command</tt> keine Ausgabe mehr produziert
| |
| * bis <tt>command</tt> beendet wird, denn sshd muss den Rückgabewert von <tt>command</tt> ssh melden
| |
| | |
| | |
| | |
| === Public-Key Authentifizierung funktioniert nicht ===
| |
| | |
| Eine typische Ursache sind zu großzügige Zugriffsrechte auf $HOME, $HOME/.ssh oder $HOME/.ssh/authorized_keys. In diesem Fall kann das Problem wie folgt gelöst werden:
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">'''chmod go-w $HOME $HOME/.ssh'''
| |
| $ '''chmod 600 $HOME/.ssh/authorized_keys'''
| |
| $ '''chown $(whoami) $HOME/.ssh/authorized_keys'''</div>
| |
| | |
| Alternativ kann '''StrictModes no''' in ''sshd_config'' gesetzt werden. Dies wird jedoch nicht empfohlen.
| |
| | |
| === Probleme bei verschlüsseltem Home-Verzeichnis ===
| |
| | |
| Bei verschlüsselten Home-Verzeichnissen (ecryptfs) ist die Datei <tt>authorized_keys</tt> verschlüsselt. Somit kann sie zur Authentifizierung verwendet werden, solange das Home-Verzeichnis nicht entschlüsselt ist (durch parallele Anmeldung mit dem gleichen Benutzernamen).
| |
| | |
| Abhilfe ist z.B. die Datei <tt>authorized_keys</tt> in ein nicht-verschlüsseltes Verzeichnis zu legen (z.B. /etc/ssh/username/) und die Einstellung ''AuthorizedKeysFile'' in der <tt>/etc/ssh/sshd_config</tt> auf ''/etc/ssh/%u/authorized_keys'' zu ändern (Root-Rechte und Neustart des SSH-Daemons erforderlich).
| |
| | |
| <nowiki># </nowiki>'''mkdir /etc/ssh/$USER'''
| |
| <nowiki># </nowiki>'''mv $HOME/.ssh/authorized_keys /etc/ssh/$USER/'''
| |
| $ '''ln -s /etc/ssh/$USER/authorized_keys $HOME/.ssh/ '''
| |
| | |
| === Probleme von SSH 2.3 mit OpenSSH 2.1.1 ===
| |
| | |
| SSH 2.3 und frühere Versionen haben einen Fehler in ihrer HMAC-Implementation. Ihr Code hat nicht die komplette Ausgabe des Datenblocks von der Auswahl bereitgestellt, sondern stattdessen eben nur 128 Bits. Bei längeren Anfragen konnte dann SSH 2.3 eben nicht mit OpenSSH zusammenarbeiten.
| |
| | |
| OpenSSH 2.2.0 erkennt, dass SSH 2.3 diesen Fehler hat. In zukünftigen Versionen von SSH wird dieser Fehler behoben sein. Alternativ kannst du das folgende in deine /etc/sshd2_config von SSH 2.3 einfügen.
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">Mac hmac-md5 </div>
| |
| | |
| === setuid root de ssh-Clients ===
| |
| | |
| In Verbindung mit der vorhergehenden Frage ([http://openssh.org/de/faq.html#2.1 2.1]) braucht OpenSSH root-Autorität, um sich an die unteren und privilegierten Ports binden zu können, um dann eine rhosts-Authentifikation durchzuführen. Genauso notwendig ist dieser privilegierte Port für rhosts-rsa-Authentifikation zu älteren SSH-Versionen.
| |
| | |
| Zusätzlich gilt sowohl für rhosts-rsa-Authentifikation (in Protokollversion 1) als auch für hostbasierte Authentifikation (in Protokollversion 2), dass der ssh-Client Zugang zum ,private host key' braucht, um die Clientmaschine am Server anzumelden. OpenSSH-Versionen vor 3.3 benötigten ein gesetztes setuid-Bit für die Binärdatei von <tt>ssh</tt>, um das zu erreichen, aber du kannst das Bit löschen, wenn du diese Authentifizierungsmethoden nicht benutzen willst.
| |
| | |
| Beginnend mit OpenSSH 3.3 ist <tt>ssh</tt> standardmäßig nicht setuid. [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-keysign ssh-keysign] wird benutzt, um die privaten Hostschlüssel auszulesen, und ssh benutzt standardmäßig keine privilegierten Quellports. Wenn du doch einen benutzen willst, musst du das setuid-Bit von <tt>ssh</tt> per Hand setzen.
| |
| | |
| === Dispatch protocol error: type 20 ===
| |
| | |
| Probleme bei der Zusammenarbeit treten auf, weil ältere Versionen von OpenSSH noch keine Unterstützung für ,session rekeying' hatten. Das kommerzielle SSH 2.3 versucht diese Funktionalität abzulehnen, und es kann zum Einfrieren der Verbindung kommen, oder die Fehlermeldung ,Dispatch protocol error: type 20 ' kann zu lesen sein. Das Problem wird entweder durch ein Upgrade auf eine aktuelle OpenSSH-Version oder Abschalten des ,rekeying' durch Hinzufügen des folgenden in die ssh2_config oder sshd2_config vom kommerziellen SSH 2.3 behoben.
| |
| | |
| RekeyIntervalSeconds 0
| |
| | |
| === IDEA verschlüsselte Hostkeys ===
| |
| | |
| Die alten Versionen von SSH haben einen patentierten Algorithmus benutzt, um ihren /etc/ssh/ssh_host_key zu verschlüsseln. Das Problem manifestiert sich darin, dass der [http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8 sshd(8)] seinen Hostschlüssel nicht lesen kann. Um das Problem zu lösen, benutze das Kommando weiter unten, um deinen ssh_host_key zu 3DES zu konvertieren. HINWEIS: Benutze das [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-keygen&sektion=1 ssh-keygen(1)]-Programm von dem kommerziellen SSH-Produkt und *NICHT* OpenSSH für das Beispiel weiter unten.
| |
| | |
| <nowiki># ssh-keygen -u -f /etc/ssh/ssh_host_key </nowiki>
| |
| | |
| === Warnungen über Schlüssellängen? ===
| |
| | |
| Das [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-keygen&sektion=1 ssh-keygen(1)] des kommerziellen SSH-Programms hat einen Fehler beinhaltet, der dazu führte, dass es von Zeit zu Zeit ,Pubkey'-Authentifikationsschlüssel (RSA oder DSA) generiert hat, deren ,Most Significant'-Bit (MSB) nicht gesetzt war. Solche Schlüssel wurden zwar als ,mit voller Länge' angekündigt, waren aber die Hälfte der Zeit über kleiner als angekündigt.
| |
| | |
| OpenSSH wird Warnungen ausgeben, wenn es solchen Schlüsseln begegnet. Um diese Warnungen loszuwerden, passe deine known_hosts-Datei an und ersetze die falsche Schlüssellänge (normalerweise ,1024') mit der richtigen (normalerweise ,1023').
| |
| | |
| === X11/Agent-Weiterleitung funktioniert nicht ===
| |
| | |
| Prüfe deine ssh_config und sshd_config. Die voreingestellten Konfigurationsdateien schalten den Authentifikationsagenten und X11-Weiterleitung ab. Füge die Zeilen unten in die sshd_config ein, um sie zu aktivieren:
| |
| | |
| X11Forwarding yes
| |
| | |
| und füge die folgenden Zeilen in die ssh_config ein:
| |
| | |
| ForwardAgent yes
| |
| ForwardX11 yes
| |
| | |
| X11-Weiterleitung setzt eine funktionierende [http://www.openbsd.org/cgi-bin/man.cgi?query=xauth&sektion=1 xauth(1)]-Binary voraus. Unter OpenBSD befindet sie sich im xbase-Dateiset, was auf anderen Plattformen jedoch nicht der Fall sein muss. Für die portable OpenSSH muss xauth entweder während dem configure-Aufruf gefunden werden oder später mittels XauthLocation in der sshd_config(5) und ssh_config(5) angegeben werden.
| |
| | |
| Hinweis zur Agenten-Interoperabilität: Es gibt zwei unterschiedliche und inkompatible Agentweiterleitung-Mechanismen innerhalb des SSH2-Protokolls. OpenSSH hat immer eine Erweiterung der originalen SSH1-Agent-Anfragen genutzt, jedoch verwenden einige kommerzielle Produkte ein anderes, nicht freies Agentweiterleitungsprotokoll. Dies bedeutet, dass Agentweiterleitung nicht zwischen OpenSSH und diesen kommerziellen Produkten genutzt werden kann.
| |
| | |
| HINWEIS: Benutzer von Linux Mandrake 7.2: Mandrake modifiziert die XAUTHORITY-Umgebungsvariable in /etc/skel/.bashrc und damit das Heimatverzeichnis jedes Bash-Benutzers. Diese Variable wird von OpenSSH gesetzt und daher muss für die oben genannten Optionen die folgende Zeile auskommentiert werden:
| |
| | |
| <nowiki># export XAUTHORITY=$HOME/.Xauthority </nowiki>
| |
| | |
| === Keine SSH2-Unterstützung ===
| |
| | |
| Die Dateien sshd_config oder ssh_config können von Version zu Version verändert werden. Du solltest immer nach solchen Änderungen Ausschau halten, wenn du auf eine neue Version von OpenSSH upgradest. Nach OpenSSH 2.3.0 musst du das folgende in deine sshd_config einfügen:
| |
| | |
| HostKey /etc/ssh_host_dsa_key
| |
| HostKey /etc/ssh_host_rsa_key
| |
| | |
| === sftp/scp kann keine Verbindung aufbauen ===
| |
| | |
| '''obwohl ssh funktioniert'''
| |
| | |
| sftp und/oder scp können beim Aufbauen der Verbindung Probleme haben, wenn du eine Shellinitialisierung (.profile, .bashrc, .chsrc etc.) hast, die Ausgaben für nicht interaktive Sitzungen produziert. Diese Ausgabe verwirrt den sftp/scp-Client. Hiermit kannst du prüfen, ob deine Shell das tut:
| |
| | |
| ssh yourhost /usr/bin/true
| |
| | |
| Wenn das Kommando oben irgendeine Art von Ausgabe produziert, musst du deine Shellinitialisierung modifizieren.
| |
| | |
| === ssh-Verbindung friert ein oder steigt aus ===
| |
| | |
| ===== ssh-Verbindung friert ein oder steigt nach N Minuten Inaktivität aus =====
| |
| | |
| Das ist üblicherweise das Resultat eines Paketfilters oder einem NAT-Gerät, das die TCP-Verbindung wegen Inaktivität auslaufen lässt. Du kannst ClientAliveInterval in der [http://www.openbsd.org/cgi-bin/man.cgi?query=sshd_config&sektion=5 sshd_config] des Servers aktivieren oder ServerAliveInterval in der [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh_config&sektion=5 ssh_config] des Clients ermöglichen (die letzte Option ist in OpenSSH 3.8 und neuer verfügbar).
| |
| | |
| Das Aktivieren einer der beiden Optionen und das Setzen des Intervalls, das kürzer als die benötigte Zeit ist, um die Verbindung auslaufen zu lassen, sorgen dafür, dass die Verbindung in der Verbindungstabelle des Gerätes ,frisch' gehalten wird.
| |
| | |
| === scp - Datei mit Doppelpunkt ===
| |
| | |
| [http://www.openbsd.org/cgi-bin/man.cgi?query=scp&sektion=1 scp] interpretiert den Teil vor dem Doppelpunkt als Namen des entfernten Servers und versucht, eine Verbindung zu diesem aufzubauen. Um das zu verhindern, greife auf die Datei mit relativer oder absoluter Pfadangabe zu, z. B.:
| |
| | |
| $ scp ./source:file sshserver:
| |
| | |
| === OpenSSH teilt Clients seine Version mit ===
| |
| | |
| OpenSSH, wie die meisten SSH-Implementationen, teilt seinen Namen und seine Version den Clients mit, wenn sie eine Verbindung aufbauen, z. B.
| |
| | |
| ''SSH-2.0-OpenSSH_3.9 ''
| |
| | |
| Diese Information wird von den Clients und Servern verwendet, um Protokollkompatibilitätskniffe zu aktiveren, die veränderte, fehlerhafte oder fehlende Funktionen in der Implementation, mit der sie reden, zu umgehen. Dieser Protokollfunktionstest ist weiterhin nötig, weil noch immer Versionen mit Inkompatibilitäten im Umlauf sind.
| |
| | |
| === Unechte PAM-Authentifikationsmeldungen in den Logdateien ===
| |
| | |
| Die portable Version von OpenSSH generiert unechte misslungene Authentifikationsmeldungen bei jedem Login, etwa wie:
| |
| | |
| "authentication failure; (uid=0) -> root for sshd service"
| |
| | |
| Diese werden erzeugt, weil OpenSSH zuerst versucht herauszufinden, ob der Anwender eine Authentifikation zum Login benötigt (z. B. leeres Passwort). Dummerweise logt PAM alle Authentifikationversuche, inklusive diesem hier.
| |
| | |
| Wenn es dich zu sehr stört, setze »PermitEmptyPasswords no« in sshd_config. Das wird die Meldung stilllegen, allerdings auf Kosten dessen, dass es nicht mehr möglich ist, sich in Accounts mit leeren Passwörtern einzuloggen. Das ist im übrigen bereits der Standard, wenn du die mitgelieferte sshd_config-Datei benutzt.
| |
| | |
| === Leere Passwörter sind bei der PAM-Authentifikation nicht erlaubt ===
| |
| | |
| Um leere Passwörter in einer OpenSSH-Version zu erlauben, die mit PAM erzeugt wurde, musst du das ,nullok'-Flag an das Ende des Password-Checking-Moduls in der /etc/pam.d/sshd-Datei setzen. Zum Beispiel:
| |
| | |
| auth required/lib/security/pam_unix.so shadow nodelay nullok
| |
| | |
| Das muss zusätzlich zum Setzen von »PermitEmptyPasswords yes« in der sshd_config-Datei geschehen.
| |
| | |
| Es gibt einen Fallstrick beim Benutzen leerer Passwörter mit PAM-Authentifikation: PAM wird jegliches Passwort erlauben, wenn ein Account mit einem leeren Passwort authentifiziert wird. Das macht den Check, den [http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8 sshd(8)] benutzt, um zu prüfen, ob der Account ein Passwort gesetzt hat, wirkungslos und umgeht ebenso die Richtlinie, die von PermitEmptyPasswords gesetzt wurde. Aus diesem Grund raten wir davon ab, die nullok-Direktive in deiner PAM-Konfigurationsdatei zu setzen, es sei denn, du willst leere Passwörter explizit erlauben.
| |
| | |
| === ssh(1) benötigt sehr lange zum Verbinden oder zum Einloggen ===
| |
| | |
| Große Verzögerungen (mehr als 10 Sekunden) werden normalerweise durch Probleme mit der Namensauflösung verursacht: * Einige Versionen der glibc (insbesondere glibc 2.1, die mit Red Hat 6.1 ausgeliefert wurde) können einen langen Zeitraum benötigen, um ,IPv6 zu IPv4'-Adressen von Domänennamen aufzulösen. Das kann umgangen werden, indem die Option AddressFamily inet in der ssh_config eingetragen wird.
| |
| * Es könnte ein DNS-Auflösungsproblem vorliegen, entweder beim Client oder beim Server. Du kannst den <tt>nslookup</tt>-Befehl auf dem Client und dem Server verwenden, um den Namen und die IP-Adresse der Gegenseite auflösen zu lassen. Lass zusätzlich den Namen auf dem Server auflösen, den der Client beim Auflösen der IP-Adresse des Servers zurückgegeben hat. Du kannst die meisten Lookups serverseitig durch das Hinzufügen von UseDNS no in sshd_config deaktivieren.
| |
| | |
| | |
| | |
| Verzögerungen unter 10 Sekunden können andere Ursachen haben. * OpenSSH-Versionen vor 3.8 hatten eine moduli-Datei mit moduli, die kleiner waren als die, nach denen OpenSSH Ausschau hielt, und als Resultat würde sshd am Ende moduli verwenden, die beachtlich größer wären als die, die angefragt wurden, was auf Kosten der Geschwindigkeit geschah. Das Ersetzen der moduli-Datei wird das Problem lösen (bedenke, dass diese Datei bei einem Upgrade in den meisten Fällen nicht ausgetauscht wird und daher manuell ersetzt werden muss).
| |
| * OpenSSH-Versionen vor 3.8 hatten einen Fehler in <tt>ssh</tt>, der dazu führte, dass es größere moduli anforderte als erwartet (was dann, in Kombination mit dem oben genannten Problem, in erheblichen Geschwindigkeitseinbußen endete). Ein Upgrade des Clients auf Version 3.8 oder höher wird das Problem beheben.
| |
| * Falls entweder der Server oder der Client keinen kernelbasierten Zufallszahlengenerator besitzen (z. B. Solaris < 9, AIX < 5.2, HP-UX < 11.11) und kein Ersatz verfügbar ist (z. B. [ftp://ftp.ayamura.org/pub/prngd/ prngd]), ist es möglich, dass ein Programm, das von <tt>ssh-rand-helper</tt> zum Generieren vom Entropy aufgerufen wird, hängt. Das kann ermittelt werden, indem es im Debug-Modus ausgeführt wird:
| |
| | |
| | |
| | |
| <div style="margin-left:1.249cm;margin-right:0cm;">/usr/local/libexec/ssh-rand-helper -vvv </div>* Alle beachtlichen Verzögerungen sollten untersucht und behoben, oder aber die entsprechenden Befehle aus ssh_prng_cmds entfernt werden.
| |
| | |
| | |
| | |
| ==== Wie langsam ist ,langsam'? ====
| |
| | |
| Unter normalen Umständen ist die Geschwindigkeit des SSH-Logins abhängig von der CPU-Leistung des Clients und Servers. Zum Vergleich folgen typische Verbindungszeiten für <tt>time ssh localhost true</tt> mit einem 1024-Bit-RSA-Schlüssel auf einem ansonsten ungenutzten System. OpenSSH und OpenSSL wurden mit gcc 3.3.x compiliert.
| |
| | |
| | |
| {| style="border-spacing:0;margin:auto;width:17.501cm;"
| |
| |-
| |
| | style="border-top:0.05pt solid #000000;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" | '''CPU'''
| |
| | style="border-top:0.05pt solid #000000;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" | '''Zeit (SSHv1)[http://openssh.org/de/faq.html#3.3fn1 [1]]
| |
| | style="border:0.05pt solid #000000;padding:0.049cm;" | '''Zeit (SSHv2)'''
| |
| |-
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" | 170MHz SPARC/sun4m
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" | 0.74 Sek
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.049cm;" | 1.25 Sek
| |
| |-
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" | 236MHz HPPA/8200[http://openssh.org/de/faq.html#3.3fn2 [2]]
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" | 0.44 Sek
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.049cm;" | 0.79 Sek
| |
| |-
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" | 375MHz PowerPC/604e
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" | 0.38 Sek
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.049cm;" | 0.51 Sek
| |
| |-
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" | 933MHz VIA Ezra
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" | 0.34 Sek
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.049cm;" | 0.44 Sek
| |
| |-
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" | 2.1GHz Athlon 2600+
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" | 0.14 Sek
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.049cm;" | 0.22 Sek
| |
| |-
| |
| |}
| |
| [1] Das SSHv1 Protokoll ist zwar schneller, aber kryptographisch schwächer als SSHv2.[2] Zu dem Zeitpunkt des Schreibens generiert gcc relativ langsamen Code auf HPPA für RSA- und Diffie-Hellman-Operationen (siehe [http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7625 gcc bug #7625] und [http://marc.info/?l=openssh-unix-dev&m=102646106016694 Diskussion auf openssh-unix-dev]).
| |
| | |
| === Can't locate module net-pf-10 ===
| |
| | |
| Der Linux-Kernel sucht (via modprobe) nach der Protokollfamilie 10 (IPv6). Lade entweder das passende Kernelmodul, gib den korrekten Alias in /etc/modules.conf an oder schalte IPv6 in /etc/modules.conf ab.
| |
| | |
| Aus irgendeinem blödsinnigen Grund kann /etc/modules.conf auch /etc/conf.modules heißen.
| |
| | |
| === Passwortauthentifikation funktioniert nicht ===
| |
| | |
| Falls das Passwort das korrekte Passwort ist, und der Login weiterhin verwehrt bleibt, liegt die Ursache normalerweise darin, dass das System zwar mit MD5-Typ-Passwörtern arbeitet, aber die [http://www.openbsd.org/cgi-bin/man.cgi?query=crypt&sektion=3 crypt(3)]-Funktion, die von sshd verwendet wird, diese nicht verstehen kann.
| |
| | |
| Betroffene Passwörter haben eine Passwortzeichenkette in /etc/passwd oder /etc/shadow, die mit $1$ beginnt. Falls die Passwortauthentifikation für neue Accounts oder Accounts mit Passwörtern, die kürzlich aktualisiert wurden, fehlschlägt, aber mit alten Accounts funktioniert, dann ist dies wahrscheinlich das Problem.
| |
| | |
| Der Grund hierfür ist, dass einige Versionen von OpenSSL eine crypt(3)-Funktion haben, die keine MD5-Passwörter versteht, und die ,link'-Reihenfolge von sshd führt dazu, dass OpenSSLs crypt(3) und nicht das vom System genutzt wird. OpenSSHs configure versucht dies zu korrigieren aber ist damit nicht immer erfolgreich.
| |
| | |
| Es gibt einige mögliche Lösungen: * Aktiviere sshds eingebaute Unterstützung für MD5-Passwörter während der Erzeugungsphase.
| |
| | |
| | |
| | |
| ./configure --with-md5-passwords [Optionen] Dies ist sogar dann sicher, wenn du beide Verschlüsselungstypen verwendest, da sshd den korrekten Algorithmus für jeden Account automatisch auswählt. * Wenn dein System eine separate libcrypt-Bibliothek hat (z. B. Slackware 7), dann kannst du manuell -lcrypt zur LIBS-Liste einfügen, sodass es statt OpenSSLs verwendet wird:
| |
| | |
| | |
| | |
| LIBS=-lcrypt ./configure [Optionen] * Wenn deine Plattform PAM unterstützt, könntest du sshd so konfigurieren, dass es dieses verwendet (siehe [http://openssh.org/de/faq.html#3.15 Sektion 3.15]). Das bedeutet, dass sshd Passwörter nicht selbst überprüfen wird, sondern es an die konfigurierten PAM-Module übergibt.
| |
| | |
| | |
| | |
| === fehlende RSA- oder DSA-Unterstützung ===
| |
| | |
| Configure oder sshd(8) beschweren sich über fehlende RSA- oder DSA-Unterstützung
| |
| | |
| Stelle sicher, dass deine OpenSSL-Bibliotheken mit eingebauter RSA- oder DSA-Unterstützung erzeugt wurden, entweder intern oder durch RSAref.
| |
| | |
| === »scp: command not found«-Fehler ===
| |
| | |
| [http://www.openbsd.org/cgi-bin/man.cgi?query=scp&sektion=1 scp(1)] muss sich im Standard-PATH sowohl auf dem Client als auch auf dem Server befinden. Möglicherweise musst du die Option --with-default-path angeben, um einen angepassten Pfad für die Suche auf dem Server angeben zu können. Diese Option ersetzt den Standardpfad, sodass du sowohl alle bisherigen Verzeichnisse in deinem Pfad angeben musst als auch das Verzeichnis, in dem scp installiert ist. Zum Beispiel:
| |
| | |
| $ ./configure --with-default-path=/bin:/usr/bin:/usr/local/bin:/path/to/scp
| |
| | |
| Bedenke, dass die Konfiguration des Administrators des Servers Vorrang gegenüber der Option --with-default-path hat. Das beinhaltet das Rücksetzen von PATH in /etc/profile, PATH in /etc/environment unter AIX oder (für 3.7p1 und höher) das Setzen von PATH oder SUPATH in /etc/default/login unter Solaris oder Reliant Unix.
| |
| | |
| === Kann die Passphrase nicht lesen ===
| |
| | |
| Einige Betriebssysteme setzen /dev/tty mit falschen Modi, was zum Fehler beim Lesen von Passwörtern mit folgender Fehlermeldung führt:
| |
| | |
| You have no controlling tty. Cannot read passphrase.
| |
| | |
| Die Lösung hierzu ist, die Berechtigungen von /dev/tty auf 0666 zu setzen und dann das ganze deinem Betriebssystem-Hersteller als Fehler zu melden.
| |
| | |
| === configure fehlt oder make versagt ===
| |
| | |
| Wenn es keine configure-Datei in deiner tar.gz-Datei gibt, die du heruntergeladen hast, oder make mit einem ,missing seperator'-Fehler versagt, hast du vermutlich die OpenBSD-Distribution heruntergeladen und versuchst, sie auf einer anderen Plattform zu kompilieren. Bitte verwende die [http://openssh.org/de/portable.html portable Version].
| |
| | |
| === Hängt beim Verlassen von ssh ===
| |
| | |
| OpenSSH kann beim Beenden hängen bleiben. Das kann passieren, wenn es einen aktiven Hintergrundprozess gibt. Linux und HP-UX sind hierfür bekannt. Das Problem kann hiermit verifiziert werden:
| |
| | |
| $ sleep 20 & exit
| |
| | |
| Versuche stattdessen das hier zu benutzen:
| |
| | |
| $ sleep 20 < /dev/null > /dev/null 2>&1 &
| |
| | |
| Ein Umgehen des Problems für bash-Anwender ist mittels eines Einfügens von "shopt -s huponexit" in entweder /etc/bashrc oder ~/.bashrc möglich. Ansonsten konsultiere die Handbuchseite deiner Shell um eine Option zu finden, mit der man aktiven Jobs ein HUP-Signal senden kann, wenn man sie verlässt. Siehe [http://bugzilla.mindrot.org/show_bug.cgi?id=52 bug #52] für andere Möglichkeiten, das Problem umgehen zu können.
| |
| | |
| ==== Wieso hängt ssh beim Beenden? ====
| |
| | |
| Beim Ausführen von
| |
| | |
| $ ssh host command
| |
| | |
| muss ssh hängen bleiben, da es zu warten hat * bis es sicherstellen kann, dass <tt>command</tt> keine weiteren Eingaben benötigt.
| |
| * bis es sicherstellen kann, dass <tt>command</tt> keine weitere Ausgaben zurückgibt.
| |
| * bis <tt>command</tt> beendet ist, da der sshd den Exitstatus von <tt>command</tt> an ssh weitergeben muss.
| |
| | |
| | |
| | |
| === X11-Weiterleitung funktioniert nicht mehr ===
| |
| | |
| Ich habe ein Upgrade auf OpenSSH 3.1 durchgeführt und dann ging die X11-Weiterleitung nicht mehr.
| |
| | |
| Beginnend mit OpenSSH 3.1 lauscht der sshd-X11-Weiterleitungsserver standardmäßig auf localhost; siehe auch die Option X11UseLocalhost von sshd, um zum vorherigen Verhalten zurückzukehren, wenn deine älteren X11-Clients nicht mit dieser Konfiguration funktionieren.
| |
| | |
| Im Allgemeinen sollten X11-Clients, die X11 R6 benutzen, mit dieser Einstellung funktionieren. Einige Hersteller, einschließlich HP, setzen X11-Clients mit R6- und R5-Bibliotheken ein, sodass einige Clients funktionieren und andere nicht. Das gilt z. B. für HP-UX 11.X.
| |
| | |
| ==== X11-Programme funktionieren nicht mehr ====
| |
| | |
| Ich habe ein Upgrade auf OpenSSH 3.8 durchgeführt und dann gingen einige X11-Programme nicht mehr.
| |
| | |
| Wie in den [http://openssh.org/txt/release-3.8 3.8 release notes] dokumentiert worden ist, wird <tt>ssh</tt> standardmäßig ,untrusted X11 cookies' benutzen. Das vorherige Verhalten kann durch das Setzen von ForwardX11Trusted yes in sshd_config wiederhergestellt werden.
| |
| | |
| Mögliche Symptome beinhalten:
| |
| BadWindow (invalid Window parameter)
| |
| BadAccess (attempt to access private resource denied)
| |
| X Error of failed request: BadAtom (invalid Atom parameter)
| |
| Major opcode of failed request: 20 (X_GetProperty)
| |
| | |
| === Publickey-Authentifizierung funktioniert nicht ===
| |
| | |
| Ich habe meinen öffentlichen Schlüssel in authorized_keys kopiert, aber Publickey-Authentifizierung funktioniert immer noch nicht.
| |
| | |
| Typischerweise wird das durch die Dateirechte von $HOME, $HOME/.ssh oder $HOME/.ssh/authorized_keys hervorgerufen, die mehr erlauben als sshd standardmäßig zulässt.
| |
| | |
| In diesem Falle kann es behoben werden, indem Folgendes auf dem Server ausgeführt wird.
| |
| | |
| $ chmod go-w $HOME $HOME/.ssh
| |
| $ chmod 600 $HOME/.ssh/authorized_keys
| |
| $ chown `whoami` $HOME/.ssh/authorized_keys
| |
| | |
| Falls das aus irgendeinem Grund nicht möglich sein sollte, besteht die Alternative darin, StrictModes no in sshd_config zu setzen, jedoch wird das nicht empfohlen.
| |
| | |
| === OpenSSH-Versionen und das Verhalten von PAM. ===
| |
| | |
| Das portable OpenSSH hat eine Option, die während der Konfigurationsphase gesetzt werden kann, um sshds Nutzung des [http://www.opengroup.org/onlinepubs/008329799/ PAM]- (Pluggable Authentication Modules) Interfaces zu aktivieren.
| |
| | |
| ./configure --with-pam [Optionen]
| |
| | |
| Um PAM auf irgendeine Weise nutzen zu können, muss diese Option während der Erzeugungsphase gesetzt sein. Das Laufzeit-Verhalten, wenn PAM erzeugt wurde, variiert mit der Version des portablen OpenSSH, und spätere Versionen müssen es ebenfalls mit dem Setzen von UsePAM auf yes in sshd_config aktivieren.
| |
| | |
| Das Verhalten der relevanten Authentifikations-Optionen, wenn PAM-Unterstützung integriert wurde, ist in der folgenden Tabelle zusammengefasst.
| |
| | |
| | |
| {| style="border-spacing:0;margin:auto;width:17.501cm;"
| |
| |- | | |- |
| | style="border-top:0.2pt double #000000;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:none;padding:0.101cm;" | '''Version'''
| | ! RFC !! Title |
| | style="border-top:0.2pt double #000000;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:none;padding:0.101cm;" | '''UsePAM'''
| |
| | style="border-top:0.2pt double #000000;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:none;padding:0.101cm;" | '''PasswordAuthentication'''
| |
| | style="border:0.2pt double #000000;padding:0.101cm;" | '''ChallengeResponseAuthentication'''
| |
| |- | | |- |
| | style="border-top:none;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:none;padding:0.101cm;" | <=3.6.1p2 | | | 4251 || [https://tools.ietf.org/html/rfc4251 The Secure Shell (SSH) Protocol Architecture ] |
| | style="border-top:none;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:none;padding:0.101cm;" | Nicht nutzbar | |
| | style="border-top:none;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:none;padding:0.101cm;" | Verwendet PAM
| |
| | style="border-top:none;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:0.2pt double #000000;padding:0.101cm;" | Verwendet PAM, wenn PAMAuthenticationViaKbdInt aktiv ist
| |
| |- | | |- |
| | style="border-top:none;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:none;padding:0.101cm;" | 3.7p1 - 3.7.1p1 | | | 4252 || [https://tools.ietf.org/html/rfc4252 The Secure Shell (SSH) Authentication Protocol ] |
| | style="border-top:none;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:none;padding:0.101cm;" | Standard ist yes
| |
| | style="border-top:none;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:none;padding:0.101cm;" | Verwendet nicht PAM | |
| | style="border-top:none;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:0.2pt double #000000;padding:0.101cm;" | Verwendet PAM, wenn UsePAM aktiv ist
| |
| |- | | |- |
| | style="border-top:none;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:none;padding:0.101cm;" | 3.7.1p2 - 3.8.1p1 | | | 4253 || [https://tools.ietf.org/html/rfc4253 The Secure Shell (SSH) Transport Layer Protocol ] |
| | style="border-top:none;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:none;padding:0.101cm;" | Standard ist no | |
| | style="border-top:none;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:none;padding:0.101cm;" | Verwendet nicht PAM [http://openssh.org/de/faq.html#3.15fn1 [1]]
| |
| | style="border-top:none;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:0.2pt double #000000;padding:0.101cm;" | Verwendet PAM, wenn UsePAM aktiv ist
| |
| |- | | |- |
| | style="border-top:none;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:none;padding:0.101cm;" | 3.9p1 | | | 6668 || [https://tools.ietf.org/html/rfc6668 SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol ] |
| | style="border-top:none;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:none;padding:0.101cm;" | Standard ist no | |
| | style="border-top:none;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:none;padding:0.101cm;" | Verwendet PAM, wenn UsePAM aktiv ist
| |
| | style="border-top:none;border-bottom:0.2pt double #000000;border-left:0.2pt double #000000;border-right:0.2pt double #000000;padding:0.101cm;" | Verwendet PAM, wenn UsePAM aktiv ist
| |
| |- | | |- |
| |} | | | 8268 || [https://tools.ietf.org/html/rfc8268 More Modular Exponentiation (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH) ] |
| [1] Einige Verkäufer, insbesondere Redhat/Fedora, haben die Passwortauthentifikation von 3.9p1 auf ihre 3.8x-basierten Pakete zurückportiert. Wenn du ein Paket nutzt, das von einem Verkäufer bereitgestellt wurde, konsultiere bitte dessen Dokumentation.
| |
| | |
| ,OpenSSH Portable's PAM-Interface hat immer noch Probleme mit ein paar Modulen, jedoch hoffen wir, dass wir diese Anzahl in Zukunft verringern können. Zum Zeitpunkt der Veröffentlichung von 3.9p1 sind folgende Probleme bekannt: * Module, die sich auf ,module-private' Daten verlassen (z. B. pam_dhkeys, pam_krb5, AFS) können darin fehlschlagen, korrekte ,Credentials' zu erzeugen (Fehler [http://bugzilla.mindrot.org/show_bug.cgi?id=688 #688]) wenn über ChallengeResponseAuthentication authentifiziert wird. PasswordAuthentication mit 3.9p1 und neuer sollten funktionieren.
| |
| * Du kannst außerdem [http://bugzilla.mindrot.org/buglist.cgi?product=Portable+OpenSSH&bug_status=RESOLVED&bug_status=NEW&bug_status=ACCEPTED&component=PAM+support bugzilla für aktuelle PAM-Probleme] durchsehen.
| |
| | |
| | |
| | |
| === »w« noch »who« unter AIX 5.x ===
| |
| | |
| Warum zeigen weder »w« noch »who« unter AIX 5.x Benutzer an, die über ssh eingeloggt sind?
| |
| | |
| Zwischen AIX 4.3.3 und AIX 5.x wurde das Format vom »wtmp struct« geändert. Das bedeutet, dass sshd-Binarys, die unter AIX 4.x erzeugt wurden, keine korrekten wtmp-Einträge schreiben, wenn sie unter AIX 5.x ausgeführt werden. Dies kann behoben werden, indem einfach sshd auf einem AIX-5.x-System neukompiliert und dieser dann eingesetzt wird.
| |
| | |
| == Tools und Erweiterungen ==
| |
| | |
| === Sicherheit ===
| |
| | |
| ==== fail2ban ====
| |
| | |
| '''Bans IP addresses that make too many authentication failures'''
| |
| | |
| <div style="margin-left:0cm;margin-right:0cm;">Fail2ban scans log files like /var/log/messages and bans IP addresses that makes too many password failures. It updates firewall rules to reject the IP address, can send e-mails, or set host.deny entries. These rules can be defined by the user. Fail2Ban can read multiple log files such as sshd or Apache web server ones.</div>
| |
| | |
| ==== sshguard ====
| |
| | |
| '''Protect hosts from brute force attacks against ssh'''
| |
| | |
| Sshguard protects networked hosts from brute force attacks against ssh servers. It detects such attacks and blocks the attacker's address with a firewall rule.
| |
| | |
| ==== denyhosts ====
| |
| | |
| '''Utility to help system administrators thwart brute-force ssh hackers'''
| |
| | |
| DenyHosts is a python program that automatically blocks ssh attacks by adding entries to /etc/hosts.deny. DenyHosts will also inform Linux administrators about offending hosts, attacked users and suspicious logins.
| |
| | |
| ==== ScanSSH ====
| |
| | |
| ''ScanSSH'' supports scanning a list of addresses and networks for '''open proxies''', SSH protocol servers, Web and SMTP servers. Where possible ScanSSH, displays the version number of the running services. ''ScanSSH'' protocol scanner supports random selection of IP addresses from large network ranges and is useful for gathering statistics on the deployment of SSH protocol servers in a company or the Internet as whole.
| |
| | |
| http://www.monkey.org/~provos/scanssh/
| |
| | |
| ====== SSH-Serverversionen scannen ======
| |
| | |
| Um die Überwachung der verwendeten SSH-Server zu erleichtern (z. B. in einem Firmennetzwerk) hat Niels Provos das [http://www.monkey.org/%7Eprovos/scanssh/ scanssh]-Tool geschrieben. scanssh prüft eine Liste von Adressen und Netzwerken auf die Verwendung von SSH-Servern und ihrer Versionsnummern hin. Es unterstützt die zufällige Auswahl von IP-Adressen innerhalb großer Netzwerkbereiche und ist einfach nützlich, um Statistiken über die Verwendung von SSH-Servern in einer Firma oder dem Internet an sich zu erhalten. Die Statistiken enthalten sowohl die unterstützten SSH-Protokolle als auch die benutzten Softwareversionen.
| |
| | |
| scanssh wird benutzt, um die [http://openssh.org/usage/de/index.html Statistiken] über die Verbreitung und Benutzung der SSH-Protokolle im Internet zu erhalten. Die Messungen erlauben Einblicke in die Verbreitung der verschiedenen SSH-Protokolle und der Marktdurchdringung bestimmter Serverversionen.
| |
| | |
| === Authentifizierung ===
| |
| | |
| ==== pam_ssh ====
| |
| | |
| '''PAM Module for SSH Authentication'''
| |
| | |
| This module provides single sign-on behavior. The user types a passphrase when logging in and is allowed in if it decrypts the user s SSH private key. An ssh-agent is started and keys are added. For the entire session, the user types no more passwords.
| |
| | |
| === Automatisierung ===
| |
| | |
| ==== clusterssh ====
| |
| | |
| | |
| {| style="border-spacing:0;margin:auto;width:17.501cm;"
| |
| |- | | |- |
| || '''Multiplex SSH sessions onto many hosts using multiple terminals''' | | | 8308 || [https://tools.ietf.org/html/rfc8308 Extension Negotiation in the Secure Shell (SSH) Protocol ] |
| | |
| Cluster SSH opens terminal windows with connections to specified hosts and an administration console. Any text typed into the administration console is replicated to all other connected and active windows.
| |
| | |
| This tool is intended for, but not limited to, cluster administration where the same configuration or commands must be run on each node within the cluster. Performing these commands all at once via this tool ensures all nodes are kept in sync.
| |
| | align=right| [[Image:Grafik68.png|right|top]]
| |
| | |
| | |
| |- | | |- |
| | | 8332 || [https://tools.ietf.org/html/rfc8332 Use of RSA Keys with SHA-256 and SHA-512 in the Secure Shell (SSH) Protocol ] |
| |} | | |} |
| ==== pssh ====
| |
|
| |
| '''Parallel SSH to control large numbers of Machines simultaneously'''
| |
|
| |
| pssh provides parallel versions of the OpenSSH tools that are useful for controlling large numbers of machines simultaneously. It includes parallel versions of ssh, scp, and rsync, as well as a parallel kill command.
| |
|
| |
| ==== sshfp ====
| |
|
| |
| '''RFC4255 DNS SSHFP record generator'''
| |
|
| |
| sshfp generates DNS SSHFP records from SSH public keys. sshfp can take public keys from a knownhosts file or from scanning the host's sshd daemon. The ssh client can use these SSHFP records if you set "VerifyHostKeyDNS yes" in the file /etc/ssh/ssh_config.
| |
|
| |
| === Tunnel ===
| |
|
| |
| ==== autossh ====
| |
|
| |
| '''Automatically restart SSH sessions and tunnels'''
| |
|
| |
| Autossh is a program to start a copy of ssh and monitor it, restarting it as necessary should it die or stop passing traffic. The idea and the mechanism are from rstunnel (Reliable SSH Tunnel), but implemented in C. The author's view is that it is not as fiddly as rstunnel to get to work. Connection monitoring using a loop of port forwardings. Backs off on rate of connection attempts when experiencing rapid failures such as connection refused.
| |
|
| |
| ==== httptunnel-la ====
| |
|
| |
| '''Tunnel Arbitrary TCP Connections over HTTP'''
| |
|
| |
| HTTPTunnel is a simple client/server application for creating an HTTP tunnel between two machines, optionally via a Web proxy. This tunnel can then be used to wrap arbitrary TCP socket traffic in HTTP, thus allowing communications even through a restrictive firewall that only allows outgoing HTTP connections.
| |
|
| |
| ==== sslh ====
| |
|
| |
|
| '''SSL/SSH multiplexer'''
| | === Links === |
| | | ==== Projekt ==== |
| sslh lets one accept both HTTPS and SSH connections on the same port. It makes it possible to connect to an SSH server on port 443 (e.g. from inside a corporate firewall) while still serving HTTPS on that port.
| | ==== Weblinks ==== |
| | |
| ==== sshuttle ==== | |
| | |
| '''Transparent Proxy VPN'''
| |
| | |
| Transparent proxy server that works as a poor man's VPN. Forwards over ssh. Doesn't require admin. Works with Linux and MacOS. Supports DNS tunneling.
| |
| | |
| == Quellen und Informationen ==
| |
| | |
| === Weblinks ===
| |
| | |
| * de.wikipedia.org/wiki/Ssh
| |
| * wiki.ubuntuusers.de/ssh
| |
| * de.wikipedia.org/wiki/Transport_Layer_Security
| |
| * www.openssh.org
| |
| * www.openssl.org
| |
| | |
| | |
| | |
| ==== Wo sollte ich um Hilfe fragen? ==== | |
| | |
| Es gibt mehrere Stellen, die du um Hilfe bitten kannst. Zusätzlich zur [http://openssh.org/de/index.html OpenSSH-Webseite] gibt es mehrere Mailinglisten, in denen du dein Glück versuchen kannst. Bevor du das tust, durchsuche bitte alle Mailinglisten-Archive um zu sehen, ob deine Frage vielleicht schon beantwortet wurde. Die OpenSSH-Mailingliste wurde archiviert und steht in durchsuchbarer Form unter [http://marc.info/?l=openssh-unix-dev&r=1&w=2 marc.info]. zur Verfügung.
| |
| | |
| Mehr Informationen über das Abonnieren von OpenSSH-bezogenen Mailinglisten gibt es unter [http://openssh.org/de/list.html OpenSSH-Mailinglisten].
| |
| | |
| ==== Ich habe einen Fehler gefunden. Wo melde ich ihn? ====
| |
| | |
| Informationen zum Senden von Fehlermeldungen können auf der OpenSSH [http://openssh.org/de/report.html ,Fehler melden']-Seite gefunden werden.
| |
| | |
| Wenn du eine Sicherheitslücke melden möchtest, kontaktiere bitte die private Liste »[mailto:openssh@openssh.com openssh@openssh.com]«.
| |
| | |
| === Handbuchseiten ===
| |
| | |
| Web-Handbuchseiten sind von OpenBSD für die folgenden Kommandos verfügbar. Diese Handbuchseiten reflektieren die letzte Entwicklungsversion von OpenSSH.
| |
| | |
| | |
| {| style="border-spacing:0;margin:auto;width:17.501cm;"
| |
| |-
| |
| | style="border-top:0.05pt solid #000000;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.15cm;" | [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh&sektion=1 ssh(1)]
| |
| | style="border:0.05pt solid #000000;padding:0.15cm;" | Das rlogin/rsh-ähnliche Basis-Clientprogramm.
| |
| |-
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.15cm;" | [http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8 sshd(8)]
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.15cm;" | Der Daemon, der dir erlaubt, dich einzuloggen.
| |
| |-
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.15cm;" | [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh_config&sektion=5 ssh_config(5)]
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.15cm;" | Die Konfigurationsdatei des Clients.
| |
| |-
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.15cm;" | [http://www.openbsd.org/cgi-bin/man.cgi?query=sshd_config&sektion=5 sshd_config(5)]
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.15cm;" | Die Konfigurationsdatei des Daemons.
| |
| |-
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.15cm;" | [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-agent&sektion=1 ssh-agent(1)]
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.15cm;" | Ein Authentifikationsagent, der private Schlüssel verwalten kann.
| |
| |-
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.15cm;" | [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-add&sektion=1 ssh-add(1)]
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.15cm;" | Werkzeug, das zum obigen Agenten neue Schlüssel hinzufügt.
| |
| |-
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.15cm;" | [http://www.openbsd.org/cgi-bin/man.cgi?query=sftp&sektion=1 sftp(1)]
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.15cm;" | FTP-ähnliches Programm, das sowohl unter dem SSH1- als auch dem SSH2-Protokoll läuft.
| |
| |-
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.15cm;" | [http://www.openbsd.org/cgi-bin/man.cgi?query=scp&sektion=1 scp(1)]
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.15cm;" | Dateikopierprogramm, das sich wie rcp(1) verhält.
| |
| |-
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.15cm;" | [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-keygen&sektion=1 ssh-keygen(1)]
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.15cm;" | Schlüsselerzeugungs-Werkzeug.
| |
| |-
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.15cm;" | [http://www.openbsd.org/cgi-bin/man.cgi?query=sftp-server&sektion=8 sftp-server(8)]
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.15cm;" | SFTP-Server-Subsystem (wird automatisch von sshd gestartet).
| |
| |-
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.15cm;" | [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-keyscan&sektion=1 ssh-keyscan(1)]
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.15cm;" | Werkzeug, um öffentliche Hostschlüssel von verschiedenen anderen Hosts zu holen.
| |
| |-
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.15cm;" | [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-keysign&sektion=8 ssh-keysign(8)]
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.15cm;" | Hilfsprogramm für hostbasierte Authentifikation.
| |
| |-
| |
| |}
| |
| Die Arbeitsweisen des SSH2-Protokolls, das in OpenSSH implementiert ist, wurde von der IETF-secsh-Arbeitsgruppe standardisiert und ist in verschiedenen Entwürfen definiert. Die umfassende Struktur von SSH2 ist im architecture-RFC beschrieben. Es besteht aus drei aufeinander aufbauenden Komponenten: * Die [http://www.ietf.org/rfc/rfc4253.txt Transportschicht] stellt die Algorithmusvereinbarung und den Schlüsselaustausch zur Verfügung. Der Schlüsselaustausch schließt die Serverauthentifikation und die Resultate in einer kryptographisch gesicherten Verbindung mit ein: Er enthält Integrität, Vertraulichkeit und optionale Kompression.
| |
| * Die [http://www.ietf.org/rfc/rfc4252.txt Benutzer-Authentifikationsschicht] benutzt die hergestellte Verbindung und benötigt die Dienste, die von der Transportschicht bereitgestellt werden. Er bietet verschiedene Mechanismen zur Benutzerauthentifikation. Das beinhaltet traditionelle Passwortauthentifikation genauso wie ,public-key'- oder hostbasierte Authentifikationsmechanismen.
| |
| | |
| | |
| | |
| Die [http://www.ietf.org/rfc/rfc4254.txt Verbindungsschicht] multiplext viele verschiedene gleichzeitige Kanäle über die authentifizierte Verbindung und erlaubt das Tunneln von ,login sessions' und TCP-Weiterleitung. Sie stellt einen ,flow control service' für diese Kanäle bereit. Zusätzlich können verschiedene kanalspezifische Optionen verhandelt werden.
| |
| | |
| === Zusätzliche Dokumente ===
| |
| | |
| * Der RFC für [http://www.ietf.org/rfc/rfc4256.txt interaktive Authentifikation] bietet Unterstützung für neue Authentifikationsschemata wie etwa S/Key oder TIS.
| |
| * Das SFTP-Dateitransferprotokoll wird im [http://openssh.org/txt/draft-ietf-secsh-filexfer-02.txt filexfer]-Dokument spezifiziert. OpenSSH implementiert einen SFTP-[http://www.openbsd.org/cgi-bin/man.cgi?query=sftp&sektion=1 client] und -[http://www.openbsd.org/cgi-bin/man.cgi?query=sftp-server&sektion=8 server].
| |
| * Ein Dateiformat für öffentliche Schlüssel wird im [http://openssh.org/txt/draft-ietf-secsh-publickeyfile-02.txt publickeyfile]-Dokument spezifiziert. Der Befehl [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-keygen&sektion=1 ssh-keygen(1)] kann benutzt werden, um einen OpenSSH-,public key' in dieses Dateiformat zu überführen.
| |
| * Die [http://www.ietf.org/rfc/rfc4419.txt Diffie-Hellman Group Exchange] erlaubt es Clients, nach sichereren Gruppen für den Diffie-Hellman-Schlüsselaustausch zu fragen.
| |
| * OpenSSH hat eine Kompressionsmethode namens »zlib@openssh.com« implementiert, die erst nach der Benutzerauthentifikation mit der Kompression beginnt, um jegliche Angriffe vor der Authentifikation zu unterbinden. Es wird in [http://openssh.org/txt/draft-miller-secsh-compression-delayed-00.txt draft-miller-secsh-compression-delayed-00.txt] beschrieben.
| |
| * OpenSSH implementiert einen zusätzlichen MAC (Message Authentication CODE) namens »umac-64@openssh.com«, der eine bessere Performance hat als jene, die im RFC 4253 beschrieben werden. Er wird in [http://openssh.org/txt/draft-miller-secsh-umac-01.txt draft-miller-secsh-umac-01.txt] beschrieben.
| |
| * Das Authentifikationagentenprotokoll, das von [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-agent&sektion=1 ssh-agent] verwendet wird, wird in der Datei [http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL.agent?rev=HEAD PROTOCOL.agent] beschrieben.
| |
| * OpenSSH macht weitere kleine Erweiterungen oder weicht von den Standard-SSH-Protokollen ab. Diese werden in der Datei [http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL?rev=HEAD PROTOCOL] beschrieben. <br/>Es gibt auch eine Mailingliste für generelle Diskussionen über das SSH2-Protokoll ([mailto:ietf-ssh@netbsd.org ietf-ssh@netbsd.org]).
| |
| | |
| | |
| | |
| === Spezifikationen (OpenSSH) ===
| |
| | |
| OpenSSH implementiert die folgenden Spezifikationen.
| |
| | |
| ==== SSH Protokollversion 1 ====
| |
| | |
| | |
| {| style="border-spacing:0;margin:auto;width:17.501cm;"
| |
| |-
| |
| | style="border-top:0.05pt solid #000000;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | [http://openssh.org/txt/ssh-rfc-v1.3.txt ssh-rfc-v1.3.txt]
| |
| | style="border:0.05pt solid #000000;padding:0.101cm;" | SSH Protokollversion 1.3
| |
| |-
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | [http://openssh.org/txt/ssh-rfc-v1.5.txt ssh-rfc-v1.5.txt]
| |
| | style="background-color:transparent;border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | SSH Protokollversion 1.5
| |
| | |
| | |
| |-
| |
| |}
| |
| ==== SSH Protokollversion 2 Kern-RFCs ====
| |
| | |
| Quelle: [http://datatracker.ietf.org/wg/secsh/ secsh working group]
| |
| | |
| | |
| {| style="border-spacing:0;margin:auto;width:17.501cm;"
| |
| |-
| |
| | style="border-top:0.05pt solid #000000;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | [http://openssh.org/txt/rfc4250.txt rfc4250.txt]
| |
| | style="border-top:0.05pt solid #000000;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" |
| |
| | style="border:0.05pt solid #000000;padding:0.101cm;" | Dem SSH-Protokoll zugewiesene Nummern und Werte
| |
| |-
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | [http://openssh.org/txt/rfc4251.txt rfc4251.txt]
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" |
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | SSH Protokollarchitektur
| |
| |-
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | [http://openssh.org/txt/rfc4252.txt rfc4252.txt]
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" |
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | SSH Authentifizierungs-Protokoll
| |
| |-
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | [http://openssh.org/txt/rfc4253.txt rfc4253.txt]
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | [http://www.rfc-editor.org/errata_search.php?rfc=4253 (e)]
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | SSH Transportschicht-Protokoll
| |
| |-
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" | [http://openssh.org/txt/rfc4254.txt rfc4254.txt]
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.101cm;" |
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.101cm;" | SSH Verbindungs-Protokoll
| |
| | |
| | |
| |-
| |
| |}
| |
| ==== SSH Protokollversion 2, Erweiterungs-RFCs ====
| |
| | |
| | |
| {| style="border-spacing:0;margin:auto;width:17.501cm;"
| |
| |-
| |
| | style="border-top:0.05pt solid #000000;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" | [http://openssh.org/txt/rfc4255.txt rfc4255.txt]
| |
| | style="border-top:0.05pt solid #000000;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" | [http://www.rfc-editor.org/errata_search.php?rfc=4255 (e)]
| |
| | style="border:0.05pt solid #000000;padding:0.049cm;" | Die Nutzung von DNS zur sicheren Veröffentlichung von Fingerabdrücken von SSH-Schlüsseln (SSHFP)
| |
| |-
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" | [http://openssh.org/txt/rfc4256.txt rfc4256.txt]
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" | [http://www.rfc-editor.org/errata_search.php?rfc=4256 (e)]
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.049cm;" | Generische Authentifizierung über den Austausch von Botschaften (»keyboard-interactive«)
| |
| |-
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" | [http://openssh.org/txt/rfc4335.txt rfc4335.txt]
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" | [http://www.rfc-editor.org/errata_search.php?rfc=4335 (e)]
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.049cm;" | »BREAK«-Erweiterung des SSH-Sitzungskanals
| |
| |-
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" | [http://openssh.org/txt/rfc4344.txt rfc4344.txt]
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" |
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.049cm;" | Verschlüsselungsmethoden für die SSH Transportschicht
| |
| |-
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" | [http://openssh.org/txt/rfc4345.txt rfc4345.txt]
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" |
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.049cm;" | Verbesserte Arcfour-Methoden für das SSH Transportschicht-Protokoll
| |
| |-
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" | [http://openssh.org/txt/rfc4419.txt rfc4419.txt]
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" |
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.049cm;" | Diffie-Hellman Methode zum Austausch von Gruppen
| |
| |-
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" | [http://openssh.org/txt/rfc4462.txt rfc4462.txt]
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" | [http://www.rfc-editor.org/errata_search.php?rfc=4462 (e)]
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.049cm;" | GSS-API Authentifizierung und Schlüsselaustausch (einzig Authentifizierung ist im Moment implementiert)
| |
| |-
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" | [http://openssh.org/txt/rfc4716.txt rfc4462.txt]
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" |
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.049cm;" | Dateiformat des öffentlichen SSH-Schlüssels
| |
| |-
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" | [http://openssh.org/txt/rfc5656.txt rfc5656.txt]
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" | [http://www.rfc-editor.org/errata_search.php?rfc=5656 (e)]
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.049cm;" | Integration des »Elliptic Curve Algorithm« in SSH
| |
| |-
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" | [http://openssh.org/txt/rfc6594.txt rfc6594.txt]
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" | [http://www.rfc-editor.org/errata_search.php?rfc=6594 (e)]
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.049cm;" | SHA-256 SSHFP Ressourceneinträge (neu in OpenSSH 6.1).
| |
| |-
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" | [http://openssh.org/txt/rfc6668.txt rfc6668.txt]
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" |
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.049cm;" | SHA-2 Datenintegritätsalgorithmus (neu in OpenSSH 5.9)
| |
| | |
| | |
| |-
| |
| |}
| |
| ==== SSH Protokollversion 2 - Spezifikationsentwürfe ====
| |
| | |
| | |
| {| style="border-spacing:0;margin:auto;width:17.501cm;"
| |
| |-
| |
| | style="border-top:0.05pt solid #000000;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" | [http://openssh.org/txt/draft-ietf-secsh-filexfer-02.txt draft-ietf-secsh-filexfer-02.txt]
| |
| | style="border:0.05pt solid #000000;padding:0.049cm;" | SSH Dateiübertragungs-Protokoll, Version 3
| |
| | |
| | |
| |-
| |
| |}
| |
| ==== SSH Protokollversion 2 - Anbietererweiterungen. ====
| |
| | |
| | |
| {| style="border-spacing:0;margin:auto;width:17.501cm;"
| |
| |-
| |
| | style="border-top:0.05pt solid #000000;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" | [http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL?rev=HEAD;content-type=text/plain usr/bin/ssh/PROTOCOL]
| |
| | style="border:0.05pt solid #000000;padding:0.049cm;" | Ein Überblick über alle unten aufgeführten Anbietererweiterungen sowie der Spezifikationen der SSH2-Erweiterungen <tt>eow@openssh.com</tt>, <tt>no-more-sessions@openssh.com</tt>, <tt>tun@openssh.com</tt> und der SFTP-Erweiterungen <tt>posix-rename@openssh.com</tt>, <tt>statvfs@openssh.com</tt>, <tt>fstatvfs@openssh.com</tt>
| |
| |-
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" | [http://openssh.org/txt/draft-miller-secsh-umac-01.txt draft-miller-secsh-umac-01.txt]
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.049cm;" | <tt>umac-64@openssh.com</tt>: ein neuer MAC für die Transportschicht.
| |
| |-
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" | [http://openssh.org/de/txt/draft-miller-secsh-compression-delayed-00.txt draft-miller-secsh-compression-delayed-00.txt]
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.049cm;" | <tt>zlib@openssh.com</tt>: Verzögerung der Kompression bis nach erfolgter Authentifierung.
| |
| |-
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" | [http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL.certkeys?rev=HEAD;content-type=text/plain usr/bin/ssh/PROTOCOL.certkeys]
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.049cm;" | <tt>ssh-rsa-cert-v00@openssh.com</tt>, <tt>ssh-dsa-cert-v00@openssh.com</tt>, <tt>ecdsa-sha2-nistp256-cert-v01@openssh.com</tt>, <tt>ecdsa-sha2-nistp384-cert-v01@openssh.com</tt>, <tt>ecdsa-sha2-nistp521-cert-v01@openssh.com</tt>: neue Algorithmen für öffentliche Schlüssel, die Zertifikate unterstützen.
| |
| |-
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" | [http://git.libssh.org/projects/libssh.git/tree/doc/curve25519-sha256@libssh.org.txt curve25519-sha256@libssh.org.txt]
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.049cm;" | <tt>curve25519-sha256@libssh.org</tt> Schlüsselaustauschmethode.
| |
| | |
| | |
| |-
| |
| |}
| |
| ==== Andere Spezifikationen ====
| |
| | |
| | |
| {| style="border-spacing:0;margin:auto;width:17.501cm;"
| |
| |-
| |
| | style="border-top:0.05pt solid #000000;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" | [http://openssh.org/txt/socks4.protocol socks4.protocol]
| |
| | style="border:0.05pt solid #000000;padding:0.049cm;" | SOCKS Protokollversion 4. Genutzt für <tt>ssh -D</tt>.
| |
| |-
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" | [http://openssh.org/txt/socks4a.protocol socks4a.protocol]
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.049cm;" | SOCKS Protokollversion 4a. Genutzt für <tt>ssh -D</tt>.
| |
| |-
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" | [http://openssh.org/txt/rfc1928.txt rfc1928.txt]
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.049cm;" | SOCKS Protokollversion 5. Genutzt für <tt>ssh -D</tt>.
| |
| |-
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.049cm;" | [http://openssh.org/txt/rfc1349.txt rfc1349.txt][http://openssh.org/txt/rfc2597.txt rfc2597.txt][http://openssh.org/txt/rfc2598.txt rfc2598.txt]
| |
| | style="border-top:none;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:0.05pt solid #000000;padding:0.049cm;" | »IP Type of Service« (ToS) und »Differentiated Services«. ssh und sshd setzen automatisch den ToS, wie es von RFC 1349 verlangt wird, es sei denn es wird durch Nutzung des Schlüsselworts <tt>IPQoS</tt> in den Dateien [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh_config ssh_config] und [http://www.openbsd.org/cgi-bin/man.cgi?query=sshd_config sshd_config] eine Rekonfiguration vorgenommen.
| |
| |-
| |
| |}
| |
| | |
| | |
| = OpenSSH =
| |
| | |
| Ein aktualisiertes Paket wurde mit [https://www.debian.org/security/2008/dsa-1576 DSA-1576] herausgegeben, das die Schlüsseltransformation vereinfacht.
| |
| | |
| 1. Installieren Sie die Sicherheitsaktualisierungen aus DSA-1576
| |
| | |
| Sobald die Aktualisierung eingespielt wurde, werden schwache Benutzerschlüssel, wenn möglich, automatisch zurückgewiesen (diese können aber nicht in allen Fällen erkannt werden). Falls Sie solche Schlüssel für die Benutzerauthentifizierung verwenden, werden sie ab sofort nicht mehr funktionieren und müssen ersetzt werden (siehe Schritt 3).
| |
| | |
| OpenSSH-Rechner-Schlüssel können automatisch neu erzeugt werden, wenn die OpenSSH-Sicherheitsaktualisierung eingespielt wurde. Die Aktualisierung wird nach Bestätigung fragen, bevor dieser Schritt durchgeführt wird.
| |
| | |
| 2. Aktualisierung der OpenSSH-Dateien <tt>known_hosts</tt>
| |
| | |
| Die Neuerzeugung der Rechnerschlüssel wird eine Warnung ausgeben, wenn auf das System mit SSH zugegriffen wird, bis der Rechnerschlüssel in der Datei known_hosts auf dem Klient aktualisiert wurde. Die Warnung wird wie folgt aussehen:
| |
| | |
| @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
| |
| @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
| |
| @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
| |
| IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
| |
| Someone could be eavesdropping on you right now (man-in-the-middle attack)!
| |
| It is also possible that the RSA host key has just been changed.
| |
| | |
| Auf Deutsch lautet diese Meldung in etwa wie folgt:
| |
| | |
| @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
| |
| @ WARNING: IDENTIFIZIERUNG DES ENTFERNTES RECHNERS HAT SICH GEÄNDERT @
| |
| @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
| |
| ES IST MÖGLICH, DASS JEMAND ETWAS BÖSES TUT!
| |
| Jemand könnte Sie zurzeit abhören (man-in-the-middle-(Mann in der Mitte)-Angriff)!
| |
| Es ist auch möglich, dass der RSA-Rechnerschlüssel vor kurzem geändert wurde.
| |
| | |
| In diesem Fall wurde der Rechnerschlüssel einfach geändert und Sie sollten die entsprechende Datei <tt>known_hosts</tt>, wie in der Meldung beschrieben, aktualisieren. Es wird empfohlen, dass Sie einen vertrauenswürdigen Kanal zum Austausch des Server-Schlüssels verwenden. Er befindet sich in der Datei <tt>/etc/ssh/ssh_host_rsa_key.pub</tt> auf dem Server; sein Fingerabdruck kann mit dem folgenden Kommando gedruckt werden:
| |
| | |
| <tt>ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub</tt>
| |
| | |
| Zusätzlich zu benutzerspezifischen <tt>known_hosts</tt>-Dateien, kann eine systemweite Datei <tt>/etc/ssh/ssh_known_hosts</tt> existieren. Diese Datei wird sowohl vom ssh-Klient als auch von sshd für die <tt>hosts.equiv</tt>-Funktionalität verwendet. Diese Datei muss auch aktualisiert werden.
| |
| | |
| 3. Überprüfen aller OpenSSH-Benutzerschlüssel
| |
| | |
| Der sicherste Weg ist es, alle OpenSSH-Benutzerschlüssel neu zu erzeugen, es sei denn, es kann mit ausreichender Bestimmtheit sichergestellt werden, dass der Schlüssel auf einem nicht betroffenen System erstellt wurde.
| |
| | |
| Um zu testen, ob Ihr Schlüssel betroffen ist, können Sie <tt>ssh-vulnkey</tt> starten, was in der Sicherheitsaktualisierung enthalten ist. Standardmäßig wird <tt>ssh-vulnkey</tt> den Standardort für Benutzerschlüssel (<tt>~/.ssh/id_rsa</tt>, <tt>~/.ssh/id_dsa</tt> und <tt>~/.ssh/identity</tt>), Ihre Datei <tt>authorized_keys</tt> (<tt>~/.ssh/authorized_keys</tt> und <tt>~/.ssh/authorized_keys2</tt>) und die Rechnerschlüssel des Systems (<tt>/etc/ssh/ssh_host_dsa_key</tt> und <tt>/etc/ssh/ssh_host_rsa_key</tt>) überprüfen.
| |
| | |
| Sie können alle Ihre eigenen Schlüssel wie folgt testen, unter der Voraussetzung, dass sie sich an den Standardorten (<tt>~/.ssh/id_rsa</tt>, <tt>~/.ssh/id_dsa</tt> oder <tt>~/.ssh/identity</tt>) befinden:
| |
| | |
| <tt>ssh-vulnkey</tt>
| |
| | |
| Um alle Schlüssel auf Ihrem System zu überprüfen:
| |
| | |
| <tt>sudo ssh-vulnkey -a</tt>
| |
| | |
| Um einen Schlüssel an einem nicht standardmäßigem Ort zu testen:
| |
| | |
| <tt>ssh-vulnkey ''/Pfad/zum/Schlüssel''</tt>
| |
| | |
| Falls <tt>ssh-vulnkey</tt> die Meldung Unknown (no blacklist information) ausgibt, hat es keine Informationen darüber, ob der Schlüssel betroffen ist. Im Zweifelsfall sollte der Schlüssel zerstört und ein neuer erzeugt werden.
| |
| | |
| 4. Neuerzeugen beliebiger betroffener Benutzerschlüssel
| |
| | |
| Für die Benutzerauthentifizierung verwendete OpenSSH-Schlüssel müssen manuell neu erzeugt werden, inklusive derjenigen, die nach der Erzeugung auf ein anderes System übertragen wurden.
| |
| | |
| Neue Schlüssel können mit <tt>ssh-keygen</tt> erzeugt werden, z.B.:
| |
| | |
| $ ssh-keygen
| |
| Generating public/private rsa key pair.
| |
| Enter file in which to save the key (/home/user/.ssh/id_rsa):
| |
| Enter passphrase (empty for no passphrase):
| |
| Enter same passphrase again:
| |
| Your identification has been saved in /home/user/.ssh/id_rsa.
| |
| Your public key has been saved in /home/user/.ssh/id_rsa.pub.
| |
| The key fingerprint is:
| |
| 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 user@host
| |
| | |
| 5. Aktualisierung der <tt>authorized_keys</tt>-Dateien (falls nötig)
| |
| | |
| Sobald die Benutzerschlüssel neu erzeugt wurden, müssen die relevanten öffentlichen Schlüssel in <tt>authorized_keys</tt>-Dateien (und eventuell <tt>authorized_keys2</tt>-Dateien) auf entfernten Systemen übertragen werden. Stellen Sie sicher, dass die betroffenen Schlüssel gelöscht werden.
| |
| | |
| == SSH Hostkeys generieren ==
| |
| | |
| rm /etc/ssh/ssh_host_*
| |
| | |
| /usr/bin/ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_key -N ""
| |
| | |
| /usr/bin/ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N ""
| |
| | |
| /usr/bin/ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N ""
| |
| | |
| ssh-keygen -t ed25519 -f <span style="background-color:#ffffff;color:#000000;">/etc/ssh/ssh_host_ed</span><span style="background-color:#ffffff;color:#b21818;">25519</span><span style="background-color:#ffffff;color:#000000;">_key</span>
| |
| | |
| | |
| = Secure Secure Shell =
| |
| | |
| 2015-01-04 crypto, nsa, and ssh
| |
| | |
| You may have heard that the NSA can decrypt SSH at least some of the time. If you have not, then read the [https://www.spiegel.de/international/germany/inside-the-nsa-s-war-on-internet-security-a-1010361.html latest batch of Snowden documents] now. All of it. This post will still be here when you finish. My goal with this post here is to make NSA analysts sad.
| |
| | |
| TL;DR: Scan this post for fixed width fonts, these will be the config file snippets and commands you have to use.
| |
| | |
| ''Warning'': You will need a recent OpenSSH version. It should work with 6.5 but I have only tested 6.7 and connections to Github. Here is a good [http://ssh-comparison.quendi.de/comparison.html compatibility matrix].
| |
| | |
| === The crypto ===
| |
| | |
| Reading the documents, I have the feeling that the NSA can 1) decrypt weak crypto and 2) steal keys. Let’s focus on the crypto first. SSH supports different key exchange algorithms, ciphers and message authentication codes. The server and the client choose a set of algorithms supported by both, then proceed with the key exchange. Some of the supported algorithms are not so great and should be disabled completely. This hurts interoperability but everyone uses OpenSSH anyway. Fortunately, downgrade attacks are not possible because the supported algorithm lists are included in the key derivation. If a man in the middle were to change the lists, then the server and the client would calculate different keys.
| |
| | |
| == Key exchange ==
| |
| | |
| There are basically two ways to do key exchange: [https://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange Diffie-Hellman] and [https://en.wikipedia.org/wiki/Elliptic_curve_Diffie–Hellman Elliptic Curve Diffie-Hellman]. Both provide [https://en.wikipedia.org/wiki/Forward_secrecy forward secrecy] which the NSA hates because they can’t use passive collection and key recovery later. The server and the client will end up with a shared secret number at the end without a passive eavesdropper learning anything about this number. After we have a shared secret we have to derive a cryptographic key from this using a key derivation function. In case of SSH, this is a hash function.
| |
| | |
| DH works with a multiplicative group of integers modulo a prime. Its security is based on the hardness of the [https://en.wikipedia.org/wiki/Discrete_logarithm_problem discrete logarithm problem].
| |
| | |
| Alice Bob
| |
| <nowiki>---------------------------</nowiki>
| |
| Sa = random
| |
| Pa = g^Sa --> Pa
| |
| Sb = random
| |
| Pb <-- Pb = g^Sb
| |
| s = Pb^Sa s = Pa^Sb
| |
| k = KDF(s) k = KDF(s)
| |
| | |
| ECDH works with elliptic curves over finite fields. Its security is based on the hardness of the elliptic curve discrete logarithm problem.
| |
| | |
| Alice Bob
| |
| <nowiki>---------------------------</nowiki>
| |
| Sa = random
| |
| Pa = Sa * G --> Pa
| |
| Sb = random
| |
| Pb <-- Pb = Sb * G
| |
| s = Sa * Pb s = Sb * Pa
| |
| k = KDF(s) k = KDF(s)
| |
| | |
| OpenSSH supports 8 key exchange protocols:# [http://git.libssh.org/projects/libssh.git/tree/doc/curve25519-sha256@libssh.org.txt curve25519-sha256]: ECDH over [http://cr.yp.to/ecdh.html Curve25519] with SHA2
| |
| # [https://www.ietf.org/rfc/rfc4253.txt diffie-hellman-group1-sha1]: 1024 bit DH with SHA1
| |
| # [https://www.ietf.org/rfc/rfc4253.txt diffie-hellman-group14-sha1]: 2048 bit DH with SHA1
| |
| # [https://www.ietf.org/rfc/rfc4419.txt diffie-hellman-group-exchange-sha1]: Custom DH with SHA1
| |
| # [https://www.ietf.org/rfc/rfc4419.txt diffie-hellman-group-exchange-sha256]: Custom DH with SHA2
| |
| # ecdh-sha2-nistp256: ECDH over NIST P-256 with SHA2
| |
| # ecdh-sha2-nistp384: ECDH over NIST P-384 with SHA2
| |
| # ecdh-sha2-nistp521: ECDH over NIST P-521 with SHA2
| |
| | |
| | |
| | |
| We have to look at 3 things here:* ''ECDH curve choice'': This eliminates 6-8 because [http://blog.cr.yp.to/20140323-ecdsa.html NIST curves suck]. They leak secrets through timing side channels and off-curve inputs. Also, [https://projectbullrun.org/dual-ec/vulnerability.html NIST is considered harmful] and cannot be trusted.
| |
| * ''Bit size of the DH modulus'': This eliminates 2 because the NSA has supercomputers and possibly unknown attacks. 1024 bits simply don’t offer sufficient security margin.
| |
| * ''Security of the hash function'': This eliminates 2-4 because SHA1 is broken. We don’t have to wait for a second preimage attack that takes 10 minutes on a cellphone to disable it right now.
| |
| | |
| | |
| | |
| We are left with 1 and 5. 1 is better and it’s perfectly OK to only support that but for interoperability (with Eclipse, WinSCP), 5 can be included.
| |
| | |
| Recommended <tt>/etc/ssh/sshd_config</tt> snippet:
| |
| | |
| KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
| |
| | |
| Recommended <tt>/etc/ssh/ssh_config</tt> snippet:
| |
| | |
| <nowiki># Github needs diffie-hellman-group-exchange-sha1 some of the time but not always.</nowiki>
| |
| <nowiki>#Host github.com</nowiki>
| |
| <nowiki># </nowiki> KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1
| |
| | |
| Host *
| |
| KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
| |
| | |
| If you chose to enable 5, open <tt>/etc/ssh/moduli</tt> if exists, and delete lines where the 5th column is less than 2000.
| |
| | |
| awk '$5 > 2000' /etc/ssh/moduli > "${HOME}/moduli"
| |
| wc -l "${HOME}/moduli" # make sure there is something left
| |
| mv "${HOME}/moduli" /etc/ssh/moduli
| |
| | |
| If it does not exist, create it:
| |
| | |
| ssh-keygen -G /etc/ssh/moduli.all -b 4096
| |
| ssh-keygen -T /etc/ssh/moduli.safe -f /etc/ssh/moduli.all
| |
| mv /etc/ssh/moduli.safe /etc/ssh/moduli
| |
| rm /etc/ssh/moduli.all
| |
| | |
| This will take a while so continue while it’s running.
| |
| | |
| == Authentication ==
| |
| | |
| The key exchange ensures that the server and the client shares a secret no one else knows. We also have to make sure that they share this secret with each other and not an NSA analyst.
| |
| | |
| === Server authentication ===
| |
| | |
| The server proves its identity to the client by signing the key resulting from the key exchange. There are 4 public key algorithms for authentication:# DSA with SHA1
| |
| # ECDSA with SHA256, SHA384 or SHA512 depending on key size
| |
| # [http://ed25519.cr.yp.to/ Ed25519] with SHA512
| |
| # RSA with SHA1
| |
| | |
| | |
| | |
| DSA keys must be exactly 1024 bits so let’s disable that. Number 2 here involves NIST suckage and should be disabled as well. Another important disadvantage of DSA and ECDSA is that it uses randomness for each signature. If the random numbers are not the best quality, then it is [https://security.stackexchange.com/a/46781 possible to recover] the [https://events.ccc.de/congress/2010/Fahrplan/attachments/1780%5F27c3%5Fconsole%5Fhacking%5F2010.pdf secret key]. Fortunately, RSA using SHA1 is not a problem here because the value being signed is actually a SHA2 hash. The hash function SHA1(SHA2(x)) is just as secure as SHA2 (it has less bits of course but no better attacks).
| |
| | |
| Protocol 2
| |
| HostKey /etc/ssh/ssh_host_ed25519_key
| |
| HostKey /etc/ssh/ssh_host_rsa_key
| |
| | |
| The first time you connect to your server, you will be asked to accept the new fingerprint.
| |
| | |
| This will also disable the horribly broken v1 protocol that you should not have enabled in the first place. We should remove the unused keys and only generate a large RSA key and an Ed25519 key. Your init scripts may recreate the unused keys. If you don’t want that, remove any <tt>ssh-keygen</tt> commands from the init script.
| |
| | |
| cd /etc/ssh
| |
| rm ssh_host_*key*
| |
| ssh-keygen -t ed25519 -f ssh_host_ed25519_key < /dev/null
| |
| ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key < /dev/null
| |
| | |
| === Client authentication === | |
| | |
| The client must prove its identity to the server as well. There are various methods to do that.
| |
| | |
| The simplest is password authentication. This should be disabled immediately ''after'' setting up a more secure method because it allows compromised servers to steal passwords. Password authentication is also more vulnerable to online bruteforce attacks.
| |
| | |
| Recommended <tt>/etc/ssh/sshd_config</tt> snippet:
| |
| | |
| PasswordAuthentication no
| |
| ChallengeResponseAuthentication no
| |
| | |
| Recommended <tt>/etc/ssh/ssh_config</tt> snippet:
| |
| | |
| Host *
| |
| PasswordAuthentication no
| |
| ChallengeResponseAuthentication no
| |
| | |
| The most common and secure method is public key authentication, basically the same process as the server authentication.
| |
| | |
| Recommended <tt>/etc/ssh/sshd_config</tt> snippet:
| |
| | |
| PubkeyAuthentication yes
| |
| | |
| Recommended <tt>/etc/ssh/ssh_config</tt> snippet:
| |
| | |
| Host *
| |
| PubkeyAuthentication yes
| |
| HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ssh-rsa
| |
| | |
| Generate client keys using the following commands:
| |
| | |
| ssh-keygen -t ed25519 -o -a 100
| |
| ssh-keygen -t rsa -b 4096 -o -a 100
| |
| | |
| You can deploy your new client public keys using <tt>ssh-copy-id</tt>.
| |
| | |
| It is also possible to use OTP authentication to reduce the consequences of lost passwords. [https://code.google.com/p/google-authenticator/wiki/PamModuleInstructions Google Authenticator] is a nice implementation of [https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm TOTP], or Timebased One Time Password. You can also use a [https://www.cl.cam.ac.uk/%7Emgk25/otpw.html printed list of one time passwords] or any other [https://en.wikipedia.org/wiki/Pluggable_authentication_module PAM] module, really, if you enable <tt>ChallengeResponseAuthentication</tt>.
| |
| | |
| === User Authentication ===
| |
| | |
| Even with Public Key authentication, you should only allow incoming connections from expected users. The <tt>AllowUsers</tt> setting in <tt>sshd_config</tt> lets you specify users who are allowed to connect, but this can get complicated with a large number of ssh users. Additionally, when deleting a user from the system, the username is [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779880 not removed] from <tt>sshd_config</tt>, which adds to maintenance requirements. The solution is to use the <tt>AllowGroups</tt> setting instead, and add users to an <tt>ssh-user</tt> group.
| |
| | |
| Recommended <tt>/etc/ssh/sshd_config</tt> snippet:
| |
| | |
| AllowGroups ssh-user
| |
| | |
| Create the ssh-user group with <tt>sudo groupadd ssh-user</tt>, then add each ssh user to the group with <tt>sudo usermod -a -G ssh-user <username></tt>.
| |
| | |
| == Symmetric ciphers ==
| |
| | |
| Symmetric ciphers are used to encrypt the data after the initial key exchange and authentication is complete.
| |
| | |
| Here we have quite a few algorithms:# 3des-cbc
| |
| # aes128-cbc
| |
| # aes192-cbc
| |
| # aes256-cbc
| |
| # aes128-ctr
| |
| # aes192-ctr
| |
| # aes256-ctr
| |
| # aes128-gcm@openssh.com
| |
| # aes256-gcm@openssh.com
| |
| # arcfour
| |
| # arcfour128
| |
| # arcfour256
| |
| # blowfish-cbc
| |
| # cast128-cbc
| |
| # chacha20-poly1305@openssh.com
| |
| | |
| | |
| | |
| We have to consider the following:* ''Security of the cipher algorithm'': This eliminates 1 and 10-12 - both DES and RC4 are broken. Again, no need to wait for them to become even weaker, disable them now.
| |
| * ''Key size'': At least 128 bits, the more the better.
| |
| * ''Block size'': Does not apply to stream ciphers. At least 128 bits. This eliminates 13 and 14 because those have a 64 bit block size.
| |
| * ''Cipher mode'': The recommended approach here is to prefer [https://en.wikipedia.org/wiki/Authenticated_encryption AE] modes and optionally allow CTR for compatibility. CTR with Encrypt-then-MAC is provably secure.
| |
| | |
| | |
| | |
| Chacha20-poly1305 is preferred over AES-GCM because the SSH protocol [http://blog.djm.net.au/2013/11/chacha20-and-poly1305-in-openssh.html does not encrypt message sizes] when GCM (or EtM) is in use. This allows some traffic analysis even without decrypting the data. We will deal with that soon.
| |
| | |
| Recommended <tt>/etc/ssh/sshd_config</tt> snippet:
| |
| | |
| Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
| |
| | |
| Recommended <tt>/etc/ssh/ssh_config</tt> snippet:
| |
| | |
| Host *
| |
| Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
| |
| | |
| == Message authentication codes ==
| |
| | |
| Encryption provides ''confidentiality'', message authentication code provides ''integrity''. We need both. If an AE cipher mode is selected, then extra MACs are not used, the integrity is already given. If CTR is selected, then we need a MAC to calculate and attach a tag to every message.
| |
| | |
| There are multiple ways to combine ciphers and MACs - not all of these are useful. The 3 most common:* ''Encrypt-then-MAC'': encrypt the message, then attach the MAC of the ciphertext.
| |
| * ''MAC-then-encrypt'': attach the MAC of the plaintext, then encrypt everything.
| |
| * ''Encrypt-and-MAC'': encrypt the message, then attach the MAC of the plaintext.
| |
| | |
| | |
| | |
| Only Encrypt-then-MAC should be used, period. Using MAC-then-encrypt have lead to many attacks on TLS while Encrypt-and-MAC have lead to not quite that many attacks on SSH. The reason for this is that the more you fiddle with an attacker provided message, the more chance the attacker has to gain information through side channels. In case of Encrypt-then-MAC, the MAC is verified and if incorrect, discarded. Boom, one step, no timing channels. In case of MAC-then-encrypt, first the attacker provided message has to be decrypted and only then can you verify it. Decryption failure (due to invalid CBC padding for example) may take less time than verification failure. Encrypt-and-MAC also has to be decrypted first, leading to the same kind of potential side channels. It’s even worse because no one said that a MAC’s output can’t leak what its input was. SSH by default, uses this method.
| |
| | |
| Here are the available MAC choices:# hmac-md5
| |
| # hmac-md5-96
| |
| # hmac-ripemd160
| |
| # hmac-sha1
| |
| # hmac-sha1-96
| |
| # hmac-sha2-256
| |
| # hmac-sha2-512
| |
| # umac-64
| |
| # umac-128
| |
| # hmac-md5-etm@openssh.com
| |
| # hmac-md5-96-etm@openssh.com
| |
| # hmac-ripemd160-etm@openssh.com
| |
| # hmac-sha1-etm@openssh.com
| |
| # hmac-sha1-96-etm@openssh.com
| |
| # hmac-sha2-256-etm@openssh.com
| |
| # hmac-sha2-512-etm@openssh.com
| |
| # umac-64-etm@openssh.com
| |
| # umac-128-etm@openssh.com
| |
| | |
| | |
| | |
| The selection considerations:* ''Security of the hash algorithm'': No MD5 and SHA1. Yes, I know that HMAC-SHA1 does not need collision resistance but why wait? Disable weak crypto today.
| |
| * ''Encrypt-then-MAC'': I am not aware of a security proof for CTR-and-HMAC but I also don’t think CTR decryption can fail. Since there are no downgrade attacks, you can add them to the end of the list. You can also do this on a host by host basis so you know which ones are less safe.
| |
| * ''Tag size'': At least 128 bits. This eliminates umac-64-etm.
| |
| * ''Key size'': At least 128 bits. This doesn’t eliminate anything at this point.
| |
| | |
| | |
| | |
| Recommended <tt>/etc/ssh/sshd_config</tt> snippet:
| |
| | |
| MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com
| |
| | |
| Recommended <tt>/etc/ssh/ssh_config</tt> snippet:
| |
| | |
| Host *
| |
| MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com
| |
| | |
| === Preventing key theft ===
| |
| | |
| Even with forward secrecy the secret keys must be kept secret. The NSA has a database of stolen keys - you do not want your key there.
| |
| | |
| == System hardening ==
| |
| | |
| This post is not intended to be a comprehensive system security guide. Very briefly:* ''Don’t install what you don’t need'': Every single line of code has a chance of containing a bug. Some of these bugs are security holes. Fewer lines, fewer holes.
| |
| * ''Use free software'': As in speech. You want to use code that’s actually reviewed or that you can review yourself. There is no way to achieve that without source code. Someone may have reviewed proprietary crap but who knows.
| |
| * ''Keep your software up to date'': New versions often fix critical security holes.
| |
| * ''Exploit mitigation'': Sad but true - there will always be security holes in your software. There are things you can do to prevent their exploitation, such as GCC’s -fstack-protector. One of the best security projects out there is [https://grsecurity.net/ Grsecurity]. Use it or use OpenBSD.
| |
| | |
| | |
| | |
| == Traffic analysis resistance ==
| |
| | |
| Set up [https://www.torproject.org/docs/hidden-services.html.en Tor hidden services] for your SSH servers. This has multiple advantages. It provides an additional layer of encryption and server authentication. People looking at your traffic will not know your IP, so they will be unable to scan and target other services running on the same server and client. Attackers can still attack these services but don’t know if it has anything to do with the observed traffic until they actually break in.
| |
| | |
| Now this is only true if you don’t disclose your SSH server’s fingerprint in any other way. You should only accept connections from the hidden service or from LAN, if required.
| |
| | |
| If you don’t need LAN access, you can add the following line to <tt>/etc/ssh/sshd_config</tt>:
| |
| | |
| ListenAddress 127.0.0.1:22
| |
| | |
| Add this to <tt>/etc/tor/torrc</tt>:
| |
| | |
| HiddenServiceDir /var/lib/tor/hidden_service/ssh
| |
| HiddenServicePort 22 127.0.0.1:22
| |
| | |
| You will find the hostname you have to use in <tt>/var/lib/tor/hidden_service/ssh/hostname</tt>. You also have to configure the client to use Tor. For this, socat will be needed. Add the following line to <tt>/etc/ssh/ssh_config</tt>:
| |
| | |
| Host *.onion
| |
| ProxyCommand socat - SOCKS4A:localhost:%h:%p,socksport=9050
| |
| | |
| Host *
| |
| ...
| |
| | |
| If you want to allow connections from LAN, don’t use the <tt>ListenAddress</tt> line, configure your firewall instead.
| |
| | |
| == Key storage ==
| |
| | |
| You should encrypt your client key files using a strong password. Additionally, you can use <tt>ssh-keygen -o -a $number</tt> to slow down cracking attempts by iterating the hash function many times. You may want to store them on a pendrive and only plug it in when you want to use SSH. Are you more likely to lose your pendrive or have your system compromised? I don’t know.
| |
| | |
| Unfortunately, you can’t encrypt your server key and it must be always available, or else sshd won’t start. The only thing protecting it is OS access controls.
| |
| | |
| === The end ===
| |
| | |
| It’s probably a good idea to test the changes. <tt>ssh -v</tt> will print the selected algorithms and also makes problems easier to spot. Be extremely careful when configuring SSH on a remote host. Always keep an active session, never restart sshd. Instead you can send the <tt>SIGHUP</tt> signal to reload the configuration without killing your session. You can be even more careful by starting a new sshd instance on a different port and testing that.
| |
| | |
| Can you make these changes? If the answer is yes, then…
| |
| | |
| If the answer is no, it’s probably due to compatibility problems. You can try to convince the other side to upgrade their security and turn it into a yes. I have created a [https://github.com/stribika/stribika.github.io/wiki/Secure-Secure-Shell wiki page] where anyone can add config files for preserving compatibility with various SSH implementations and SSH based services.
| |
| | |
| If you work for a big company and change management doesn’t let you do it, I’m sorry. I’ve seen the v1 protocol enabled in such places. There is no chance of improvement. Give up to preseve your sanity.
| |
| | |
| Special thanks to the people of Twitter for the improvements.
| |
| | |
| = OpenSSH server =
| |
| | |
| == Configuration ==
| |
| | |
| Different versions of OpenSSH support different options which are not always compatible. This guide shows settings for the most commonly deployed OpenSSH versions at Mozilla - however, using the latest version of OpenSSH is recommended.
| |
| | |
| === Modern (OpenSSH 6.7+) ===
| |
| | |
| File: <tt>/etc/ssh/sshd_config</tt>
| |
| | |
| <nowiki># Supported HostKey algorithms by order of preference.</nowiki>
| |
| HostKey /etc/ssh/ssh_host_ed25519_key
| |
| HostKey /etc/ssh/ssh_host_rsa_key
| |
| HostKey /etc/ssh/ssh_host_ecdsa_key
| |
| | |
| KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
| |
| | |
| Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
| |
| | |
| MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com
| |
| | |
| <nowiki># Password based logins are disabled - only public key based logins are allowed.</nowiki>
| |
| AuthenticationMethods publickey
| |
| | |
| <nowiki># LogLevel VERBOSE logs user's key fingerprint on login. Needed to have a clear audit track of which key was using to log in.</nowiki>
| |
| LogLevel VERBOSE
| |
| | |
| <nowiki># Log sftp level file access (read/write/etc.) that would not be easily logged otherwise.</nowiki>
| |
| Subsystem sftp /usr/lib/ssh/sftp-server -f AUTHPRIV -l INFO
| |
| | |
| <nowiki># Root login is not allowed for auditing reasons. This is because it's difficult to track which process belongs to which root user:</nowiki>
| |
| <nowiki>#</nowiki>
| |
| <nowiki># On Linux, user sessions are tracking using a kernel-side session id, however, this session id is not recorded by OpenSSH.</nowiki>
| |
| <nowiki># Additionally, only tools such as systemd and auditd record the process session id.</nowiki>
| |
| <nowiki># On other OSes, the user session id is not necessarily recorded at all kernel-side.</nowiki>
| |
| <nowiki># Using regular users in combination with /bin/su or /usr/bin/sudo ensure a clear audit track.</nowiki>
| |
| PermitRootLogin No
| |
| | |
| <nowiki># Use kernel sandbox mechanisms where possible in unprivileged processes</nowiki>
| |
| <nowiki># Systrace on OpenBSD, Seccomp on Linux, seatbelt on MacOSX/Darwin, rlimit elsewhere.</nowiki>
| |
| UsePrivilegeSeparation sandbox
| |
| | |
| File: <tt>/etc/ssh/moduli</tt>
| |
| | |
| All Diffie-Hellman moduli in use should be at least 3072-bit-long (they are used for <tt>diffie-hellman-group-exchange-sha256</tt>) as per our [https://wiki.mozilla.org/Security/Guidelines/Key_Management Security/Guidelines/Key_Management] recommendations. See also <tt>man moduli</tt>.
| |
| | |
| To deactivate short moduli in two commands: <tt>awk '$5 >= 3071' /etc/ssh/moduli > /etc/ssh/moduli.tmp && mv /etc/ssh/moduli.tmp /etc/ssh/moduli</tt>
| |
| | |
| | |
| === Intermediate (OpenSSH 5.3) ===
| |
| | |
| This is mainly for use by RHEL6, CentOS6, etc. which run older versions of OpenSSH.
| |
| | |
| File: <tt>/etc/ssh/sshd_config</tt>
| |
| | |
| <nowiki># Supported HostKey algorithms by order of preference.</nowiki>
| |
| HostKey /etc/ssh/ssh_host_rsa_key
| |
| HostKey /etc/ssh/ssh_host_ecdsa_key
| |
| | |
| KexAlgorithms diffie-hellman-group-exchange-sha256
| |
| MACs hmac-sha2-512,hmac-sha2-256
| |
| Ciphers aes256-ctr,aes192-ctr,aes128-ctr
| |
| | |
| <nowiki># Password based logins are disabled - only public key based logins are allowed.</nowiki>
| |
| RequiredAuthentications2 publickey
| |
| | |
| <nowiki># RequiredAuthentications2 not work on official OpenSSH 5.3 portable.</nowiki>
| |
| <nowiki># In this is your case, use this instead:</nowiki>
| |
| <nowiki>#PubkeyAuthentication yes</nowiki>
| |
| <nowiki>#PasswordAuthentication no</nowiki>
| |
| | |
| <nowiki># LogLevel VERBOSE logs user's key fingerprint on login. Needed to have a clear audit track of which key was using to log in.</nowiki>
| |
| LogLevel VERBOSE
| |
| | |
| <nowiki># Log sftp level file access (read/write/etc.) that would not be easily logged otherwise.</nowiki>
| |
| Subsystem sftp /usr/lib/ssh/sftp-server -f AUTHPRIV -l INFO
| |
| | |
| <nowiki># Root login is not allowed for auditing reasons. This is because it's difficult to track which process belongs to which root user:</nowiki>
| |
| <nowiki>#</nowiki>
| |
| <nowiki># On Linux, user sessions are tracking using a kernel-side session id, however, this session id is not recorded by OpenSSH.</nowiki>
| |
| <nowiki># Additionally, only tools such as systemd and auditd record the process session id.</nowiki>
| |
| <nowiki># On other OSes, the user session id is not necessarily recorded at all kernel-side.</nowiki>
| |
| <nowiki># Using regular users in combination with /bin/su or /usr/bin/sudo ensure a clear audit track.</nowiki>
| |
| PermitRootLogin No
| |
| | |
| File: <tt>/etc/ssh/moduli</tt>
| |
| | |
| All Diffie-Hellman moduli in use should be at least 2048-bit-long. From the structure of <tt>moduli</tt> files, this means the fifth field of all lines in this file should be greater than or equal to 2047.
| |
| | |
| To deactivate weak moduli in two commands: <tt>awk '$5 >= 2047' /etc/ssh/moduli > /etc/ssh/moduli.tmp && mv /etc/ssh/moduli.tmp /etc/ssh/moduli</tt>
| |
| | |
| === Multi-Factor Authentication (OpenSSH 6.3+) ===
| |
| | |
| Recent versions of OpenSSH support MFA (Multi-Factor Authentication). Using MFA is recommended where possible.
| |
| | |
| It requires additional setup, such as using the [http://www.nongnu.org/oath-toolkit/ OATH Toolkit] or [https://www.duosecurity.com/ DuoSecurity].
| |
| | |
| | |
| {| style="border-spacing:0;width:17.501cm;"
| |
| |- style="border:none;padding:0.049cm;"
| |
| || <span style="color:#ff0000;">'''ATTENTION</span> '''
| |
| |- style="border:none;padding:0.049cm;"
| |
| || In order to allow using one time passwords (OTPs) and any other text input, Keyboard-interactive is enabled in OpenSSH. This ''MAY'' allow for password authentication to work. It is therefore very important to check your PAM configuration so that PAM disallow password authentication for OpenSSH.
| |
| | |
| | |
| |-
| |
| |}
| |
| ==== OpenSSH 6.3+ (default) ====
| |
| | |
| File: <tt>/etc/ssh/sshd_config</tt>
| |
| | |
| <nowiki># IMPORTANT: you will have to ensure OpenSSH cannot authenticate with passwords with PAM in /etc/pam.d/sshd</nowiki>
| |
| <nowiki># "PasswordAuthentication no" is not sufficient!</nowiki>
| |
| PubkeyAuthentication yes
| |
| PasswordAuthentication no
| |
| AuthenticationMethods publickey,keyboard-interactive:pam
| |
| KbdInteractiveAuthentication yes
| |
| UsePAM yes
| |
| <nowiki># Ensure /bin/login is not used so that it cannot bypass PAM settings for sshd.</nowiki>
| |
| UseLogin no
| |
| | |
| ==== OpenSSH 5.3+ w/ RedHat/CentOS patch (old) ====
| |
| | |
| File: <tt>/etc/ssh/sshd_config</tt>
| |
| | |
| <nowiki># Allow keyboard-interactive.</nowiki>
| |
| <nowiki># IMPORTANT: you will have to ensure OpenSSH cannot authenticate with passwords with PAM in /etc/pam.d/sshd</nowiki>
| |
| <nowiki># "PasswordAuthentication no" is not sufficient!</nowiki>
| |
| RequiredAuthentications2 publickey,keyboard-interactive:skey
| |
| PasswordAuthentication no
| |
| ChallengeResponseAuthentication yes
| |
| UsePAM yes
| |
| <nowiki># Ensure /bin/login is not used so that it cannot bypass PAM settings for sshd.</nowiki>
| |
| UseLogin no
| |
| | |
| PAM configuration for use with the [https://www.nongnu.org/oath-toolkit/ OATH Toolkit] or [https://www.duosecurity.com/ DuoSecurity] as second authentication factor.
| |
| | |
| File: <tt>/etc/pam.d/sshd</tt>
| |
| | |
| <nowiki>#%PAM-1.0</nowiki>
| |
| auth required pam_sepermit.so
| |
| | |
| <nowiki># WARNING: make sure any password authentication module is disabled.</nowiki>
| |
| <nowiki># Example: pam_unix.so, or "password-auth", "system-auth", etc.</nowiki>
| |
| <nowiki>#auth </nowiki> include password-auth
| |
| | |
| <nowiki># Options to enable when using OATH toolkit</nowiki>
| |
| <nowiki>#auth </nowiki> requisite pam_oath.so usersfile=/etc/users.oath digits=6 window=20
| |
| | |
| <nowiki># Options to enable when using DuoSecurity</nowiki>
| |
| <nowiki>#auth </nowiki> sufficient /lib64/security/pam_duo.so
| |
| | |
| account required pam_nologin.so
| |
| | |
| == Ciphers and algorithms choice ==
| |
| | |
| * When CHACHA20 (OpenSSH 6.5+) is not available, AES-GCM (OpenSSH 6.1+) and any other algorithm using EtM (Encrypt then MAC) [http://blog.djm.net.au/2013/11/chacha20-and-poly1305-in-openssh.html disclose the packet length] - giving some information to the attacker. Only recent OpenSSH servers and client support CHACHA20.
| |
| | |
| * NIST curves (<tt>ecdh-sha2-nistp512,ecdh-sha2-nistp384,ecdh-sha2-nistp256</tt>) are listed for compatibility, but the use of <tt>curve25519</tt> is [https://safecurves.cr.yp.to/ generally preferred].
| |
| | |
| * SSH protocol 2 supports [https://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange DH] and [https://en.wikipedia.org/wiki/Elliptic_curve_Diffie–Hellman ECDH] key-exchange as well as [https://en.wikipedia.org/wiki/Forward_secrecy forward secrecy]. Regarding group sizes, please refer to [https://wiki.mozilla.org/Security/Guidelines/Key_Management Security/Guidelines/Key_Management].
| |
| | |
| | |
| | |
| The various algorithms supported by a particular OpenSSH version can be listed with the following commands:
| |
| | |
| $ ssh -Q cipher
| |
| $ ssh -Q cipher-auth
| |
| $ ssh -Q mac
| |
| $ ssh -Q kex
| |
| $ ssh -Q key
| |
| | |
| = OpenSSH client =
| |
| | |
| == Configuration ==
| |
| | |
| If you have a file containing known_hosts using RSA or ECDSA host key algorithm and the server now supports ed25519 for example, you will get a warning that the host key has changed and will be unable to connect. This means you will have to verify the new host key.
| |
| | |
| The following configurations expect a recent OpenSSH client, as updating OpenSSH on the client side is generally not an issue.
| |
| | |
| === Modern ===
| |
| | |
| This configuration is less compatible and you may not be able to connect to some servers which use insecure, deprecated algorithms. Nevertheless, modern servers will work just fine.
| |
| | |
| File: <tt>~/.ssh/config</tt>
| |
| | |
| <nowiki># Ensure KnownHosts are unreadable if leaked - it is otherwise easier to know which hosts your keys have access to.</nowiki>
| |
| HashKnownHosts yes
| |
| <nowiki># Host keys the client accepts - order here is honored by OpenSSH</nowiki>
| |
| HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ssh-rsa,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256
| |
| | |
| KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
| |
| MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com
| |
| Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
| |
| | |
| === Intermediate (connects to older servers) ===
| |
| | |
| This configuration can connect to older OpenSSH servers which run old or intermediate configurations.
| |
| | |
| File: <tt>~/.ssh/config</tt>
| |
| | |
| <nowiki># Ensure KnownHosts are unreadable if leaked - it is otherwise easier to know which hosts your keys have access to.</nowiki>
| |
| HashKnownHosts yes
| |
| <nowiki># Host keys the client accepts - order here is honored by OpenSSH</nowiki>
| |
| HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256
| |
| | |
| == Key generation ==
| |
| | |
| Large key sizes are used as SSH keys are not renewed very often (see also [https://wiki.mozilla.org/Security/Key_Management Security/Key_Management]).
| |
| | |
| <div style="margin-left:1cm;margin-right:1cm;">'''''Note:''' ''</div>
| |
| | |
| <div style="margin-left:1cm;margin-right:1cm;">''DSA and RSA 1024 bit (or lower) keys are considered weak and should be replaced as soon as possible. ''</div>
| |
| | |
| Don't hesitate to create multiple different keys for different usages. In particular, never mix your personal and Mozilla keys.
| |
| | |
| <nowiki># RSA keys are favored over ECDSA keys when backward compatibility ''is required'',</nowiki>
| |
| <nowiki># thus, newly generated keys are always either ED25519 or RSA (NOT ECDSA or DSA).</nowiki>
| |
| $ ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_mozilla_$(date +%Y-%m-%d) -C "Mozilla key for xyz"
| |
| | |
| <nowiki># ED25519 keys are favored over RSA keys when backward compatibility ''is not required''.</nowiki>
| |
| <nowiki># This is only compatible with OpenSSH 6.5+ and fixed-size (256 bytes).</nowiki>
| |
| $ ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_mozilla_$(date +%Y-%m-%d) -C "Mozilla key for xyz"
| |
| | |
| You may then want to add the new key to your SSH agent or your configuration file (or both).
| |
| | |
| <nowiki># Add key to ssh-agent</nowiki>
| |
| $ ssh-add ~/.ssh/id_..._mozilla... # <= replace by your key's path
| |
| <nowiki># Add configuration to ~/.ssh/config</nowiki>
| |
| host *.mozilla.com
| |
| IdentityFile ~/.ssh/id_...mozilla... # <= replace by your key's path
| |
| | |
| === Protection of user keys ===
| |
| | |
| * Protected by strong passphrase.
| |
| * Never copied to another system than your own workstation/personal physical disks/tokens.
| |
| * Use SSH forwarding or SSH tunneling if you need to jump between hosts. '''DO NOT''' maintain unnecessary agent forwarding when unused.
| |
| | |
| | |
| | |
| === Protection of machine keys ===
| |
| | |
| When SSH keys are necessary for automation between systems, it is reasonable to use passphrase-less keys. * The recommended settings are identical to the user keys.
| |
| * The keys must be accessible only by the admin user (root) and/or the system user requiring access.
| |
| * Usage of machine keys should be registered in an inventory (a wiki page, ldap, an inventory database), to allow for rapid auditing of key usage across an infrastructure.
| |
| * The machine keys should be unique per usage. Each new usage (different service, different script called, etc.) should use a new, different key.
| |
| * Only used when strictly necessary.
| |
| * Restrict privileges of the account (i.e. no root or "sudoer" machine account).
| |
| * Using a ForceCommand returning only the needed results, or only allowing the machine to perform SSH-related tasks such as tunneling is prefered.
| |
| * Disable sftp if not needed as it exposes more surface and different logging mechanisms than SSH (and thus scp) itself.
| |
| | |
| | |
| | |
| <div style="margin-left:1cm;margin-right:1cm;">'''''Note:''' ''</div>
| |
| | |
| <div style="margin-left:1cm;margin-right:1cm;">''You may want to use the group "users" instead of "sftpusers" in the example below as this may already exist and include all regular users by default. ''</div>
| |
| | |
| <nowiki># groupadd sftpusers</nowiki>
| |
| <nowiki># usermod -a -g sftpusers <userthat_needs_ftp></nowiki>
| |
| <nowiki># chgrp sftpusers /usr/lib/ssh/sftp-server</nowiki>
| |
| <nowiki># chmod 0750 /usr/lib/ssh/sftp-server</nowiki>
| |
| | |
| ==== Multi-factor bypass setup for machine keys ====
| |
| | |
| Machine keys do not play well with multi-factor authentication as there is no human interaction. * All logins from machine accounts should be protected by an additional authentication layer (VPN, another machine, etc.).
| |
| * All logins from machine accounts are only allowed within the private IP-space, and if possible, only the relevant machine source IPs should be accessible.
| |
| | |
| | |
| | |
| File: <tt>/etc/ssh/sshd_config</tt> (OpenSSH 6.3+)
| |
| | |
| Match User machine_user Address 10.0.0.0/8,192.168.0.0/16,172.16.0.0/12
| |
| PubkeyAuthentication yes
| |
| KbdInteractiveAuthentication no
| |
| AuthenticationMethods publickey
| |
| | |
| File: <tt>/etc/ssh/sshd_config</tt> (OpenSSH 5.3+ w/ RedHat/CentOS patch)
| |
| | |
| Match User machine_user Address 10.0.0.0/8,192.168.0.0/16,172.16.0.0/12
| |
| RequiredAuthentications2 publickey
| |
| | |
| === Auditing your existing SSH keys ===
| |
| | |
| Existing keys are generally stored in <tt>~/.ssh/</tt> (Linux/OSX) or <tt>%APPDATA%</tt> (Windows). Look for <tt>id_{rsa,ed25519,ecdsa,dsa}, identity, IdentityFile, *.pem</tt>, and other <tt>identity</tt> files.
| |
| | |
| ==== Display SSH keys information ====
| |
| | |
| <nowiki># You may run this for any key file that you have.</nowiki>
| |
| $ ssh-keygen -lf id_rsa
| |
| 2048 bc:4f:46:2b:3d:f1:e2:0f:ac:40:99:49:ed:c9:81:a2 Mozilla key for xyz (RSA)
| |
| ^^ ^^^^^^^^^ ^^^^ ^^^
| |
| |__ Size |__ Fingerprint |__ Comment |__ Type
| |
| | |
| == SSH agent forwarding ==
| |
| | |
| | |
| {| style="border-spacing:0;width:17.501cm;"
| |
| |- style="border:none;padding:0.049cm;"
| |
| || <span style="color:#ff0000;">'''ATTENTION</span> '''
| |
| |- style="border:none;padding:0.049cm;"
| |
| || SSH Agent forwarding exposes your authentication to the server you're connecting to. By default, an attacker with control of the server (i.e. root access) can communicate with your agent and use your key to authenticate to other servers without any notification (i.e. impersonate you).For this reason, one must be careful when using SSH agent forwarding. Defaulting to always forwarding the agent is strongly discouraged.Note also that while the attacker can use your key as long as the agent is running and forwarded, he cannot steal/download the key for offline/later use.
| |
| |-
| |
| |}
| |
| SSH forwarding allows you to jump between hosts while keeping your private key on your local computer. This is accomplished by telling SSH to forward the authentication requests back to the ssh-agent of your local computer. SSH forwarding works between as many hosts as needed, each host forwarding new authentication request to the previous host, until the ssh-agent that holds the private key is reached.
| |
| | |
| [[Image:Bild1.png|top|alt="Ssh forwarding.png"]]
| |
| | |
| On each host, two environment variables are declared for the user enabling ssh-agent: * '''$SSH_AUTH_SOCK''' declares the location of the unix socket that can be used to forward an authentication request back to the previous host.(ex: /tmp/ssh-NjPxtt8779/agent.8779). Only present if using SSH agent forwarding.
| |
| * '''$SSH_CONNECTION''' shows the source IP and port of the previous host, as well as the local IP and port. (ex: 10.22.248.74 44727 10.8.75.110 22).
| |
| | |
| | |
| | |
| To use ssh-agent, add the flag <tt>-A</tt> to your ssh commands:
| |
| | |
| $ ssh -A user@ssh.mozilla.com
| |
| | |
| You can set the following configuration parameter in your local ssh configuration at ~/.ssh/config.
| |
| | |
| Host ssh.mozilla.com
| |
| ForwardAgent yes
| |
| | |
| === Hardening the Agent forwarder ===
| |
| | |
| It is possible to require confirmation every time the agent is used (i.e. when you connect to a server through the SSH agent) by using the <tt>-c</tt> flag:
| |
| | |
| <nowiki># First, remove the key from the agent if it's already loaded:</nowiki>
| |
| $ ssh-add -d ~/.ssh/id_ed25519
| |
| <nowiki># And re-add it with the -c flag:</nowiki>
| |
| $ ssh-add -c ~/.ssh/id_ed25519
| |
| | |
| It is also possible to lock the key in the agent after a configurable amount of time, this can be done either for all keys when starting the agent, or per key when adding the keys to the agent with the <tt>-t</tt> flag:
| |
| | |
| <nowiki># Keep all keys decrypted/useable in memory for 30 minutes (1800 seconds)</nowiki>
| |
| $ ssh-agent -t 1800
| |
| <nowiki># First, remove the key from the agent if it's already loaded:</nowiki>
| |
| $ ssh-add -d ~/.ssh/id_ed25519
| |
| <nowiki># Re-add it, with the -t flag to keep this specific key decrypted/useable in memory for 30 minutes (1800 seconds)</nowiki>
| |
| $ ssh-add -t 1800 ~/.ssh/id_ed25519
| |
| | |
| For MacOSX in particular it's possible to save the passphrase in the Keychain. If you do so it is strongly recommended to also change the keychain setting to lock itself when the computer is locked, and/or to timeout and lock the keychain. These settings are not controlled by OpenSSH.
| |
| | |
| <nowiki># MacOSX only - save the passphrase in the Keychain</nowiki>
| |
| $ ssh-add -K ~/.ssh/id_ed25519
| |
| | |
| <div style="margin-left:1cm;margin-right:1cm;">'''''Note:''' ''</div>
| |
| | |
| <div style="margin-left:1cm;margin-right:1cm;">''There are also some third-party patches for various OpenSSH clients that will notify you visually when the agent is being used. ''</div>
| |
| | |
| <div style="margin-left:1cm;margin-right:1cm;">''These are not officially supported and may require you to recompile OpenSSH. ''</div>* [https://github.com/gdestuynder/openssh-portable/commits/libnotify OpenSSH Linux] ''
| |
| * [https://github.com/gdestuynder/putty-pagent-notification/commits/master PuTTY/Pageant] ''
| |
| * [https://github.com/gdestuynder/gnupg-agent-notification/commit/57697146188d52f5447a50303070371a8cf5c0bb GnuPG Agent Linux] ''
| |
| * [https://github.com/devinteske/apple/tree/master/OpenSSH-186/openssh OpenSSH MacOS X] (see also [http://devinteske.com/ http://devinteske.com/])''
| |
| | |
| | |
| | |
| === Recommended, safer alternatives to SSH agent forwarding ===
| |
| | |
| ==== OpenSSH >=7.3 ====
| |
| | |
| OpenSSH 7.3 onwards allow users to jump through several hosts in a rather automated fashion. It has full support for scp and sftp commands as well as regular ssh.
| |
| | |
| For example to reach a host behind a bastion/jumphost:
| |
| | |
| <nowiki># Single jump</nowiki>
| |
| $ ssh -J ssh.mozilla.com myhost.private.scl3.mozilla.com
| |
| | |
| <nowiki># Jump through 2 hops</nowiki>
| |
| $ ssh -J ssh.mozilla.com,ec2-instance.aws.net 10.0.0.3
| |
| | |
| <nowiki># Copy data from a host</nowiki>
| |
| $ scp -oProxyJump=ssh.mozilla.com myhost.private.scl3.mozilla.com:/home/kang/testfile ./
| |
| | |
| You can also add these lines to your <tt>~/.ssh/config</tt>
| |
| | |
| Host *.mozilla.com !ssh.mozilla.com
| |
| ProxyJump ssh.mozilla.com
| |
| | |
| ==== Older versions of OpenSSH ====
| |
| | |
| It is possible to directly forward ports for single jumps instead of forwarding the agent. This has the advantage of never exposing your agent to the servers you're connecting to.
| |
| | |
| For example, you can add these lines to your <tt>~/.ssh/config</tt>
| |
| | |
| Host *.mozilla.com !ssh.mozilla.com
| |
| ProxyCommand ssh ssh.mozilla.com -W %h:%p
| |
| | |
| This will automatically forward the SSH connection over ssh.mozilla.com when you connect to a mozilla.com SSH server.
| |
| | |
| = Appendixes =
| |
| | |
| == Key material handling ==
| |
| | |
| Key material identifies the cryptographic secrets that compose a key. All key material must be treated as <span style="color:#ffa500;">RESTRICTED</span> data, meaning that: * Only individual with specific training and need-to-know should have access to key material.
| |
| * Key material must be encrypted on transmission.
| |
| * Key material can be stored in clear text, but only with proper access control (limited access).
| |
| | |
| | |
| | |
| This includes: * OpenSSH server keys (<tt>/etc/ssh/ssh_host_*key</tt>)
| |
| * Client keys (<tt>~/.ssh/id_{rsa,dsa,ecdsa,ed25519}</tt> and <tt>~/.ssh/identity</tt>).
| |
| | |
| | |
| | |
| == Client key size and login latency ==
| |
| | |
| In order to figure out the impact on performance of using larger keys - such as RSA 4096 bytes keys - on the client side, we have run a few tests:
| |
| | |
| On an idle, i7 4500 intel CPU using OpenSSH_6.7p1, OpenSSL 1.0.1l and ed25519 server keys the following command is ran 10 times:
| |
| | |
| <tt>time ssh localhost -i .ssh/id_thekey exit</tt>
| |
| | |
| Results:
| |
| | |
| | |
| {| style="border-spacing:0;width:6.846cm;"
| |
| |- style="border:none;padding:0.049cm;"
| |
| || '''Client key '''
| |
| || '''Minimum '''
| |
| || '''Maximum '''
| |
| || '''Average '''
| |
| |- style="border:none;padding:0.049cm;"
| |
| || RSA 4096
| |
| || 120ms
| |
| || 145ms
| |
| || 127ms
| |
| |- style="border:none;padding:0.049cm;"
| |
| || RSA 2048
| |
| || 120ms
| |
| || 129ms
| |
| || 127ms
| |
| |- style="border:none;padding:0.049cm;"
| |
| || ed25519
| |
| || 117ms
| |
| || 138ms
| |
| || 120ms
| |
| |-
| |
| |}
| |
| Keep in mind that these numbers may differ on a slower machine, and that this contains the complete login sequence and therefore is subject to variations. However, it seems safe to say that the latency differences are not significant and do not impact performance sufficiently to cause any concern regardless of the type of key used.
| |
|
| |
|
| == Reference documents ==
| | <noinclude> |
|
| |
|
| * [https://wiki.mozilla.org/Security/Key_Management Key Management]
| | </noinclude> |
| * [https://wiki.mozilla.org/Security/Server_Side_TLS Server Side TLS]
| |
| * [https://www.ietf.org/rfc/rfc4418.txt RFC4418 (umac)]
| |
| * [http://www.openssh.com/txt/draft-miller-secsh-umac-01.txt umac draft]
| |
| * [https://safecurves.cr.yp.to/ Safe curves]
| |
| * [http://blog.djm.net.au/2013/11/chacha20-and-poly1305-in-openssh.html DJM blog]
| |
| * [https://stribika.github.io/2015/01/04/secure-secure-shell.html Stribika blog]
| |
| * [http://2013.diac.cr.yp.to/slides/gueron.pdf AES-GCM performance study]
| |
| * [https://security.googleblog.com/2014/04/speeding-up-and-strengthening-https.html CHACHA20 vs AES-GCM performance study]
| |
| * [http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.bin/ssh/PROTOCOL.certkeys?rev=1.9&content-type=text/plain PROTOCOL.certkeys]
| |
| * [https://wiki.gnupg.org/rfc4880bis rfc44880bis from GnuPG]
| |
| * [https://weakdh.org/ Weak Diffie-Hellman and the Logjam Attack]
| |
| * [https://jbeekman.nl/blog/2015/05/ssh-logjam/ On OpenSSH and Logjam, by Jethro Beekman]
| |
|
| |
|
| [[Category:Entwurf]] | | [[Kategorie:SSH]] |
| | [[Kategorie:Telnet]] |