Man öffnet eine ssh-Verbindung, gibt seinen Benutzernamen ein, dann das Passwort und ist schließlich angemeldet. Aus Sicherheitsgründen hat das Passwort 18 Stellen oder mehr, oft genug kommt es vor, dass man sich vertippt, im schlimmsten Fall so oft hintereinander, dass die eigene IP-Adresse vom Server gesperrt wird. Zugegeben, das ist ein übertriebenes Horror-Szenario, aber ausschließen, dass es schon passiert ist, möchte ich nicht.

Warum also nicht ganz ohne Passwort anmelden?

Die Möglichkeit besteht durchaus, ist noch dazu sicherer als die Anmeldung per Passwort und natürlich gemütlicher. Die Rede ist von der Authentifizierung mit einem Schlüsselpaar (z.B. RSA). Dieses Schlüsselpaar muss für jeden Client einmal generiert werden. Der öffentliche Schlüssel wird dann auf dem Server abgelegt, damit er weiß, dass der Client sich anmelden darf. Nun ist der öffentliche Schlüssel des Clients aber, naja, öffentlich, also wird der Anmeldevorgang signiert. Dies geschieht mit dem privaten Schlüssel des Clients, der natürlich nur dem Client bekannt ist. Wie genau die Überprüfung funktioniert, weiß ich nicht, eine simple Möglichkeit wäre aber folgende (evtl. ist es auch die tatsächlich genutzte):

Der Server sendet eine zufällig generierte Zahl an den Client,  die auch nur einmal verwendet wird (nennt sich NONCE). Der Client verschlüsselt diese Zahl mit seinem privaten Schlüssel und schickt das Ergebnis wieder an den Server. Dieser versucht, die empfangene Nachricht mit dem öffentlichen Schlüssel des Clients zu entschlüsseln. Gelingt ihm dies, so ist es (nahezu) unmöglich, dass jemand anderes als der richtige Client gerade versucht, sich mit dem öffentlichen Schlüssel anzumelden.

Das Verfahren wird allgemein als sicher angesehen und wenn man sich die am häufigsten benutzten Passwörter ansieht, so ist dieses Verfahren im Gegensatz dazu die Definition von Sicherheit.

Zur Einrichtung begibt man sich zunächst an den Client. Hier wird mittels

ssh-keygen -t rsa

ein Schlüsselpaar generiert. Es ist vermutlich empfehlenswert, eine Passphrase für den Schlüssel zu vergeben, allerdings entfällt dann der Vorteil, dass man sich ohne Passwort anmelden kann. Vergibt man keine, so muss man sicherstellen, dass niemals der private Schlüssel öffentlich bekannt wird.

Es werden zwei Dateien erzeugt, eine mit dem privaten Schlüssel und eine mit dem öffentlichen. Letztere hat die Endung .pub (für public).  Der Inhalt dieser Datei muss auf dem Server an die Datei /home/[user]/.ssh/authorized_keys angefügt werden.

Dieses Vorgehen muss für jeden Client einmal wiederholt werden. Die Clients müssen, wie bereits erwähnt, entsprechend geschützt sein, damit der private Schlüssel nicht bekannt wird.

Unter Windows ist die Erzeugung des Schlüsselpaares etwas umständlicher. Will man diese Art der Authentifizierung z.B. mit PuTTY verwenden, so benötigt man zunächst das Programm PuTTYgen. Hier kann man als Typ SSH2-RSA mit 2048 Bits wählen. Klickt man auf Generate, so muss die Maus erst einige Zeit bewegt werden, damit der Schlüssel möglichst zufällig ist.

Anschließend muss der Inhalt des Textfeldes an die Datei /home/[user]/.ssh/authorized_keys angefügt werden. Dies ist der öffentliche Schlüssel. Den privaten Schlüssel speichert man (save private key), wo man ihn wieder findet.

In Putty muss diese Datei unter SSH->Auth als Private key file ausgewählt werden. Anschließend sollte die Verbindung ohne Passwort funktionieren.

Nach dieser Anleitung könnte man auf die Idee kommen, auch die Anmeldung an einem ssh-Server, der z.B. über cygwin unter Windows läuft, durch RSA zu ermöglichen. Vorab: Nein.

Warum das nicht so einfach möglich ist, wird schnell klar, wenn man verstanden hat, wie diese Anmeldung unter Linux überhaupt funktionieren kann. Wir melden uns an einem Rechner mit einem Benutzernamen aber ohne dessen Passwort an. Auch in den Dateien, die wir dafür angelegt oder geändert haben, ist das Passwort nirgends gespeichert.  Alles andere wäre auch irrsinnig.

Unter Linux ist das möglich, weil root eine Shell für einen beliebigen Benutzer öffnen kann – ohne Passwort. Nun läuft der ssh-Server unter dem Benutzer root, also hat der Server dieses Recht. Wir versichern dem Server durch unsere Authentifizierung, dass wir ein bestimmter Benutzer sind und er öffnet für uns die entsprechende Shell. Unter Windows ist es selbst dem Administrator nicht möglich, sich einfach als ein anderer Benutzer auszugeben. Eine Anmeldung ohne Passwort ist ohne weitere Eingriffe also nicht möglich. Natürlich darf der Administrator das Passwort eines Benutzers zurücksetzen und kennt dann das neue Passwort – aber das wollen wir wohl kaum als Anmeldeprozedur implementieren.

Falls doch jemand voreilig etwas in die authorized_keys eines Windows-Servers eingetragen hat, so ist die Anmeldung von dem eingetragenen Client aus nicht mehr möglich. Also entweder einen anderen Client benutzen oder lokal anmelden und den Eintrag aus der Datei wieder löschen.

Grundsätzliches

Ein Rechner, der an das Internet angeschlossen ist, insbesondere dann, wenn Ports im Router weitergeleitet werden, sollte kein Benutzerkonto ohne sicheres Passwort besitzen. Unter einem sicheren Passwort darf jetzt jeder verstehen, was er möchte. Kleiner Tipp: Der eigene Vorname ist ebenso unsicher wie ein 17-stellige Passwort, welches man sich nicht merken kann und unter die Tastatur schreibt. Ansosten gehe ich bei dieser Anleitung davon aus, dass man mit Windows einigermaßen umgehen kann. Getestet wurde alles unter Windows XP und Windows 7. Bei XP muss es sich um die Professional-Version handeln, bei Windows 7 könnte es auch mit anderen Versionen funktionieren, was ich aber nicht sicher weiß. Außerdem wäre ein zweiter Rechner von Vorteil, damit man alles jederzeit testen kann. Im Idealfall hat man bei dem zweiten Rechner die Wahl, ob er im selben lokalen Netz ist wie der Hauptrechner oder in einem ganz anderen.

Remotedesktopeinstellung

Zunächst wird der Rechner so konfiguriert, dass es möglich ist, von einem anderen Rechner im selben Netzwerk eine Remotedesktopverbindung aufzubauen. Mit einem Rechtsklick auf den Arbeitsplatz (Computer)  und dann auf Eigenschaften öffnen sich die Systemeigenschaften. Dort findet man die relevanten Einstellungen unter Remote (Remoteeinstellungen).

links: Windwos 7, rechts: Windows XP

Zum einen erlaubt man dort grundsätzlich, dass jemand eine Remotedesktopverbindung zu diesem Rechner aufbaut, zum anderen wählt man die dafür zulässigen Benutzer aus. Dabei sollte es sich nicht um ein Administratorkonto handeln und das Konto muss auf jeden Fall durch ein Kennwort geschützt sein. Die Windows-Firewall, so sie denn aktiviert ist, sollte automatisch so konfiguriert werden, dass Remotedesktop-Verbindungen akzeptiert werden. Falls eine andere Firewall installiert ist (z.B. ZoneAlarm oder Norton Internet Security) (beide dürfen mich gerne bezüglich einer Vergütung für die Werbung kontaktieren), so muss diese noch konfiguriert werden. Für den Moment reicht es, wenn Port 3389 freigeschaltet wird. Jetzt sollten die Einstellungen einmal getestet werden. Also führt man an einem zweiten Rechner, der sich im selben lokalen Netzwerk befindet das Programm mstcs aus (Start->Ausführen: mstsc). Dort gibt man den Computernamen oder die IP-Adresse des Rechners ein, auf dem die Einstellungen vorgenommen wurden. Beides kann man in Erfahrung bringen, indem man – natürlich wieder auf dem Rechner, den es betrifft – in der Eingabeaufforderung (Start->Ausführen: cmd) den Befehl “ipconfig /all” eingibt. Ganz oben steht hinter Hostname der Computername und darunter steht hinter IPv4-Adresse die IP-Adresse. Mit einem Klick auf Verbinden sollte man zur Anmeldemaske des Rechners gelangen, auf dem die Remotedesktopeinstellungen vorgenommen wurden.

ssh-Server installieren

Wenn bis hierhin alles geklappt hat, sollte sich der Rechner auf jeden Fall hinter einem Router befinden, so dass er aus dem Internet noch nicht erreicht werden kann. Jetzt könnte man im Router Port-Forwarding aktivieren und den Rechner so auch aus dem Internet zugänglich machen, allerdings rate ich davon ab. Zum einen ist die Remotedesktopverbindung nicht die sicherste und zum anderen möchte man nicht jedem Menschen seine Windows-Anmeldemaske im Internet anbieten. Deshalb wird als nächstes ein ssh-Server installiert, der es später erlauben wird, die Remotedesktopverbindung über ssh zu tunneln. Ein weiterer Vorteil des Tunnels ist, dass man sich den dafür verwendeten Port selbst aussuchen kann. So ist es z.B. in Firmennetzwerken oft üblich, fast alle Ports zu sperren, bis auf einige wenige, die das Surfen im Internet noch erlauben.

Der Port für RDP (Remotedesktop-Protocol) ist wie erwähnt 3389. ssh läuft über Port 22. Ein kostenloser ssh-Server für Windwos kann mit cygwin installiert werden. Dabei solltem an die Anweisungen während der Installation Schritt für Schritt durchlesen und befolgen. Irgendwann kommt man zu einer Auswahl der Pakete. Dort sollten folgende Pakete auf jeden Fall ausgewählt werden: Admin -> cygrunsrv Base -> alle Pakete Editors -> nano, vim Net -> autossh, openssh, openssl, Openssl097 Zur kurzen Erklärung: cygrunsrv ist der Dienst, der mit Windows gestartet wird, so dass cygwin immer in Hintergrund läuft. nano und vim sind Texteditoren, man benötigt nur einen von beiden, wenn man sich nicht sonderlich gut mit ihnen auskennt, ist vermutlich nano empfehlenswerter. autossh, openssh, openssl und Openssl097 sind die Pakete, die für die eigentliche ssh-Verbindung erforderlich sind (wobei ich mir den ssl-Paketen nicht sicher bin).

Nach erfolgreicher Installation startet man cygwin mit der Datei cygwin.bat (im Installationsverzeichnis von cygwin). Unter Windows 7 muss die Datei per Rechtsklick als Administrator ausgeführt werden. Jetzt kann die automatische ssh-Konfiguration mit dem Befehl “ssh-host-config” gestartet werden. Die Fragen, die während der Konfiguration beantwortet werden müssen, haben sich in den letzten Jahren geändert. Eines gilt nach wie vor: Frage durchlesen, verstehen und nach bestem Wissen und Gewissen beantworten. Für gewöhnlich antwortet man also mit der Default-Antwort, also dem, was voreingestellt ist. Nach der Konfiguration wird der ssh-Server mit dem Befehl “net start sshd” gestartet. Anschließend müssen etwaige Firewalls so eingestellt werden, dass Verbindungen auf Port 22 akzeptiert werden.

PuTTY konfigurieren

Zum Testen wird auf einem zweiten Rechner PuTTY ausgeführt.

Konfiguration von PuTTY

Bei Host Name gibt man wieder die IP-Adresse des fernzusteuernden Rechners ein. Klickt man auf Open, so kann man sich mit Benutzername und Passwort anmelden. Wenn die Anmeldung erfolgreich ist, kann PuTTY geschlossen und neu geöffnet werden. Die folgenden Einstellungen müssen auf jedem Rechner vorgenommen werden, von dem aus man sich zu seinem Rechner zu Hause verbinden möchte. Was bei Host Name tatsächlich eingegeben werden muss, darauf komme ich später zurück. Wichter ist zunächst der Tunnel. Im Menü unter SSH->Tunnels füllt man die Felder wie abgebildet aus:

ssh-Tunnel mit PuTTY

Der Source port gibt an, auf welchem Port der ssh-Server einen Socket aufmachen soll, auf dem er auf Verbindungen wartet. Eingehende Verbindungen auf diesem Port werden über die ssh-Verbindung zu dem Rechner, auf dem der Server läuft geleitet und dort an “Destination” geschickt. In diesem Fall also an den Server selbst (localhost) und zwar an Port 3389, also den Port, über den die Remotedesktopverbindung aufgebaut wird. Wichtig ist hier ein Klick auf Add, damit der Tunnel auf wirklich eingerichtet wird. Damit diese Einstellungen nicht verloren gehen, sollte man sie als Default speichern, also im Menü auf Session klicken, den Eintrag Default Settings markieren und auf Save klicken.

Remotedesktopverbindung über den Tunnel aufbauen

Hat man PuTTY konfiguriert und sich darüber mit dem Rechner verbunden, so kann man wieder die Datei mstsc ausführen, und als Ziel diesmal “localhost” eingeben.  Falls hier eine Fehlermeldung erscheint, kann es in manchen Fällen helfen, unter Putty->ssh->Tunnels als Source port nicht 3389 zu benutzen, sondern z.B. 3400. Die Destination wird auf keinen Fall geändert. Dann gibt man statt “localhost” einfach “localhost:3400″ ein.

Verbindung weltweit

Aus dem lokalen Netz sollte man nun die Verbindung zu seinem Rechner herstellen können. Über das Internet funktioniert dies noch nicht. Dafür gibt es zwei Gründe: Zum einen sollte sich der Rechner hinter einem Router befinden, auf welchem Port-Forwarding noch nicht eingerichtet ist, zum anderen ist die öffentliche IP-Adresse des Routers vermutlich unbekannt und ändert sich zu allem Überfluss auch noch alle 24 Stunden. Das erste Problem lässt sich schnell in der Routerkonfiguration beheben. Diese erreicht man meist über ein Web-Interface, indem man im Browser seiner Wahl die IP-Adresse des Routers einträgt. Also z.B. http://192.168.1.1 – falls dies denn die IP-Adresse des Routers ist. Eine schnelle Möglichkeit, die Adresse des Routers zu finden, ist folgender Befehl in der Eingabeaufforderung:

C:\>tracert jediblog.de

Routenverfolgung zu jediblog.de [188.40.132.68] über maximal 30 Abschnitte:

1    <1 ms    <1 ms    <1 ms  router [192.168.2.1]
2     5 ms     5 ms     5 ms

Der erste Abschnitt hat als Ziel für gewöhnlich den Router. Das Wort “router” steht dort im Normalfall allerdings nicht. In der Konfiguration sollte es einen Punkt “Port-Mapping” oder “Port-Forwarding” geben, evtl. auch unter dem Namen NAT (Network Address Translation). Dort muss eine neue Regel erstellt werden, die besagt, dass TCP-Verbindungen über Port 22 an den Rechner mit dem ssh-Server (vermutlich muss seine IP-Adresse eingegeben werden) und zwar an den gleichen Port geleitet werden. In manchen Netzwerken ist Port 22 gesperrt. In diesem Fall kann man als öffentlichen Port einen anderen Port wählen, der offen ist. Meistens ist z.B. Port 443 offen, da er für gesicherte http-Verbindungen benutzt wird (https). Es ist zu beachten, dass dieses Vorgehen in einem Firmennetzwerk zunächst mit dem Arbeitgeber (vermutlich der IT-Abteilung des Arbeitgebers) abzusprechen ist, da man ansonsten unter Umständen gegen Unternehmensvorschriften verstößt.

Die eingerichtete Regel besagt also, dass alles, was über den eingestellten Port am Router ankommt, an Port 22 des ssh-Servers geleitet wird. Es bleibt noch das Problem der unbekannten öffentlichen IP-Adresse. Ausgehend davon, dass der Router sich per DSL ins Internet einwählt und keine Standleitung gebucht wurde, so wird die Verbindung bei den meisten Providern einmal am Tag getrennt. Bei der Wiedereinwahl erhält man meistens eine unterschiedliche IP-Adresse. Hier ist nicht die Adresse gemeint, die mit 192 anfängt. Die richtige IP-Adresse sieht man z.b. hier oder hier. Das hilft nur nicht weiter, denn die Seite muss von dem Rechner aus aufgerufen werden, der erreicht werden soll. Die Lösung des Problems heißt DynDNS. DNS ist der Dienst, der Domain-Namen (z.B. google.de) in IP-Adressen übersetzt. DynDNS bietet die Möglichkeit, dies dynamisch zu gestalten (die IP-Adresse von Google bleibt dagegen mehr oder weniger fest).

Verschiedene Dienstleister bieten diesen Dienst zum Teil kostenlos an.  Einer dieser Dienstleister ist dyndns.com. Dort meldet man sich an, sucht sich einen Domain-Namen aus und ist fast fertig. Doch woher weiß dyndns.com, welche IP-Adresse zur gewählten Domain passt, wo sich diese doch täglich ändert? Im einfachen Fall bietet der Router in der Konfiguration auch den Punkt Dynamic DNS an. Dort wählt man üblicherweise den Dienstleister (dyndns.com) aus und gibt Domain und Passwort ein. Den Rest übernimmt dann der Router. Bei jeder Änderung der IP-Adresse übermittelt er die neue IP-Adresse an dyndns.com. Ältere Router bieten diese Möglichkeit nicht an. In diesem Fall kann man einen Update-Client auf seinem Rechner installieren (z.B. DynDNS Updater). Dieser übernimmt dann die Aufgabe der Aktualisierung an Stelle des Routers. Das Programm muss natürlich ständig ausgeführt werden, sich also am besten im Autostart befinden. Der Computer muss so oder so an sein, sonst gestaltet sich die Verbindung schwierig.