Der Betrieb von NAT bringt es mit sich, dass man einerseits mit einem nicht-öffentlichen Addressraum arbeitet und andererseits Verbindungen von außen by default nicht durchgelassen werden. Um den Betrieb normaler Client-Server-Protokolle wie HTTP überhaupt sicherzustellen, werden Ports dynamisch in Abhängigkeit des Traffics nach innen freigeschaltet, damit der Betrieb überhaupt gewährleistet werden kann. Da es zu NAT keinen wirklichen Standard gibt ist aber das Verhalten der einzelnen Implementationen sehr unterschiedlich.

Um nun für bestimmte Anwendungen wie Telefonie und/oder Dateiübertragung im Instant Messaging Protokollen (iChat) oder P2P-Protokolle zu realisieren wurde über Strategien nachgedacht, wie man eine definierte Erreichbarbeit von außen herstellen kann. Da der Bedarf zuerst und vor allem für nicht-verbindungsorientierte Protokolle via UDP deutlich wurde, gab es mit STUN (RFC3489) einen ersten Versuch, der Problematik Herr zu werden. Auch iChat verwendet STUN, doch ist trotzdem die Kooperation des NAT-Routers erforderlich. STUN war daher nicht sonderlich erfolgreich, doch immerhin wurde anlässlich der Protokolldefinition überhaupt eine Klassifikation von NAT-Protokollen vorgenommen, die da heißen:

• Full Cone
• Restricted Cone
• Port Restricted Cone
• Symmetric

Ich will hier nicht genau die Funktionalitätsunterschiede beschreiben (das ist in der Wikipedia bereits ausführlich erfolgt). Nur so viel: STUN funktioniert am besten mit “Full Cone” und mit “Symmetric” überhaupt nicht. Mit den anderen beiden Varianten fällt es bestenfalls unter “your mileage will vary”, da aber das NAT im Linux-Network-Stack aus generellen Sicherheitserwägungen “Symmetric” ist und Linux in vielen Routern zum Einsatz kam, war der Erfolg mit STUN gering. Wer schon mal Probleme mit iChat und Audio-Verbindungen gehabt hat, wird jetzt ahnen, woran das liegt.

STUN selbst ist also kein großer Schritt, es mussten anderen Krücken her. Das Pflegen einer Port Forwarding Tabelle hilft in manchen Fällen weiter, ist aber lästig, wenn man DHCP verwenden will und das gleiche Protokoll auf mehr als einem Rechner anbieten möchte. Sowohl Microsoft als auch Apple sahen das Problem und entwickelten unabhängig voneinander jeweils eine Lösung. Die von Microsoft wiegt schwer und kommt unter dem Wischiwaschi-Namen Universal Plug and Play (UPnP) daher, Apple setzt auf NAT-PMP. Während UPnP ein umfangreiches Framework mit zahlreichen Protokollen, Datenformaten und einer komplexen Dokumentation ist (allein die Beschreibung des NAT-Traversal Unter-Protokolls IGD umfasst 13 PDF-Dokumente mit insgesmt 360 Seiten unverständlichem Fooblas) wird Apples NAT-PMP in einem knappen RFC in zwanzig Seiten ausreichend beschrieben.

Das NAT Port Mapping Protocol (NAT-PMP)

Die Grundfunktionen von NAT-PMP sind schnell aufgezählt:

1. Erfragen der externen IP-Adresse
2. Öffnen eines Ports auf dem Router für Verbindungen von außen

Das alles geht über Broadcast-UDP-Pakete im lokalen Netzwerk, es funktioniert also nur, wenn man mit dem Router in der selben Collision Domain ist (was aber in den typischen Heimnetzen eben der Fall ist). Mir ist schon die erste Funktion ovn NAT-PMP sehr symphatisch, da man sonst auf Tools wie BwanaDik zurückgreifen muss, die zunächst Verbindungen zu externen Hosts aufbauen müssen. Mit NAT-PMP erhält man seine externe IP-Adresse ohne Fehlermöglichkeiten direkt vom eigenen Router mitgeteilt, was auch schneller geht.

Aber die eigentliche Killerfunktion ist natürlich die zweite. Das Pflegen einer Forwarding Table entfällt, die Programme können sich jetzt selbst um alles kümmern und bekommen dabei akkurat mitgeteilt, ob der gewünschte Port bereitgestellt werden konnte und wenn ja unter welcher Adress/Port-Kombination. Diese Information kann dann innerhalb von Netzwerkprotokollen verwendet werden ohne dass der Router die Pakete selbst umschreiben muss.

NAT-PMP auf AirPort Basisstationen einschalten

Wie nicht anders zu erwarten ist NAT-PMP in allen AirPort-Basisstationen allen AirPort Extreme und AirPort Express Basisstationen implementiert. Es muss lediglich einmal über das AirPort Utlity in den Internet-Settings eingeschaltet werden.

Das bedeutet, dass sich jede NAT-PMP-aware Applikation selbst ihre Ports freischalten kann und jederzeit on-demand aus dem Internet Verbindungen annehmen kann (spätestens hier sollte jedem klar sein, dass NAT definitiv keine Firewall ist!).

Update: Wer noch nicht das “AirPort Utility” hat (das lag nur den neuen Extreme-Basestations bei und wird von Apple aus mir absolut nicht verständlichen Gründen allen zum Download bereitgestellt, der muss das “AirPort Admin Utility” verwenden. Wie es sich dort einschalten lässt, beschreibt ein Apple Tech Support Artikel. Man muss also zuerst auf die “Base Station Options” gehen und dann sieht das dann so aus:

BitTorrent mit NAT-PMP

Das einfachste Beispiel für ein nettes Tool, das von NAT-PMP Gebrauch macht ist der großartige BitTorrent-Client Transmission. Hier kann man in den Voreinstellungen selbst einen Port wählen, der dann an den Router weitergereicht wird. Transmission teilt einem auch gleich mit, ob die Zuordnung auch erfolgreich war.

So einfach, so effizient. Weitere Beispiele für Support von NAT-PMP (und teilweise auch UPnP) mit BitTorrent sind BitRocket und XTorrent.

Aber auch außerhalb von BitTorrent gibt es Unterstützung für NAT Traversal: Nicecast von Rogue Amoeba kann seinen Streaming-Dienstleistung auch selbst beim Router registrieren.

NAT-PMP verwalten

Aber es wird noch besser: vor kurzem bin ich auf die großartige Software Lighthouse von codelaide software gestossen. Das User Interface könnte noch etwas eleganter sein, aber die Funktionalität überzeugt: Lighthouse übernimmt die Registrierung von Ports am Router für andere Programme. Es unterstützt dabei sowohl NAT-PMP als auch UPnP (bzw. IGD), so dass man auch mit Linksys und D-Link-Routern Freude hat, die nur UPnP unterstützen.

Besonders pfiffig ist, dass Lighthouse die für eine Applikation benötigten Ports beim Start des Programms auf Wunsch auch automatisch einschaltet und beim Beenden des Programms wieder ausschaltet. Man kann sich beliebige eigene Profile erstellen und jederzeit aktivieren und deaktivieren. Lighthouse unterstützt selbstverständlich auch Growl, so dass man seine Aktivitäten auch in Echtzeit auf dem Bildschirm mitverfolgen kann, wenn man möchte.

Es gibt bereits eine Reihe fertiger Profile, z.B. für Adium, Apple Remote Desktop sowie HTTP und FTP Server. Weitere Profile stehen auch online zum Download bereit. So lernen z.B. dann auch die anderen BitTorrent Programme mit dem Router umzugehen ohne wirklich davon was mit zu bekommen.

Lighthouse kostet 13 Dollar, ist aber sein Geld durchaus Wert. Wer dynamisch HTTP- oder FTP-Server im Heimnetz betreiben möchte wird sein Geld gut angelegt wissen. Großartiges Tool, um die Nachteile von NAT erträglicher zu machen.

Funktionsweise

NAT funktioniert nach einem einfachen Prinzip: im eigenen Netzwerk verwendet man einen von drei reservierten privaten IP-Adressbereichen (10/8, 172.16/12, and 192.168/16). Ein Router (oder Gateway, wie man möchte) in diesem Netzwerk übernimmt nun die Funktion der Weiterleitung der Pakete, die für Hosts im Internet gedacht sind. Üblicherweise, aber nicht notwendigerweise, ist dieser Router auch für die Adressvergabe via DHCP und eben auch für die Netzwerk-Adressumsetzung (NAT) zuständig.

Ein Rechner im privaten Netzwerk schickt nun also seine Internet-Pakete über diesen Router. Die Absendeadresse dieser Pakete enthält dementsprechend eine Adresse aus den oben erwähnten Netzen. Diese sind aber im Internet nicht routingfähig, da sie eben nicht für Internet-Hosts vergeben werden dürfen. Der NAT-Router ersetzt nun also diese Absendeadressen durch die vom ISP (meist via PPP oder PPPoE) zugeteilte öffentliche Adresse und merkt sich zudem in einer Tabelle, dass hier demnächst mit einer Antwort zu rechnen ist. Dazu vermerkt der NAT-Router zusätzlich noch den Port, von dem aus das Paket geschickt wurde (das identifiziert die sendende Applikation) und wartet ab. Das ausgehende Paket hat nun einen gänzlich neuen Port verpasst bekommen, an dem man den Tabelleneintrag identifizieren kan

Kurze Zeit später kommt die Antwort und anhand des Zielports findet der NAT-Router den Eintrag in der Tabelle. Dort steht die eigentliche Zieladresse aus dem privaten Netzwerk nebst dem ursprünglich als Absender verwendeten Port. Diese beiden Werte werden nun wieder ersetzt und das Paket wird auf dem internen Netzwerk entsprechend versendet. Der Rechner erhält wie gewünscht seine Daten aus dem Internet ohne von dem doppelten Datentausch etwas mitzubekommen. Deswegen muss die Software für NAT nicht angepasst werden, was für den Durchbruch von NAT ganz wichtig war.

Überläufer

So weit, so gut. Doch gibt es hier einige kleine Probleme, die häufig nicht bedacht werden und bei frühen NAT-Implementierungen ein Problem waren. Das betrifft vor allem die oben bereits angesprochene Umsetztabelle.

Ist die Internetaktivität im privaten Netz sehr groß, senden also viele unterschiedliche Hosts und Programme Daten, dann kann das dazu führen, dass die Tabelle des Routers zu groß wird und neue Verbindungen nicht mehr gespeichert werden können. Da Router nicht selten recht kleine Embedded-Systeme mit wenig RAM sind, wurde dies anfangs nicht immer bedacht. Können keine Einträge mehr vorgenommen werden, werden auch die Antwortpakete nicht mehr zugeordnet und die Anfragen erhalten keine Rückmeldungen mehr: Programme warten auf ihre Daten, erhalten aber keine. Die Verbindungen frieren ein, obwohl der Internetzugang eigentlich wunderbar funktioniert.

Dabei können die Symptome schwanken, je nach dem, wie der Router mit solchen Überläufen umgeht. Neuen Verbindungen wird unter Umständen Vorrang gegeben, da alte Verbindungen ggf. nicht mehr aufgenommen werden und der Eintrag als nicht mehr notwendig betrachtet wird. Bei sehr hohem Datenaufkommen kann aber auch der älteste Eintrag noch recht neu sein und so kommt keine einzige Verbindung mehr zustande, da alle neueren Verbindungen die eben noch gestarteten überlagern und selber wieder von ihren Nachfolgern überschrieben werden. In diesem Fall geht überhaupt nichts mehr, obwohl der Router brav alle Pakete nach außen schickt und auch alle Antworten zurückkommen. Ein totales Desaster.

Die Strategie, alte Einträge bei Nichtaktivität herauszuwerfen ist aber auch sonst eine schlechte Idee, denn es gibt durchaus viele Verbindungen, die lange brachliegen, aber mit guten Grund. Ein gutes Beispiel sind SSH-Sessions. Hier loggt man sich auf einem Rechner ein und startet auf der Kommandozeile irgendein Programm, dass ein paar Stunden benötigt (ein Übersetzungsvorgang, eine Berechnung , ein Batchprozess oder was auch immer). Erst nach Ablauf meldet sich das Programm wieder. Wenn der NAT-Router wegen Nichtaktivität den Eintrag aus der Tabelle geworfen hat, brechen die Verbindungen ab. Das Ergebnis geht verloren. Im Falle von SSH kann man sich wehren, indem man seine SSH-Verbindung entsprechend mit ServerAlive konfiguriert. Aber es gibt auch andere Beispiele, wo zu kurze Timeouts stören (Chats, Datenbankverbindungen und ähnliches).

Inkontinenzen

Ein Nebeneffekt von NAT ist, dass Verbindungen von außen in der Regel blockiert werden. Das schafft einen bestimmten Sicherheitspuffer, doch sollte man NAT nicht als Sicherheitstechnologie begreifen. Schon das Beispiel mit der Tabelle oben zeigt, dass diverse Klimmzüge nötig sind, um NAT wirklich durchlässig genug zu machen und diese Durchlässigkeit ist by design bidirektional. Das bietet auch viel Raum für Sicherheitslöcher und daher sollte man bei besonders schützenswerten Infrastrukturen schon auch Gedanken um eine zusätzliche Firewall machen.

NAT orientiert sich sehr am klassischen Client/Server-Ansatz und geht vor allem davon aus, dass das private Netzwerk vor allem Clients betreibt. Das mag häufig der Fall sein, doch gibt es zunehmend den Bedarf, auch von zu Hause Serverdienste anzubieten (Fernzugriff via SSH oder Apple Remote Desktop, File Server, Web Server etc.) und komplexe Protokolle für Internettelefonie, Chat-Dateitransfer oder BitTorrent benötigen möglichst dynamische, bidirektionale Kommunikation. NAT ist nicht für P2P gemacht und daher sind hier weitere Maßnahmen nötig. In einem Folgeartikel werde ich auch auf NAT Traversal eingehen, dass diese Probleme addressiert.

Richtig schlimm wird es mit NAT, wenn Protokolle Informationen über Absendeadresse und Absenderport direkt im Protkoll unterbringen. Dies ist der Fall bei FTP, SIP und vielen anderen Protokollen, die eigentlich für den Betrieb im NAT-freien Internet gemacht sind. Vor allem Telefonie-Protokolle sind hier betroffen. NAT-Implementierungen müssen aktiv in den Protokollstrom eingreifen und tauschen Informationen in der Payload der Datenpakete, um die Protokolle überhaupt zum Laufen zu bringen. Dies mag auf den ersten Blick elegant klingen, greift aber nicht bei verschlüsselter Kommunikation bzw. verhindert diese und ist in bestimmten Situation technisch sogar nicht möglich bzw. nicht zuverlässig.

Manche Probleme entstehen auch erst, wenn mehrere NATs hintereinander geschaltet werden. Das passiert schnell, z.b. wenn man in einem mit NAT arbeitenden WLAN via Internet Sharing einem anderen Rechner via Ethernet oder Firewire Internetzugang spendet. Dann arbeitet ein zweites NAT auf dem eigenen Rechner und setzt die Adressen bereits einmal um, damit sie danach von dem WLAN-NAT noch ein weiteres Mal umgesetzt zu werden. Das funktioniert zwar, aber schafft neue Probleme für Traversal-Protokolle, denn selten verhalten sich zwei NAT-Implementierungen identisch.

Port Mapping

Nahezu alle Router (einschliesslich der AirPort-Modelle) bieten heute die Möglichkeit, ein sogenanntes “Port Mapping” einzustellen. Das erlaubt, Dienste auf einem Rechner hinter dem NAT anzubieten und die Anfragen aus dem Internet durch eine fest eingestellte Zuordnung auf diesen Rechner weiterzuleiten. Das funktioniert so weit ganz gut und straigtforward. Allerdings unterliegt man hier einigen Einschränkungen, da der Rechner dann seine IP-Adresse nicht mehr ändern darf. Das Netzwerk-Kontrollfeld bietet da mit der Einstellung “DHCP mit manueller Adresse” die nötige Voraussetzung, so dass man alle anderen Werte auch noch dynamisch beziehen kann. Bei den AirPort-Modellen ist das Port Mapping leicht über das AirPort Utility einzustellen.

Mehr Informationen zu NAT und wie man es so umbiegen kann, dass man damit glücklich wird, im nächsten Teil der Serie.

Wer sich wie im letzten Teil beschrieben, SSH mit einem Public-Private-Key Schlüsselpaar und mit SSHKeychain einen SSH-Agenten eingerichtet hat, der die Passphrase des eigenen Schlüssels im Mac OS X Schlüsselbund abspeichert, hat jetzt leichtes Spiel, Dienste mit Applikationen zu nutzen, die SSH auf eine ssh-agent-kompatible Art und Weise nutzen. Das gilt leider nicht für alle verfügbaren SSH-Clients.

Für den Mac gibt es mittlerweile einige Dateitransfer-Programme, die auch SFTP unterstützen (auch FTP-TLS, auf das ich hier nicht eingehen möchte). Nur zwei von ihnen möchte ich hier featuren: Transmit und Fugu. Während Transmit ein kommerzielles, aber extrem umfangreiches, schnelles und höchst benutzerfreundliches Tool für alle populären und unpopulären Protokolle ist, ist Fugu freie Software und auf SSH-Protokolle spezialisiert.

Beide Programme verbindet, dass sie nahtlos mit ssh-agent zusammenarbeiten. Das bedeutet, dass man Verbindungen via SFTP herstellen kann ohne die Passphrase eingeben zu müssen, da sie via SSHKeychain direkt aus dem Mac OS X Schlüsselbund geliefert werden.

Andere bekannte Dateitransfer-Programme wie z.B. Cyberduck oder das ewig gestrige Fetch sind entweder nicht ssh-agent kompatibel (Cyberduck) oder können mit SFTP nix anfangen (Fetch).

Update: Ich wollte es eigentlich in einem weiteren Beitrag nochmal auseinandernehmen, aber Max hat mich in den Kommentaren zu recht hier schon hingewiesen (zumal er auch schon vor einiger Zeit hier darüber schrieb): auch MacFusion darf hier natürlich in der Liste nicht fehlen.

MacFusion arbeitet im Gegensatz zu den oben erwähnten Programmen auf Basis des Dateisystems. Die SFTP-Server werden also wie externe Festplatten oder AFP-Server im Finder sichtbar und der Dateitransfer kann einfach mittels des Finders vorgenommen werden. Auch hier klappt die Zusammenarbeit mit SSHKeychain ganz wunderbar.

Diese Passphrase ist zwar keine Pflicht (man kann den Schlüssel auch ungeschützt im Dateisystem ablegen), aber so sensitive Daten sollte man nicht unverschlüsselt herumliegen lassen. Auf Linux-Servern sind unverschlüsselte private Schlüssel beim Betrieb von HTTPS-Webservern durchaus gängige Praxis, hat aber das gleiche Risiko. Mac OS X wiederum bietet hier aber Abhilfe: die Mac OS X Keychain (aka Schlüsselbund).

Mac OS X Server macht davon selbst Gebrauch. Legt man HTTPS-Dienste an, besteht das Administrationsprogramm darauf, die Schlüssel mit einer Passphrase zu versehen. Diese wird dann im System-Schlüsselbund abgelegt. Das ist zwar im Prinzip auch nur ein schwacher Schutz (schliesslich muss der Server auch darauf automatisiert zugreifen), aber es ist immerhin eine weitere Hürde aufgebaut (der Schlüssel muss über einen autorisierten Weg aus einer verschlüsselten Datei geholt werden). Aber mich interessiert hier mehr die Client-Seite (und muss auch zugeben, nicht viele weitere Details zu der Art, wie hier Mac OS X Server genau vorgeht, zu wissen).

Für die tägliche Anwendung auf der Kommandozeile bietet SSH bereits eine Lösung: der ssh-agent ist ein Hintergrundprozess, dem man einmal mit der Passphrase für den Schlüssel versieht und der dann in der Folge auf Anfrage einem SSH-Client den unverschlüsselten privaten Schlüssel bereitsteht. Man kann konfigurieren, wie lange der Agent den Schlüssel vorhält etc. pp. Für Leute, die ohnehin nur in der Kommandozeile zu Hause sind, eine passable Lösung.

Da diese Methode dem Mac OS X Schlüsselbund so ähnlich ist, liegt eine Integration auf der Hand und die Lösung gibt es bereits (in verschiedener Form). Das Programm, das ich ans Herz legen möchte und dass zu meiner Mac-Grundausstattung gehört, ist SSHKeychain, das jüngst in einer überarbeiteten Fassung und endlich auch als Intel-Binary erschienen ist.

SSHKeychain schlägt die Brücke zwischen dem ssh-agent und dem Mac OS X Schlüsselbund, in dem es im Environment (das, was man in der Kommandozeile durch Eingabe von “env” anzeigen lassen kann eine Kontaktadresse für den SSH-Client hinterlässt. Das sieht dann so aus:

SSH_AUTH_SOCK=/tmp/501/SSHKeychain.socket

Dadurch weiss die SSH, wie sie mit SSHKeychain kommunizieren soll. SSHKeychain fungiert nun als ssh-agent, legt aber die Passphrase in der privaten Keychain des Benutzers ab. Das Ergebnis ist, dass wann auch immer die Keychain geöffnet ist, die Eingabe der Passphrase entfällt. Das funktioniert für die SSH auf der Kommandozeile wie auch für SSH-kompatible Programme mit GUI gleichmassen.

Noch als ich diesen Beitrag schrieb wurden Sicherheitsprobleme in der Version 0.8.1 veröffentlicht. Seit heute gibt es die Version 0.8.2, die die geschilderten Probleme angeblich gelöst haben soll. Seit Version 0.8 gibt es SSHKeychain auch in einer Intel-Version.

Trotz aller Einfachkheit, die der Einsatz von SSHKeychain bringt, er macht ggf. die Sache auch unsicherer. Das muss jeder für sich abwägen. Es ist sicherlich generell zu empfehlen, seiner Keychain so einzustellen, dass sie beim Schlafen des Rechners und nach einem bestimmten Inaktivitäts-Timeout automatisch schließt. Das lässt sich im “Bearbeiten” Menü der Schlüsselbund-Applikation für jedes Schlüsselbund manuell einstellen.

Als nächstes werde ich ein paar Programme vorstellen, die prima mit SSHKeychain zusammenarbeiten.

Die Secure Shell ist seit Mac OS X ein fester Bestandteil des Macs und das ist auch gut so. Zwar ist die Kommandozeile nicht jedermanns Sache, aber ich wollte ja mal erläutern, wie man davon profitieren kann, vor allem wenn man eigene Server betreibt.

Die Kernidee von SSH ist, zwischen zwei Rechnern eine authentifizierte, verschlüsselte Verbindung herzustellen. Dazu wird eine Reihe von Massnahmen ergriffen, um möglichen Angreifern das Leben schwer zu machen.

Die einfachste Methode, eine SSH-Verbindung herzustellen, ist der Aufruf des Kommandozeilenprogramms ssh im Terminal:

$ ssh mylogin@myhost.mydomain

Damit das geht, muss natürlich ein Benutzerzugang unter dem Namen “mylogin” auf dem anderen Rechner vorhanden sein. Wird die Verbindung erstmalig hergestellt, präsentiert einem SSH zunächst einen “digitalen Fingerabdruck” der Gegenseite, an der man die Identität des Rechners sicherstellen kann. Wenn man den akzeptiert wird man nach dem Kennwort des Zugangs gefragt. Wird das richtige Kennwort eingegeben, ist man erfolgreich verbunden und alles ist gut.

Aber Kennwörter sind eigentlich out. Besonders auf Servern will man seine Sicherheit nicht darauf aufbauen, dass ein einzelner String nicht erraten werden kann. Außerdem lässt sich der Login schlecht automatisieren, da immer die manuelle Eingabe des Kennworts erforderlich ist. Für Backups und andere nützliche Dinge, die man mit SSH machen kann (dazu später mehr), ist das ein Hindernis. Daher hat sich beim Umgang mit SSH eine andere Methode der Authentifizierung durchgesetzt: die Public-Key-Authentication. Hier legt man nur einmal ein Schlüsselpaar an, bestehend aus einem öffentlichen und einem privaten Teil. Ersteren platziert man auf dem entfernten Rechner, letzteren behält man für sich. Soll nun eine SSH Verbindung aufgebaut werden, prüft das SSH-Subsystem, ob der private Schlüssel zum öffentlichen passt und gibt den Weg frei (wenn alles in Ordnung ist).

Soweit klingt das alles ganz fein, leider ist der Prozess zur Erzeugung der Schlüsselpaare und die Einrichtung des Servers ein wenig knifflig, da man sich hier den unter UNIX gängigen Konventionen beugen muss: Kommandos, Textdateien und verborgene Verzeichnisse müssen gemeistert werden. Ist aber alles nicht so schwierig. Wir machen das jetzt mal Schritt für Schritt.

Zunächst muss das Schlüsselpaar erzeugt werden. Dazu ruft man das Terminal auf und begibt sich auf die Kommandozeile und gibt ein:

$ ssh-keygen

Mit ssh-keygen wird ein interaktiver Erzeugungsprozess gestartet. Und interaktiv heißt, dass man mit dummen Fragen genervt wird. Hier ist die erste:

Enter file in which to save the key (/Users/theodor/.ssh/id_rsa):

Hier wird gefragt, in welcher Datei der private Schlüssel des Schlüsselpaares gespeichert werden soll. Ist dies der erste Schlüssel, den man erzeugt, kann und sollte man hier beruhigt Return drücken, denn der Name und Ort ist der, den man möchte. Wie man sieht, wird der Schlüssel im eigenen Home Directory im “.ssh” Verzeichnis abgelegt. Da es mit einem Punkt beginnt, ist es im Finder ohne weiteres zunächst nicht sichtbar (kann aber mit Apfel-G und der Eingabe “~/.ssh”) problemlos geöffnet werden. Wir werden mit dem Verzeichnis noch häufiger Bekanntschaft machen, da es alle Einstellungen und Schlüssel beherbergt, die für SSH wichtig sind.

Die Frage macht auch klar, dass der Default-Schlüsseltyp RSA ist. Das lässt sich alles auf der Kommandozeile noch feintunen, aber der Default reicht uns fürs erste aus.

Wie auch immer: die nächste Frage lauert schon auf uns:

Enter passphrase (empty for no passphrase):

Hier wird ein langes Kennwort (passphrase) zum Sichern des privaten Schlüssels erfragt. Da der private Schlüssel uns alle möglichen Dinge eröffnen soll ist es angeraten, ihn selbst noch einmal zu verschlüsseln, so dass es nicht einfach geraubt werden kann. Jetzt werdet ihr Euch natürlich fragen, wie man jetzt einen Vorteil mit der Automatisierung haben soll, wenn jetzt schon wieder ein Kennwort im Spiel ist und Ihr habt recht. Aber das werde ich im nächsten Teil erläutern. Jetzt denkt ihr Euch erstmal einen schönen Satz aus und gebt ihn hier ein. Dann noch ein zweites Mal zur Überrpüfung der Eingabe und dann wird das Schlüsselpaar auch endlich erzeugt: der private Schlüssel in der genannten Datei, der öffentliche in einer Datei gleichen Namens zuzüglich der Endung “.pub”.

Mit der Schlüsselerzeugung allein ist es nicht getan. Wir müssen nun noch den öffentlichen Schlüssel auf den anderen Rechner spielen, damit er dort bekannt ist. Schauen wir mal in die Datei hinein, was dort eigentlich gelandet ist:

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAxc33yRAuo2B0iaFb0
6PMKvL1hPGELuKPWMTtKx7TQgVnl97aKB1SkppFWYJOvDZYA3qCYl
7snUkSM715vGlhOYJDRSaoZpEj3l9DNZsygc4uicybkUW7lC2itbX
vP4s8ctr+Yl6xDHdcuc5uWdwqR/3okPxGY4ZVYRU6oezDK7mZ1Fvn
e58TUICSRAgUdyyjWDqZKZ/41B+V+ca8XKiks4nKMaIzypng+k07i
TnMxR5eZxVWWwUpniQ91q6+l6FLsA35MVc17Aclkj97balatNUUMg
1ZdunI1rTeVUUFt+YpJQAWGJ3LuSgDqi9A47Xd5NT5FirhfieYAJp
1Zdl/ew== theodor@macbook.local

Das ist der öffentliche Schlüssel in einer “lesbaren” Version, so dass man ihn auch einfach per Cut und Paste mit einem Texteditor von A nach B tragen kann. Anders als hier im Beispiel besteht der Schlüssel aus einer einzigen Textzeile ohne Umbrüche und sollte auch nicht nachträglich umbrochen werden. Das ist ein beliebter Anfängerfehler. Diese Textzeile muss nun auf Reisen gehen. Sie muss auf dem Zielrechner im Home Directory des Benutzers im “.ssh” Verzeichnis Bestandteil einer Datei namens authorized_keys werden. Gibt es noch keine kann man die “.pub”-Datei einfach kopieren und umbenennen. Soll allerdings mehr als ein Schlüssel gültig sein, muss jeder Schlüssel als eine Zeile in dieser Datei auftauchen.

Nun sind wir schon fast am Ziel. Es könnte zwar sein, dass ihr Euch schon jetzt erfolgreich anmelden könnt, das hängt allerdings von der Konfiguration des SSH-Servers auf dem Zielrechner ab. Diese ist ebenfalls in einer Textdatei abgelegt und zwar in /etc/sshd_config. Dort muss dafür gesorgt werden, dass die Option PubkeyAuthentication auf yes steht, damit der Login via Schlüsselpaar auch ausprobiert wird. Läuft alles kann man später die Option PasswordAuthentication auf no stellen, um zu verhindern, dass schwache Kennwörter irgendwelcher User die Sicherheit des Systems gefährden.

Das einmal zum Einstieg. Ich habe sicherlich einiges vergessen, zur Not fragt in den Kommentaren nach. Im nächsten Teil erläutere ich dann, wie man das gesamte Schlüsselmanagement unter Mac OS X integrieren kan.

Apple bietet zwar mit Remote Desktop ein hervorragendes Produkt zur Fernverwaltung an, allerdings ist der Preis mit 299 bzw. 499 EUR eher im sportlichen Bereich und daher für die meisten unerschwinglich, da man das Tool eher selten nutzt und den Gegenwert verständlicherweise selten erzielt. Eine freie oder zumindest kostenlose Basisversion für Einsteiger wäre mal ganz angebracht.

Die Arbeit mit der Kommandozeile ist nicht jedermanns Sache, aber sie bietet – das wird schon jeder mal gehört haben – bei erhöhter Komplexität auch eine grosse Nützlichkeit. Abgesehen von der Automatisierung bietet das Terminal vor allem bei der Systemadministration vielerlei Hilfestellung, besonders bei der Administration anderer Computer über das Netzwerk.

Einiges von dem Kauderwelsch oben lässt sich einfacher nutzen als gedacht. Zunächst ist es aber erforderlich, dass man im Kontrollfeld “Sharing” im Tab “Dienste” die Einstellung “Entfernte Anmeldung” eingeschaltet ist. Gestelzter lässt es sich kaum ausdrücken, aber immerhin ist ssh so leicht und schnell zuschaltbar: ist das Häkchen gesetzt bedeutet das, dass der sog. SSH-Hintergrundprozess auf Anfragen von außen wartet. Nun braucht man nur noch die passende Software, um auf diesen Dienst auch zuzugreifen.

Da ist natürlich zum einen das Programm “ssh” auf der Kommandozeile. Ist also der SSH-Dienst auf einem Rechner angeschaltet und ist der Rechner über das Netz zu erreichen (also nicht hinter einer Firewall oder einem NAT versteckt), kann man sich mit ssh host verbinden und mit dem Login-Kurznamen und Passwort anmelden. Soweit nicht besonders exicting und nicht für jeden nützlich.

Doch gibt es einige nützliche Dinge, die man mit SSH anstellen kann und vor allem kann es als Sicherheitsnetz für viele wichtige Transaktionen im Internet verwendet werden.

Ich möchte hier in den nächsten Tagen mit einer Reihe von Blog-Postings auf die zahlreichen Möglichkeiten eingehen, wie man auf dem Mac und auch auf dem Mobiltelefon mit SSH arbeiten kann und erklären, warum man es auch tun sollte.

Aber die Abhilfe ist näher als man denkt: drückt man gleichzeitig die Alt-Taste (auch als Option-, Weichen-, oder Gabeltaste bekannt), dann sortiert der Mac die Netze in der Reihenfolge ihrer Sendestärke, das stärkste vorne dran.

[via TidBits]