Nachdem ich im ersten Teil dieser Serie versucht habe, die Grundzüge und -probleme von NAT zu beschreiben, möchte ich im zweiten Teil auf Protokolle und Programme eingehen, die einem das Leben hinter einem NAT erleichtern können.
Als Mitte der 90er Jahre der Zugang zum Netz populärer wurde, erdachten ein paar Linux-Hacker eine pfiffige Lösung, um mehreren Computer mit nur einer IP-Adresse Zugang zum Internet zu geben: Network Address Translation wurde dann schnell zum Gold-Standard für Heim und Büro. Entsprechend unterstützen heutzutage alle Router NAT.
Eine der besten Anwendungen für SSH ist die SCP-Erweiterung und FTP-Alternative SFTP. Es gibt auf dem Mac mittlerweile zahlreiche exzellente Clients für SFTP. Ein paar davon möchte ich hier vorstellen.
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.
Wie ich im letzten Beitrag zum Thema aufgezeigt habe, kann man mit der SSH mit vertretbaren Aufwand ein System aufbauen, das unter Verwendung von Schlüsselpaaren die Authentifizierung für Verbindungen zwischen zwei Systemen sicherstellt. Das Ergebnis erscheint auf den ersten Blick unbefriedigend: anstatt des Kennworts muss man nun bei jedem Verbindungsaufbau die Passphrase des privaten Schlüssels eingeben.
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.
Au weia. Jetzt habe ich den Max schon viel zu lange alleine gelassen und melde mich nach erfolgreichem Laptop-Neuerwerb (schwarzes MacBook) aus meinem Blogurlaub zurück. Und wie versprochen wende ich mich dem Thema SSH auf dem Mac zu. Zeit wird’s.
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.
Unverzichtbares Werkzeug jedes Administrators ist die sogenannte Secure Shell (ssh). ssh stellt verschlüsselte und authentisierende (die Identität überprüfende) Verbindungen zu anderen Computersystemen her. ssh ist sehr flexibel einsetzbar und bietet neben dem normalen Einloggen auf dem anderen Rechner auch verschlüsselten Dateitransfer (via SCP, SFTP) und die Möglichkeit, eine beliebige andere Netzwerkverbindung durch einen Tunnel zu verbinden (sog. Port Forwarding).
Es gibt ja Orte, da tummelt sich durchaus mehr als ein Netz und es ist nicht so einfach, auf dem Mac schnell herauszufinden, welches WLAN-Netzwerk denn nun das stärkste ist. Klickt man in das WLAN-Symbol in der Menüleiste sieht man nur ein alphabetisch sortierte Liste. Das hilft nicht weiter.
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.
in iTunes abonnieren
Neuste Kommentare