© Jan Paul Herr, Pixelio.de
Admins müssen sich oft auf einem entfernten Rechner anmelden. Ist ein einfaches Passwort die einzige Hürde beim Login, bleibt ein ungutes Gefühl. Doch unter Linux erlaubt eine ganze Palette von Verfahren mit unterschiedlichen Vor- und Nachteilen eine kryptographisch gesicherte Authentifizierung.
Die Situation kennt jeder: Man ist unterwegs und braucht aus irgendeinem Grund Zugriff auf den PC in der Firma oder Zuhause, auf dem eine wichtige Datei oder E-Mail liegt. Internetzugang gibt es heute fast überall und damit prinzipiell auch eine Zugriffsmöglichkeit. Damit die aber nicht jeder andere Internetnutzer ebenso benutzen kann, gilt es, einen Riegel vorzuschieben.
Der einfachste Schutz ist ein Passwort. Das sollte mindestens acht, besser zwölf Zeichen oder länger sein, neben Buchstaben auch Ziffern oder Sonderzeichen enthalten und nicht in einem Wörterbuch oder Nachschlagewerk vorkommen. Wer ein solches Passwort dann mehrmals jährlich wechselt, ist auf der sicheren Seite. Leider kommen in der Praxis aber oft Passwörter zum Einsatz, die sich eher daran orientieren, dass der Anwender sie sich leicht merken kann. Solche Passwörter halten besserer Cracker-Software allerdings nicht lange stand.
Glücklicherweise gibt es eine ganze Reihe Alternativen zum einfachen Passwort. Asymmetrische Verschlüsselungsverfahren, wie sie im Internet an vielen Stellen die Verbindungen chiffrieren (etwa bei HTTPS oder bei SSH), lassen sich auch verwenden, um einzelne User zuverlässig zu authentifizieren. Weil der Schlüssel hier viel länger ist als beim besten Passwort und weil er aus zufälligen Elementen besteht, bietet er deutlich mehr Schutz.
Bei der asymmetrischen Verschlüsselung gibt es immer zwei Schlüssel, einen privaten und einen öffentlichen. Was der eine verschlüsselt, kann der andere wieder entschlüsseln. Im klassischen Setup hat ein HTTPS- oder SSH-Server einen privaten Schlüssel und der Client kennt oder bekommt den zugehörigen öffentlichen Schlüssel. Damit können nun beide eine geschützte Verbindung aufbauen. Der Client kann außerdem den Server zweifelsfrei identifizieren, denn wenn der Server die mit seinem öffentlichen Schlüssel chiffrierten Informationen entschlüsseln konnte, muss er im Besitz des privaten Schlüssels sein. Da den nur der echte Server kennt, weiß der Client, dass er mit dem Original spricht.
Auch der umgekehrte Weg ist möglich: Wieder geht's um ein Schlüsselpaar, aber nun besitzt der Client den privaten Schlüssel. Bei X.509-Zertifikaten (wie sie bei HTTPS und OpenVPN zum Einsatz kommen) spricht man von einem Client-Zertifikat, bei SSH von einem Key-File, auch wenn dieser Begriff streng genommen nicht eindeutig ist. Wer dieses Verfahren zur Authentifizierung von Usern einsetzen will, braucht für jeden User ein eigenes Client-Zertifikat beziehungsweise Key-File. Auch dafür bringt Linux alle nötigen Tools bereits mit.
Unter Linux stehen mehrere Dienste zur Wahl, die alle eine verschlüsselte Verbindung herstellen und es erlauben, den User mit Hilfe eines privaten Schlüssels zu authentifizieren. Im Unterschied zum Passwort reicht dafür Wissen allein nicht mehr aus, sondern der User muss jetzt eben auch im Besitz des Schlüssels sein. Dieser Beitrag stellt die verbreitetsten drei dieser Dienste einander gegenüber. Da sie alle ein vergleichbares Sicherheitsniveau bieten, kann jeder Admin einfach das Tool wählen, das zu den eigenen Anforderungen am besten passt.
Einen SSH-Server bringen alle gängigen Distributionen mit, meist läuft er per Default. Standardmäßig erlaubt er zwar Authentifikation per Passwort, doch auch ein Schlüsselpaar für die Authentifizierung ist schnell erzeugt: Der Befehl »ssh-keygen -t rsa« erledigt das.
Bei »Enter file in which to save the key« übernimmt der Admin am besten den Standardwert. Als Nächstes fragt das Kommando eine Passphrase ab. Hier empfiehlt es sich, ein gutes Passwort zu wählen. Es dient dazu, den privaten Schlüssel (Key-File) zu schützen. Sollte dieser jemals in falsche Hände fallen, bietet diese Passphrase den letzten Schutz. Je länger ein Angreifer braucht, um sie zu knacken, desto länger hat der Angegriffene Zeit, den Verlust zu bemerken und den Schlüssel auszutauschen.
Ist der Schlüssel generiert, sollten im Unterverzeichnis ».ssh« des eigenen Homeverzeichnisses die Dateien »id_rsa« (privater Schlüssel) und »id_rsa.pub« (öffentlicher Schlüssel) liegen. Der öffentliche ist nun auf jenen Rechner zu verfrachten, auf den der Nutzer zugreifen will, und dort unter »~/.ssh/authorized_keys« zu speichern. Anschließend sorgt ein »chmod 600 authorized_keys« für den nötigen Schutz. Achtung: Bei zu laschen Berechtigungen - etwa wenn ein »w« für die Gruppe gesetzt ist oder wenn der Benutzer nicht selbst Eigentümer der Datei ist -, weigert sich der SSH-Daemon aus Sicherheitsgründen diesen Schlüssel zu verwenden!
Der private Schlüssel muss auf dem Rechner verfügbar sein, von dem aus der Nutzer zugreifen will. Auf einem USB-Stick ist er stets problemlos greifbar. Läuft der Client unter Linux, baut der Nutzer dann mit »ssh -i keyfile username@server« eine SSH-Verbindung auf. Das Kommando fragt die Passphrase des Schlüssels, nicht das Kennwort des Users ab, bevor sich eine Shell des Servers öffnet. Zum Kopieren von Dateien über die gesicherte Verbindung steht nun »scp« bereit.
Alle Rezensionen aus dem Linux-Magazin
Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...
