| Start | Kontakt |
Es gibt viele tolle Programme mit denen man aus dem Internet auf seinen eigenen Rechner zugreifen kann, z.B. FTP-Server, VNC-Server, etc..
Aber die meisten bieten keine verschlüsselte Verbindung, so dass das Anmeldungs-Passwort und die Daten unverschlüsselt übertragen werden.
Diese Daten wandern im Internet über unzählige Rechner bis sie endlich am Ziel angekommen sind, jeder dieser Rechner könnte die Daten speichern, analysieren oder sogar modifizieren.
Auf jeden Fall eine einfache Art zum Einbruch in die Privatsphäre oder zum Erlangen von internen Geschäftsinformationen (z.B. Dateien von Word, Excel und PowerPoint).
Hier bietet ein SSH-Server Abhilfe (SSH bedeutet Secure SHell), indem man eine verschlüsselte Verbindung zu diesem Server aufbaut.
Durch diese sichere Verbindung können dann andere Dienste geschleust werden, was man als "Tunneln" bezeichnet.
Dadurch ändert sich aber auch die Bedienung bzw. Konfiguration dieser Dienste (VNC, etc.).
Man verbindet sich nicht mehr direkt mit dem Server, sondern mit dem Tunnel-Eingang auf dem eigenen Rechner der dann die Verbindung zum Server über die verschlüsselte Verbindung herstellt.
Man kann jeden Dienst tunneln der mit festgelegten Ports arbeitet, leider gehört FTP nicht dazu, aber SSH bietet hier einen gleichwertigen Ersatz mit den SCP- und SFTP-Diensten.
Wir zäumen das Pferd von hinten auf und kümmern uns erstmal um die Einrichtung eines SSH-Client, der sich mit einem SSH-Server verbinden will.
"Der" SSH-Client für Windows ist Putty.
Einfach runterladen und in das gewünschte Zielverzeichnis installieren, z.B. C:\Programme\Putty.
Für die Einrichtung einer SSH-Verbindung muss man folgende Daten wissen:
Name oder IP-Adresse des SSH-Servers im Internet (z.B. 81.82.103.104 oder test.dyndns.org), den Server-Port (meistens 22 für SSH), einen gültigen Benutzernamen auf dem SSH-Server und ob der SSH-Server Zugang über Passwörter und/oder über Schlüssel gewährt.
Bei Passwörtern braucht man natürlich das zum Benutzer gehörende Passwort und bei Schlüsseln muss man sich einen entsprechenden Schlüssel erstellen (mehr dazu nach der Konfiguration).
Nun startet man Putty (Datei "putty.exe") und gibt in der Kategorie "Session" die Adresse und Port des Servers ein.
Falls der Server nur Zugang über Schlüssel gewährt, dann muss man in der Kategorie "Connection → SSH → Auth" die Datei mit dem privaten Schlüssel (endet mit ".ppk") eingetragen werden.
Tunnel definiert man in der Kategorie "Connection → SSH → Tunnels" (mehr zu Tunneln nach dem SSH-Server).
Hat man alles entsprechend konfiguriert sollte man in der Kategorie "Session" einen sprechenden Namen für diese Verbindung in das Feld "Saved Sessions" eingeben und speichern.
Mit einem Doppelklick auf einen Namen in der darunterliegenden Liste wird die ausgewählte Verbindung aufgebaut.
Muss man mal eine Konfiguration ändern, einfach den Namen anklicken und laden, dann die Änderungen vornehmen und - ganz wichtig - wieder speichern.
Beim allerersten Öffnen einer Verbindung zu einem Server fragt Putty, ob man dem Schlüssel des SSH-Servers vertraut, dazu zeigt es den dazugehörigen Fingerprint des Schlüssels an.
Diesen sollte man per eMail, ICQ oder Telefon mit dem Administrator des Servers abgleichen.
Diese Frage erscheint auch wieder wenn sich der Schlüssel des Servers ändern sollte, da eventuell auch der Server gehackt sein könnte.
Deshalb immer und unbedingt den Schlüssel mit dem Server-Administrator verifizieren.
Nach Aufbau der Verbindung sollte ein Fenster mit der Aufforderung "Login as:" erscheinen, dort gibt man den Benutzer ein.
Danach wird man entweder nach dem Passwort des Benutzers gefragt oder bei Schlüssel-Zugang eventuell nach dem Passwort für den eigenen privaten Schlüssel.
Im Normalfall erhält man dann eine Kommandozeile auf dem SSH-Server, dies kann aber auf dem Server auch anders eingestellt sein.
Da eine Authentifizierung mit Schlüsseln die sicherste Variante ist, wird man eigentlich nur SSH-Server finden, welche diese Methode voraussetzen.
Dazu muss man sich selbst einen privaten Schlüssel erstellen.
"Privat" bedeutet dabei, dass dieser private Schlüssel nie in andere Hände gelangen darf.
Damit ist sichergestellt, dass dieser Schlüssel nur von einem selbst benutzt wird.
Falls der private Schlüssel doch mal geklaut/kopiert wird, oder wenn man sich nicht sicher ist ob der Schlüssel immer noch "privat" ist, dann alle Leute, mit denen man über diesen Schlüssel kommuniziert, darüber informieren, einen neuen privaten Schlüssel erstellen und den dazugehörigen neuen öffentlichen Schlüssel an die anderen Leute weitergeben.
Einen Schlüssel erstellt man mit PuttyGen.
Nach dem Start kann man den Sicherheitsgrad des Schlüssels einstellen, hier ist der Standard (SSH2 RSA 1024 bits) vollkommen ausreichend und man kann einfach auf "Generieren" klicken.
Nun muss man solange die Maus über das PuttyGen-Fenster bewegen bis der obere Balken voll ist.
Durch die Bewegung werden Zufallszahlen generiert, mit denen dann der Schlüssel erzeugt wird und dieser damit nicht reproduzierbar ist.
Nach dem der Schlüssel also generiert wurde sollte man diesem unbedingt ein Passwort verpassen, damit auch der Schlüssel selbst geschützt ist.
Ansonsten liegt dieser im Klartext auf der Festplatte und könnte von jedem ohne Hindernis missbraucht werden.
Achtung! Gross- und Kleinschreibung werden bei Passwörtern beachtet.
Man kann und sollte auch einen Kommentar für den Schlüssel vergeben.
Dieser Kommentar wird einem angezeigt, wenn man das Schlüssel-Passwort eingeben soll/muss.
Es sollte daher etwas Sinniges drin stehen, damit man weiss um welchen Schlüssel es sich handelt und das dazugehörige Passwort eingeben kann.
Falls man mehrere Schlüssel generiert, um z.B. für jeden SSH-Server einen eigenen zu verwenden, dann sollte auch der Servername im Kommentar stehen.
Beispiel-Kommentar: "maddes.ssh" oder "maddes.ssh@home".
Nachdem wir den privaten Schlüssel komplett erstellt haben, muss man diesen nur noch mit "Save private key" speichern, z.B. als "maddes.ppk".
Diese Datei mit dem privaten Schlüssel kann man dann in Putty bei der Konfiguration einer Verbindung angeben.
Keine Angst man kann auch nachträglich einen Kommentar oder ein Passwort vergeben bzw. ändern.
Einfach den privaten Schlüssel mit PuttyGen laden, editieren und wieder abspeichern.
PuttyGen wird aber auch noch für die Bekanntmachung des eigenen öffentlichen Schlüssels auf dem SSH-Server gebraucht.
Wenn man einen privaten Schlüssel erzeugt hat, oder mit "Load" wieder geladen, dann zeigt PuttyGen im oberen Bereich den dazugehörigen öffentlichen Schlüssel in der Form die der SSH-Server benötigt.
Also alles markieren, in die Zwischenablage kopieren und dann per eMail, ICQ oder auf einem anderen Wege dem Administrator des SSH-Servers zukommen lassen.
Fehlt der öffentliche Schlüssel auf dem SSH-Server, so schlägt die Anmeldung am SSH-Server fehl, da die von Putty mit dem privaten Schlüssel verschlüsselten Daten auf dem SSH-Server nicht wieder entschlüsselt werden können.
Für einen SSH-Server auf dem eigenen Windows-Rechner empfiehlt sich die Installation der CygWin Umgebung inkl. dessen Windows-Portierung von OpenSSH für Unix.
Es gibt zwar auch reduzierte Zusammenstellungen wie OpenSSH for Windows, freeSSHd oder CopSSH, diese sind aber teilweise veraltet oder bringen keinen besonderen Vorteil.
Bei der Installation von CygWin für einen SSH-Server müssen die folgenden Pakete berücksichtigt werden:
| Category | Package | Version (or later) |
|---|---|---|
| Admin | cygrunsrv | 1.17-1 |
| Base | coreutils | 6.7-2 |
| Base | cygwin | 1.5.24-2 |
| Libs | crypt | 1.1-1 |
| Libs | libiconv2 | 1.11-1 |
| Libs | libintl3 (gettext) | 0.14.5-1 |
| Libs | minires | 1.01-1 |
| Libs | openssl (see Net) | |
| Libs | zlib | 1.2.3-2 |
| Net | openssh | 4.6p1-1 |
| Net | openssl | 0.9.8e-3 |
| Shells | ash | 20040127-3 |
| System | sysvinit | 2.84-4 |
OpenSSH for Windows hat ein paar schöne Skripte und Programme seinem Paket hinzugefügt, diese habe ich mit ein paar weiteren Skripten zusammengefasst. Diese kann man einfach ins CygWin-Verzeichnis entpacken: OpenSSH_for_Windows_Maddes_20070420.zip (26KB).
Nach der Installation sollte man unbedingt alle Dokumentationen des Packages lesen, dort sind die wichtigsten Schritte zur Konfiguration sowie die Formate und Inhalte aller Konfigurationsdateien erklärt.
Man sollte den SSH-Server erst später ins Internet stellen, wenn dieser komplett konfiguriert und getestet ist.
Als Erstes muss man die Datei "/etc/passwd" kontrollieren, da diese alle Benutzer des eigenen Rechners aufführt.
Die Definition der Zeilen in "/etc/passwd" findet man auch in der Dokumentation.
Der erste Eintrag in der Zeile gibt den Namen des SSH-Benutzers an.
Am Anfang sind dies die Windows-Benutzer, aber man kann jeden beliebigen Namen vergeben oder auch Zeilen duplizieren und den SSH-Namen ändern.
Die Einträge danach stellen die Verbindung zum Windows-Benutzer her, unter dem dieser SSH-Benutzer auf dem Windows-SSH-Server arbeitet.
Die Bewegungsfreiheit eines SSH-Benutzers auf dem SSH-Server wird durch die Privilegien des dahinterliegenden Windows-Benutzer eingeschränkt, z.B. durch dessen NTFS-Berechtigungen usw.
Der letzte Eintrag in der Zeile gibt die Shell an, welche für diesen SSH-Benutzer geöffnet wird.
Der Shell-Eintrag "/bin/switch" des OpenSSH for Windows Package öffnet normalerweise eine Windows-Eingabeaufforderung (cmd.exe) und für SCP und SFTP das entspreche Server-Programm.
Man kann aber auch eine Batch-Datei eintragen, welche keine Shell öffnet sondern mit dem Pause-Befehl nur auf eine Eingabe wartet und dann endet.
Man sollte "/etc/passwd" unbedingt nur auf die benötigten Benutzer kürzen, dabei kann man den Eintrag des Windows-Benutzers GUEST kopieren, um weitere SSH-Benutzer mit nur wenig Privilegien zu erstellen.
Mittels "ssh-host-config" richtet man dann den SSH-Server ein: es werden die privaten und öffentlichen Schlüssel für den SSH-Server erzeugt, auf Wunsch ein extra SSH-Benutzer angelegt, eine Sicherheitseinstellungen abgefragt und der SSH-Server wird als Windows-Dienst registriert.
Will man den SSH-Server nur bei Bedarf starten, so sollte man den Starttyp des Windows-Dienstes auf "manuell" setzen.
Dann ist aber eine SSH-Anmeldung auf dem Server nur möglich, wenn schon ein Benutzer mit Admin-Rechten auf dem Rechner angemeldet ist/war und dieser den SSH-Dienst gestartet und nicht wieder gestoppt hat.
Weitere Informationen zu SSH findet man auf der ssh Mailing List, im A CygWin SSH VNC HowTo oder in den c't-Ausgaben 10/2003 (SSH) sowie c't 22/2002 (VNC).
Und natürlich massenhaft im Rest des Worldwide Webs.
Jetzt kann man versuchen sich von einem zweiten Rechner im LAN mit seinem eigenen SSH-Server zu verbinden.
Der Login erfolgt mit dem Namen eines SSH-Benutzers und dem Passwort des dahinterliegenden Windows-Benutzers.
Beim ersten Verbinden mit dem SSH-Server wird der Benutzer gefragt, ob er dem Schlüssel des Servers vertraut.
Dazu wird ihm ein Fingerprint des Schlüssels angezeigt, den er mit dem Server-Administrator abgleichen sollte.
Also muss man den Schlüssel-Fingerprint des eigenen Servers in Erfahrung bringen, dazu lädt man mit PuttyGen (siehe oben beim SSH-Client) die privaten Schlüssel des Servers aus "/etc" und schreibt sich die dazugehörigen Fingerprints in eine Datei.
Für das aktuelle und üblicherweise verwendete SSH Protokoll 2 sind dies die Dateien "/etc/ssh_host_rsa_key" und "/etc/ssh_host_dsa_key".
Konnte man nun seinen eigenen Server-Schlüssel überprüfen und sich am SSH-Server anmelden, dann ist die Grundkonfiguration abgeschlossen.
Der SSH-Server ist zwar schon einsatzbereit, aber man sollte aus Sicherheitsgründen weitere Einstellungen vornehmen, um die Sicherheit noch weiter zu erhöhen.
Am Sichersten ist die Authentifizierung nur(!) über Schlüssel.
Damit sich ein SSH-Benutzer über Schlüssel anmelden kann, muss man den oder die öffentlichen Schlüssel des Benutzers in die Datei "authorized_keys" im Verzeichnis ".ssh" unter dem Home-Verzeichnis des dazugehörigen Windows-Benutzers eintragen.
In diesem Package ist das Home-Verzeichnis das Windows-Benutzerverzeichnis, auf einem deutschen Windows normalerweise "C:\Dokumente und Einstellungen\<username>\".
Leider kann man mit dem Explorer keine Verzeichnisse erstellen welche mit einem Punkt beginnen, deshalb muss man dies über die Kommandozeile und dem Befehl "mkdir" erledigen.
Ein Schlüssel muss in einer einzigen Zeile auf eine ganze bestimmte Weise eingetragen werden.
Vorne steht der Typ des Schlüssels, entweder "ssh-rsa" oder "ssh-dsa", danach folgt der Schlüssel als lange Kette von Zeichen und am Ende ein Kommentar, der dem Benutzer beim Anmelden angezeigt wird.
Diese Zeile bekommt man vom Benutzer zugeschickt, und man sollte sich wegen der eigenen Sicherheit persönlich beim Benutzer überzeugen, dass dieser Schlüssel auch wirklich seiner ist.
Falls ein Benutzer Probleme hat die richtige Schlüssel-Zeile zu liefern, so ist oben beim SSH-Client erklärt wie er diese findet.
In "authorized_keys" kann man auch noch weitere Einstellungen für jeden einzelnen Schlüssel definieren, welche man beim reinen Passwort-Zugang nicht hat.
Die Optionen werden einfach vor dem Schlüssel eingefügt.
Welche Optionen es gibt findet man in der Dokumentation zum SSH-Server (sshd), z.B. begrenzt permitopen="host:port" die möglichen Tunnel die ein SSH-Client aufbauen kann.
Falls man FAT32-Laufwerke verwendet und es Probleme mit der Anmeldung über Schlüssel gibt, so sollte man in "/etc/sshd_config" den Eintrag "StrictModes" auf "no" stellen.
Als Letztes sollte man die Authentifizierung über Passwörter deaktivieren, indem man den Eintrag "PasswordAuthentication" auf "no" in "/etc/sshd_config" setzt.
Mit dem Befehl "last" sieht man ein kleines Protokoll welche SSH-Benutzer sich wann eingeloggt haben und ob diese noch mit dem SSH-Server verbunden sind.
Ein Tipp der FU Berlin für die SH-Shell, SCP und SFTP ist das Anlegen des Verzeichnises "/cygdrive".
Damit kann man dann etwas einfacher auf alle Laufwerke des SSH-Servers zugreifen, und muss sich nicht mehr an den virtuelle Verzeichnisnamen erinnern und diesen immer wieder eingeben.
Um einen SSH-Server bei einer Neu-Installation genauso wiederherzustellen, muss man folgende Dateien aus "/etc" sichern: "ssh_host_dsa_key*", "ssh_host_key*", "ssh_host_rsa_key*", "ssh_config" und "sshd_config".
Die Dateien "group" und "passwd" sollte man auch sichern, müssen aber bei einer Neu-Installation von Windows neu generiert werden, da sich die internen Schlüsseln ändern.
Sie dienen dann aber immer noch als Vorlage.
Zusätzlich sollte man auch für alle Benutzer die Dateien aus "/home/.ssh" sichern, damit die Benutzer sich auch direkt wieder anmelden können.
Wie man Tunnel definiert werde ich anhand eines fiktiven Dienstes auf Port 4300 erklären:
Regel: Für ausgehende Anfragen benötigt meinen einen L-Tunnel und für ankommende Anfragen einen R-Tunnel, dabei handelt es sich immer um die Richtung aus Sicht des SSH-Client.
Zur Fernwartung von anderen Rechnern über das Internet oder das LAN ist VNC (z.B. TightVNC) sehr beliebt, deshalb werde ich dazu die Tunnel definieren und Tricks zur Nutzung von VNC geben.
Ein Standard-VNC-Server wartet normalerweise auf eingehende Anfragen auf Port 5900.
Wenn man also vom SSH-Client auf den VNC-Server eines SSH-Servers zugreifen will, dann benötigt man den Tunnel "L5900:localhost:5900".
Läuft der VNC-Server dagegen auf dem SSH-Client und möchte das der SSH-Server darauf zugreifen kann, dann benötigt man den Tunnel "R5900:localhost:5900".
In der Standard-Einstellung des VNC-Servers sind Verbindungen mit dem selben Rechner des VNC-Servers nicht erlaubt, denn es macht normalerweise keinen Sinn den Rechner mit sich selbst "fernzuwarten".
Durch die SSH-Tunnel sieht dies natürlich ganz anders aus, und man muss deshalb beim VNC-Server unter "Preferences → Advanced..." Loopback-Verbindungen erlauben.
Will man auf den SSH-Server über VNC zugreifen können, auch wenn kein oder noch kein Benutzer angemeldet ist, dann muss der VNC-Server als Dienst installiert und die Default Settings konfiguriert sein.
Der SSH-Dienst und der VNC-Dienst müssen auf dem Starttyp "automatisch" stehen, damit SSH- und VNC-Server ohne eine Benutzeraktion laufen.
Der Server von TightVNC bietet aber auch die Möglichkeit, sich vom VNC-Server mit einem VNC-Viewer zu verbinden, also anders als üblich wo sich der Dienst-Client mit dem Dienst-Server verbindet.
Dies geschieht mit der VNC-Server-Funktion "Add New Client" (Standard-Port 5500) und der VNC-Viewer muss im "Listen Mode" gestartet sein (Parameter /listen).
Läuft der VNC-Server auf dem SSH-Client ist dies eine ausgehende Verbindung und man benötigt den Tunnel "L5500:localhost:5500".
Läuft der VNC-Server hingegen auf dem SSH-Server ist dies eine eingehende Verbindung auf dem SSH-Client für den VNC-Viewer und man benötigt den Tunnel "R5500:localhost:5500".
| Top | Start | Kontakt |