Sie sind hier: Zentrale | Servereinrichtung | SSH-Einrichtung  Harry Boeck - Heimserver

SSH-Einrichtung (OpenSSH + PuTTY) für GUI-Fernsteuerung

(Nachtrag 2007-06-02: Diese Dokumentation ist inzwischen etwas veraltet. Im wesentlichen geht es um ein Windows 98 - System. Inzwischen benutze ich nur noch die wesentlich einfacher zu handhabende Kombination aus FreeSSHd und PuTTY, wobei es den FreeSSHd aber nur für Windows NT - Derivate gibt.)

Anliegen
Installation
Schlüsselverwaltung
Benutzung

Anwendungserfahrungen

Manual

Anliegen

In diesem Fall geht es darum, Anwendungen, die nicht für gesicherte Übertragung übers Internet ausgelegt sind, eben dafür auszurüsten.
Primär ging es um die GUI-Fernsteuerung mittels VNC für meinen Heimserver unter Windows 98 und für Rechner, die ich zu betreuen habe, unter verschiedenen Betriebssystemen, darunter Windows 2000 und Windows XP.
Sekundär geht es darum, je nach Bedarf das eine oder andere Werkzeug in einer VNC-Sitzung übers Netz betreiben zu können.

Das hier zusammengestellte Paket ist auf meine typischen Bedürfnisse ausgerichtet: Meinen Rechner oder den von einem Kunden zeitweilig über einen halbwegs sicheren Kanal von außen zugänglich zu machen, um insbesondere effektiv vor Ort oder über Internet Wartungen machen zu können. Dabei müssen Server und Client möglichst klein, kompatibel und schnell sein. Die von mir zu benutzenden (bzw. zu betreuenden) Rechner liegen in einer Größenordnung ab 200 MHz / 32 MByte / Windows 98 an aufwärts. Hier im ehemaligen DDR-Gebiet gibt es eine Menge Leute, denen nicht genug Geld zur Verfügung gestellt wird, um sich alle drei Jahre einen neuen PC leisten zu können. Gerade auf älteren Rechnern mit nicht mehr als 128 MByte läßt sich nur Windows 98 halbwegs sinnvoll zum Laufen bringen (na ja - und Linux in einer der mittlerweile üblichen abgespeckten Versionen, aber DAS lässt sich keiner meiner Bekannten ohne Pistole an der Brust installieren). Ältere Rechner als etwa 1997 gibt es in meinem Bekanntenkreis mittlerweile nicht mehr. Reines DOS und Windows 3.x brauchen nicht unterstützt werden.
Ich brauche also ein Paket, das von einem DAU auf einem x-beliebigen Windows-PC von Windows98 an aufwärts zum Laufen zu bringen ist, nötigenfalls mit ein paar Hinweisen über Telefon und einem KLEINEN Download übers Internet. Danach will ich das Windows-GUI steuern. Alternativ will ich die Möglichkeit haben, bei einem Kunden vor Ort einen winzigen Ordner mit ein paar zwingend notwendigen Werkzeugen anzulegen, die allesamt keinerlei Spuren im System des Kunden hinterlassen (oder nur vollständig und fest definierte, die mit einer Batchdatei restlos zu beseitigen sind) und mir dabei eine Möglichkeit bieten, auf meinen PC zu Hause zugreifen zu können.

Nicht in diese Aufgabenstellung einbezogen sind HTTP- und FTP-Dienste, weil es für diese z.B. mittels Apache und Filezilla bzw. den aktuellen Browsern vollwertige SSL-Anwendungen gibt. Ebenfalls nicht zur Aufgabenstellung gehört eine Konsole zum Eintippen von Kommandos. Das kann absolut gleichwertig über VNC direkt auf dem fernen Rechner ausgelöst werden, mit dem Unterschied, dass eine Konsole für VNC nur ne weitere GUI-Ecke ist, während VNC oder GUI für eine Konsole Chinesisch rückwärts darstellt.

Mittel zum Zweck ist primär eine allgemeine Anwendung, die nichts weiter macht, als einen gesicherten Daten-Kanal zwischen zwei Internet-Endpunkten aus Rechneradresse und Portnummer bereitzustellen (und dazu die notwendigen organisatorischen Mittel bereitstellt wie Authentifizierung und Sitzungsschlüsselaustausch). Sekundär geht es dann darum, die ungesicherten Anwendungen zur Benutzung solcher Kanäle zu überreden.

Die genannten Fähigkeiten bringen momentan zwei Pakete für Windows 98 mit: OpenSSH und STunnel. Der Rest, der mir begegnet ist, läuft entweder nur auf Windows NT/XP oder nur unter Unix und fällt damit flach.

Installation

Das OpenSSH-Paket wird nur für cygwin entwickelt. Um es erstmalig in Betrieb nehmen zu können, bleibt nichts weiter übrig, als über eine cygwin-Installation zu gehen (meine Erfahrung mit der Erstinstallation...). Nachdem es einmal zur Funktion gebracht wurde, kann man cygwin fast komplett wegschmeißen... Das cygwin stellt eine Art Unix-Umgebung bereit, die aber für das hier zur Debatte stehende Ziel, OpenSSH funktionsfähig zu machen, irrelevant ist. Glücklicherweise ist das OpenSSH-Paket mit einem minimalistischen Auszug aus dem gewaltigen cygwin-Massiv zur Funktion zu bringen. Diesen Auszug kann man nochmal fast dritteln, wenn man auf die Bash verzichtet und die Datei "/etc/passwd" entsprechend ändert. Wir brauchen außerdem nur den Server, da es für den Client eine viel hübschere (kleinere und GUI-orientierte) Alternative gibt.

Für das andere Ende der Leitung wird ein SSH-Client benötigt. "SSH" aus dem OpenSSH-Paket käme zwar in erster Linie in Frage, benötigt aber nochmals einen doppelt so großen Satz von DLLs (ich habe es nicht geschafft, das Ding ohne eine funktionsfähige und hier vollkommen unnütze "Bash" zum Laufen zu bringen).
Eine viel bessere Alternative ist hier PuTTY. Dieser Client ist voll kompatibel, beinhaltet sogar ein Terminal für Kommandozeilenliebhaber und wiegt nur einen Bruchteil des SSH-Clients. Er paßt zusammen mit einem VNC-Viewer, dem Anwender-Schlüssel und einer angepaßten Konfigurationsdatei als vollwertiges und lauffertiges Fernzugriffspaket (nur noch eigene Schlüssel beizulegen) auf eine halbe(!) Diskette! SO mag ich das!

Von den vielen möglichen Varianten der Organisation eines SSH-Tunnels benötige ich nur eine einzige, deren Benutzungsmodalitäten auf meine Anwendungs-Anforderungen passen und deren Sicherheit nach dem, was ich aktuell an Meinungen aus dem Internet beziehen und mir selbst bilden kann, hinreichend ist: Ich will Public-Key-Authentifizierung mit 2048 bit Schlüsseln und nach Möglichkeit Blowfish-Verschlüsselung, keine extra Shell und für mein Single-User-System keinen Extra-User-Schnickschnack. Und nach Auskunft der Sitzungsprotokolle will ich auch für zumindest mein Freeware-VNC eine Datenkomprimierung im Tunnel. Ich will aufgrund von Einschränkungen am Router den SSH-Tunnel über einen Port unmittelbar neben einem schon vorhandenen freigeschalteten Bereich laufen lassen.

Hier gibt es fertig zusammengestellte und konfigurierte Minimal-Pakete. Es sind lediglich die Pfade zur Unterbringung im Dateisystem in den Batch-Dateien, Links und Registrierdateien anzupassen und gegebenenfalls die persönlichen Vorlieben in der Konfigurationsdatei "server.cfg" beim SSH-Server einzustellen.

Paket-Inhalt und Größe [byte] Anpassung
OpenSSH-Server 4.3.2.3 mit cygwin-DLLs 1.5.19-cr-0x5ef
1.164.790
Installation:
  • irgendwo im Dateisystem ablegen!
    außerdem das PuTTY-Paket mit Schlüsselmanager installieren!
    (die Client-Schlüsselerzeugung ruft letzteren auf)
  • Dateipfade anpassen auf diesen Ablagepfad in
    • /bin/*.bat
    • /bin/*.lnk
    • /bin/*.pif
    • /etc/cygwin-mini.reg
  • eventuell Vorlieben in /etc/server.cfg anpassen!
  • *.lnk und *.pif ins Startmenü ziehen!
  • eventuell /doc/index.url ins Startmenü ziehen!
  • /etc/cygwin-mini.reg registrieren!

Benutzung:
  • Server-Schlüssel erzeugen: Server-Schlüsselerzeugung.bat (ohne Passwort)
    -> es entstehen: /etc/server.key zum liegenlassen
    und /etc/server-key.txt zum mitnehmen auf Datenträger
    oder zum offenen verschicken
  • Client-Schlüssel erzeugen: Client-Schlüsselerzeugung.bat (mit Passwort)
    im gestarteten PuTTY-Schlüsselmanager den importierten Schlüssel
    in der privaten Form (Save private Key) speichern!
    -> es entstehen:
    • /clients/<Name>.ppk - zum Mitnehmen auf privatem Datenträger
    • /clients/<Name>.key.pub - zum Zusammenstellen der registrierten Benutzer
    • /etc/clients.key - die Zusammenstellung der registrierten Benutzer

PuTTY-Client und PuTTY-Schlüsselmanager 0.58
243.072
Installation:
  • irgendwo im Dateisystem ablegen!
  • Dateipfade anpassen auf diesen Ablagepfad in "putty*.reg"!
  • "putty*.reg" "registrieren"!
  • eventuell die beiden exen ins Startmenü ziehen!
  • eventuell weitere "Sessions" in PuTTY anlegen
    (das ist basierend auf den Vorlagen einfacher übers GUI)!
    Es empfielt sich, den entstehenden Registry-Inhalt zu speichern,
    wenn man das portable Paket nutzen möchte.

Benutzung:
  • PuTTY starten!
  • "Session" "laden" und "open"!
  • Passwort eingeben ins erscheinende Terminal-Fenster für den Schlüssel!
  • Anwendung starten (z.B. VNC-Viewer für die VNC-Session)!

RealVNC 4.1.1
352.088
Installation:
  • irgendwo im Dateisystem ablegen!
  • Dateipfade anpassen auf diesen Ablagepfad in *.lnk!
  • Die *.lnk ins Startmenü ziehen und eventuell hübscher benennen!

Benutzung: siehe VNC-Anleitung!

Fernzugriffspaket: PuTTY 0.58 plus RealVNC-Viewer 4.1.1
325.661
Installation:
  • irgendwo auf einem portablen Datenträger ablegen!
  • eventuell eine erweiterte Version der "putty*.reg" vom
    installierten und angepassten PuTTY-Paket übernehmen!
  • Dateipfade anpassen auf diesen Ablagepfad in "putty*.reg"!

Benutzung:
  • portablen Datenträger im Zielrechner einsetzen!
  • eine Version der "putty*.reg" "registrieren"!
  • weiter wie beim normalen PuTTY-Paket...


Eine Bemerkung noch:
Einige Kryptographie-Pakete für Windows, darunter auch OpenSSH, laden aus einem mir schleierhaften Grunde die DLL, die unter dem Registry-Key "HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\Defaults\Provider\Microsoft Base Cryptographic Provider v1.0" eingetragen ist. Das ist eigentlich ein Bestandteil des Internet-Explorers...
Als ich mich nach OpenSource-Paketen mit eigenen Krypto-Bibliotheken umsah, hoffte ich eigentlich, von eben jenen Microsoft-Produkten unabhängig zu sein! Das ist aber offenbar nicht der Fall. Oder ist da nur etwas aus einer Urversion im Quelltext hängengeblieben? Oder hat das mit RSA-Lizenzen zu tun?
Jedenfalls habe ich im Internet bisher nichts schlüssiges als Erklärung gefunden und bin den Quelltext des OpenSSH nicht extra deswegen angegangen.
Ohne Microsoft-Updates aus dem Bereich nach 2000 ist hier die alte Export-Version "rsabase.dll" eingetragen, mit irgendeinem Update wird dann die "rsaenh.dll" nachgerüstet. Man sollte nur dran denken...

Ein Hinweis für die Inbetriebnahme: Zu Anfang - falls etwas nicht klappt oder um mit Sicherheit die korrekte Funktion nachzuweisen - ist es eventuell hilfreich, den Log-Level sowohl beim Server als auch beim PuTTY auf Debug-Niveau anzuheben und eventuell den kompletten Datenstrom mitzuschreiben. Die Meldungen sind recht ausführlich und haben bei mir geradlinig zur Funktion verholfen.

Schlüsselverwaltung

SSH verwendet das Public-Key-Verfahren für die Authentifizierung und um einen Sitzungsschlüssel für symmetrische Verschlüsselung auszutauschen.

Die Schlüsselverwaltung für die Schlüssel ist beim SSH erfreulich einfach und exakt an die Anforderungen des Anwendungsfalles angepaßt, bei dem es darum geht, dass ein Administrator in erster Linie sich selbst und eventuell dem einen oder anderen guten Bekannten Möglichkeiten zum Zugriff auf einen einzelnen Rechner übers Internet gewährt. Dabei ist nämlich die Schlüsselverteilung nebensächlich. Ein Zertifikat brauche ich mir selbst auf der Diskette in meiner Brusttasche nicht ausstellen und in den wenigen anderen Fällen wird der public Key per PGP mit Unterschrift direkt an mich geschickt, womit das Authentifizierungsprotokoll für die Public Keys bei einem extra dafür vorgesehenen etablierten Werkzeug liegt.

Man erzeugt einen Schlüssel (eigentlich ein Paar, aber das interessiert erst mal nicht) für den Server und legt ihn unter einem selbstgewählten Namen an einer unixmäßig vordefinierten Stelle (Verzeichnis /etc/ relativ zum Installationspfad des SSH-Servers) ab. Die Übergabe des öffentlichen Serverschlüssels an den Benutzer bzw. das Client-Programm PuTTY ist nun eben mit PuTTY nicht ganz so nahtlos möglich wie mit SSH (das wurde in PuTTY einfach nicht als präventive Handlung vorgesehen), aber wegen der untergeordneten Wichtigkeit der Zertifizierung noch lange nicht problematisch: Auf die Benutzerdiskette wird einfach nur der Fingerprint des Serverschlüssels kopiert und bei der ersten Anmeldung verifiziert, während PuTTY sich den Schlüssel übers Netz holt und in seinem eigenen Format ablegt (und das auch ganz nach Belieben darf).

Auf der Gegenseite erzeugt der Benutzer einen Schlüssel, dessen öffentlicher Teil beim SSH-Server hinterlegt wird (entweder direkt auf dem Server liegengelassen oder per Mail an den Admin geschickt oder was auch immer) und dessen privater Teil vom Schlüsselverwalter des PuTTY-Pakets importiert (DAS ist möglich) und beim PuTTY deponiert wird.

Damit man die paar Zusammenhänge nicht im Kopf haben muss und das ganze leicht benutzbar wird, habe ich das mal schnell in Batchdateien gepackt... (Mit einem Makroplayer wie Autohotkey könnte man das komplett automatisieren (bis auf das Kennwort), aber der steht wieder nicht überall zur Verfügung.)
Nach der Server-Schlüsselerzeugung steht der Serverschlüssel in "/etc/server.key" und sein Fingerprint in "/etc/server-key.txt". Der aus dem "server.key" obligatorisch herausgezogene Public Key wird gleich wieder gelöscht, weil er nicht gebraucht wird.
Nach einer Client-Schlüsselerzeugung ist der öffentliche Client-Schlüssel in den Schlüsselbund der für Verbindung mit dem Server erlaubten Clients ("/etc/clients.key") aufgenommen und der private über das GUI von PuTTY und den Schalter "Save private Key" irgendwo nach Geschmack des Erzeugers abgelegt (standardmäßig bietet PuTTY immer das Windows-User-Verzeichnis an, sinnvoller ist das entweder auf einem transportablen Datenträger oder im Verzeichnis von PuTTY oder einem zentralen - und eventuell PGP-gesicherten - Schlüsselverzeichnis oder wo immer der persönliche Geschmack liegt).

Wenn man mit dem portablen Fernwartungssatz an einen fremden Rechner zieht, um zwischendurch auf den eigenen Rechner zugreifen zu können, empfielt es sich, jedesmal einen neuen Client-Schlüssel zu generieren. Es ist ohne weiteres möglich, dass auf dem Rechner des besten Bekannten ein Keylogger oder sonstiger Trojaner läuft - falls jener Bekannte nicht gerade ein PC- und Sicherheits-Freak ist. Schließlich geht man zu einem Hausbesuch, um einem Nicht-Freak bei einem schwereren Problem zu helfen. Falls man statt dessen zur Arbeit geht, kenne ich es als üblich, dass dort Spionagesoftware einschließlich Keyloggern als selbstverständlich angesehen werden. Der Fernzugriff auf den eigenen Rechner ist also als eine Art Wegwerf-Produkt zu sehen: Sobald man sich verbunden hat, ist alles OK, solange man auf seinem Rechner arbeitet und sieht, was passiert. Sobald man sich wieder trennt, muß dafür gesorgt sein, dass der Schlüssel ungültig wird. Das sollte man VOR Trennung der Verbindung erledigen (aus der "/etc/clients.key" löschen)!
Es versteht sich von selbst, dass man hier vorsichtig zu Werke gehen sollte!

Benutzung

Letztlich müssen noch die beiden VNC-Stellen umgelenkt und der SSH-Tunnel gestartet werden...

  1. Der VNC-Server wird so eingerichtet, dass er Verbindungen am lokalen Rechner (localhost alias 127.0.0.1) - also vom SSH-Server - akzeptiert.
  2. Der SSH-Server wird so eingerichtet, dass er an einer von außen zugänglichen Adresse+Port auf Internet-Verkehr seines SSH-Clients lauscht.
  3. Der SSH-Client wird so eingerichtet, dass er zur Einrichtung des gesicherten Kanals die Verbindung zu seinem Server sucht und auf Anfragen eines VNC-Clients am lokalen Rechner lauscht und diese an den SSH-Server weiterleitet, um sie bei diesem lokal auf dem Port des VNC-Servers wieder auszuspucken.
  4. Der VNC-Client wird beauftragt, sich seinen Server am lokalen Rechner zu suchen.

Die Programme werden zweckmäßigerweise in dieser Reihenfolge in Betrieb genommen (der VNC-Server zumindest vor dem VNC-Client; er könnte auch über PuTTY gestartet werden, ich selbst bevorzuge es aber, die später von unterwegs benötigten Programme vorm Losgehen zu starten und zu testen, um keine bösen Überraschungen zu erleben).

Sofern die beiden Endstellen auf verschiedenen Rechnern laufen, braucht am VNC nichts weiter beachtet werden. Falls sie zum Test auf ein und demselben Rechner mit nur einer Internet-Adresse laufen (zum Test neu eingerichteter Schlüssel vor Beginn einer Dienstreise empfielt sich das hochgradig), muss einer der beiden VNC-Partner auf was anderes als den Standard-Port 5900 konfiguriert werden. Ich habe den VNC-Client standardmäßig so eingestellt, dass er sich mit dem Port 1024 seines localhosts zu verbinden versucht, wo der SSH-Client bei mir standardmäßig wartet.

Diese vier Einstellungen sind in den angepaßten Konfigurationsdateien in den Installationspaketen schon enthalten und können trivial für x-beliebige andere Anwendungen modifiziert werden.

Wenn man den Problemfall hat, dass man eine Fernwartung bei einem Kunden machen muss, bei der es um die Behandlung geheimzuhaltender Daten geht (Hilfe bei Verträgen, Konten...), ohne dass der Kunde technisch versiert ist, läßt sich dieses stufenweise erreichen:
  1. einfacher VNC-Zugriff auf den Kundenrechner
  2. Download und Installation des SSH-Servers
  3. Erzeugung eines neuen Server-Schlüssels beim Kunden
  4. Erzeugung eines neuen Client-Schlüssels bei sich selbst
  5. Kopie des öffentlichen Schlüssels via VNC-Zwischenablage zum Kunden und Eintrag des Schlüssels dort in die Datei /etc/clients.key
  6. Anschmeißen des VNC-Servers beim Kunden
  7. Trennung des eigenen VNC-Zugangs
  8. Anschmeißen des eigenen PuTTY und Herstellen der Verbindung
  9. Wiederherstellen des eigenen VNC-Zugriffs über den lokalen PuTTY-Port
(Eventuell lässt sich die Trennung des VNC-Zugangs auch noch bis nach Anschmeißen des eigenen PuTTY hinauszögern.)

Anwendungserfahrungen

2006-11-18: Nach einem knappen Jahr hier einige Erfahrungen mit der Anwendung des Pakets:

OpenSSH hat sich bisher als ohne von für diesen Anwendungsfall relevanten Sicherheitslücken befallen gezeigt. Damit brauchte dieser Teil des Systems bisher keinen Updates oder Anpassungen unterzogen werden.

Nachdem in den Anfangsmonaten am laufenden Band erfolglos Einbruchsversuche auf meinen SSH-Port unternommen worden waren, hat sich dies mittlerweile beruhigt. Irgendwie muß mein Rechner wohl irgendwo auf einer schwarzen Liste der Einbrecher-Mafia stehen. Auch gut. Würde sich für die sowieso nicht lohnen, weil hier ein Windows98 läuft, das denen keinerlei übliche Infrastruktur für übliche Verwendung von Zombierechnern bieten würde (nix Outlook, nix IE, nix MS-Adreßbuch).

Das RealVNC 4.1.1 erwies sich in der Zwischenzeit als unfähig, seinen Login korrekt auszuführen. Es gab im Juli einen erfolgreichen Angriff auf einen Windows-2000-Rechner, auf dem ich es nicht in akzeptabler Zeit geschafft hatte, das SSH-Paket zur Funktion zu bringen, weshalb ich VNC ohne Sicherung zur Fernwartung jenes Rechners betreiben mußte. Dummerweise hatte ich eine entsprechende Sicherheitsmeldung beim Heise-Verlag, die schon im Mai rausgekommen war, übersehen.
Leider hatte ich bisher auch keinen Rechner im eigenen Haushalt, an dem ich das SSH-Zeug unter einem Windows-NT ausprobieren konnte. Das hat sich allerdings mittlerweile geändert und ist gerade in Bearbeitung...

Anfangs hatte ich für jede Verwendung des Fernzugriffs von außen einen extra Schlüssel generiert (mit ein paar wenigen Klicks und dem Ausdenken eines Passwortes), was zusammen mit der Einstellung des VNC auf ungeteilte Sitzung und dem Löschen des betreffenden Schlüssels aus der Authentifizierung in der jeweiligen Sitzung sowie der strikten beidseitigen Zertifikats-Authentifizierung bewirkte, daß ich selbst von einem unsicheren Rechner mit Keylogger und Man-in-the-Middle eine sichere Verbindung aufbauen konnte (wobei man allerdings immer im Auge behalten muß, daß sämtliche Darstellungen und Aktionen auf einem dermaßen kompromittierten Rechner natürlich protokolliert werden können, also man nur Dinge tun darf, die man auch tun könnte, wenn man mit dem Rechner im Freien auf einem Präsentationsplatz sitzen würde).

Nach Einarbeitung in Windows-XP-Systemspezifika und mir genügender Verifizierung der Sicherheit meines Arbeitsplatz-PCs (das sonstige Rechnernetz halte ich nach wie vor für massiv verviert und vertrojanert) bin ich dazu übergegangen, auf eben diesem Zweit-PC ein weitgehend konstantes Zertifikat zu hinterlassen, so daß ich von der dauernden Passwortmerkerei entlastet bin (nachdem es in zu vielen Fällen vorgekommen war, daß ich das Passwort vergaß - das ist nun mal leider die Rückwirkung wirklich sicherer Passwörter, die man außerdem nicht notiert).
Extra Zertifikate werden jetzt nur noch für Wartungen bei Bekannten (oft eben wegen Vervierung) verwendet.

Leistungsmäßig ist der SSH-Kanal bei der Fernbedienug eines GUI kein Engpaß (sondern VNC) - unabhängig von der Rechenleistung der beteiligten Rechner.