ES STELLT SICH VOR...

Johannes Truschnigg jun.

Bild von Johannes Truschnigg, Februar 2015

Zur Suche ▼Zum Archiv ▼

Eintrag von 2009-03-03

pam_ssh - Single Sign On via SSH mit neuem Komfort


SSH - die Secure SHell - ist aus meinem Alltag fast nicht wegzudenken. Kaum eine Stunde am Computer vergeht, in der ich nicht zumindest ein Mal über ein Netzwerk bzw. das Internet mit einem anderen Host Verbindung aufnehme, um dort meine Kommandos abzusetzen. Die Einsatzzwecke sind vielfältig: Egal, ob ich auf eBay automatisiert in buchstäblich letzter Sekunde ein Gebot abgeben möchte, einen Teil meines Home Directories außer Haus sichern will, oder einen von mir betreuten Server mit frischen Updates versorge: OpenSSH spielt immer eine tragende Rolle. Durch die verschlüsselnde Natur von SSH ist es möglich, kritische Prozesse über eigentlich inhärent unsichere Netzwerkpfade hindurch zu erledigen: die starke Kryptographie des Protokolls sorgt dafür, dass ungewollte Lauscher mit tauben Ohren vor verschlossenen Türen bleiben müssen.

Werimmer oft mit SSH zu tun hat, hat üblicherweise auch eine oder gar mehrere SSH-Identities - eine (mit extrem hoher Wahrscheinlichkeit) weltweit einzigartige Kombination aus privatem und öffentlichem Schlüssel, die sich gegenseitig authentifizieren. Dieses Konzept ist auch von anderen, Computerfachleuten nicht weniger vertrauten Technologien bekannt: PGP/GnuPG und SSL/TLS zum Beispiel bauen im Herzen auf Public Key Cryptography auf. Diese macht es möglich, dass zwei Endpunkte die Identität des jeweiligen Gegenübers zweifelsfrei verifizieren können, ohne dass eine der beiden Parteien sensitive Informationen zum Gegenüber übertragen müsste.

Die private Komponente eines solchen Schlüsselpaares ist natürlich in höchstem Maße schützenswert. Da man in Punkto Sicherheit so wenig wie möglich dem oft launischen Zufall überlassen möchte, wird der Private Key deshalb lokal durch eine Passphrase symmetrisch verschlüsselt abgelegt. Auch bei der Wahl dieser Passphrase gelten die üblichen Kriterien für gute Passwörter - was bei oftmaliger Nutzung von SSH schnell lästig werden kann, da man bei jeder Verbindungsaufnahme zur Eingabe der Passphrase genötigt wird. Um diesem Mangel an Komfort beizukommen biete das OpenSSH-Projekt das Programm ssh-agent, das die privaten, authentizierenden Credentials an andere SSH-Clients, sei es nun der OpenSSH-Kommandozeilen-Client ssh, oder aber auch z. B. ein KIO-Slave zum Dateitransfer via sftp, über ein Socket bereitstellen kann. Dann genügt es, die Passphrase nur einmal - nämlich beim Laden der Identität in den ssh-agent - anzugeben, woraufhin der entsprechende Private Key für eine definierbare Zeit entsperrt wird.

Schon länger war es mir ein Dorn im Auge, dass ich zum Beginn meiner X11-Session (hier KDE 3.5.10) zwar automatisch einen ssh-agent starten konnte, es allerdings keinen mir bekannten Weg gab, auch gleich eine SSH-Identity in diesen zu laden. Immer war es nötig, vor der ersten SSH-Verbindung ssh-add (das Dienstprogramm zum Laden von SSH-Identities in den ssh-agent) auszuführen, um dann in weiterer Folge auf das Eintippen der Passphrase verzichten zu können. Eine kleine aber geniale Erweiterung des PAM-Stacks (Pluggable Authentification Modules - eine Bibliothek, die bei vielen UNICES und auch GNU/Linux die Authentifikation von Benutzern für Services und Logins über hat) macht dies möglich: pam_ssh.

Durch pam_ssh wird das Login-Procedere insofern abgeändert, als dass man gleich beim Login - also noch vor Beginn der Session, egal ob in X11 oder auf einem durch getty (oder was auch immer sonst) bereitgestellten VT - nach seiner SSH-Passphrase gefragt wird. Mehr noch: benutzt man als Login-Passwort und SSH-Passphrase den selben String, so kann PAM mithilfe von pam_ssh gleich beide Wünsche auf einmal erfüllen, und man hat für die Dauer der Session einen entsprechend vorbereiteten ssh-agent nach nur einmaliger Eingabe seines Passworts verfügbar.

Generell ist die genaue Konfiguration von Linux-PAM stark distributionsspezifisch, und deshalb nicht einfach auf einen allgemeingültigen, gemeinsamen Nenner zu bringen. In meinem speziellen Fall (Linux-PAM 1.0.3, pam_ssh 1.92, Gentoo ~amd64) hat es genügt, nach der Installation von pam_ssh die folgende Version der Datei /etc/pam.d/system-auth einzuspielen:

auth required pam_env.so
#pam_ssh mods begin
auth optional pam_ssh.so try_first_pass
#pam_ssh mods end
auth required pam_unix.so try_first_pass likeauth nullok

account required pam_unix.so

password required pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3
password required pam_unix.so try_first_pass use_authtok nullok sha512 shadow

#pam_ssh mods begin
session optional pam_ssh.so
#pam_ssh mods end
session required pam_limits.so
session required pam_env.so
session required pam_unix.so
session optional pam_permit.so
direkter Link ▲

© 2007-2016 Johannes Truschnigg | Design by Andreas Viklund (modified) | valid xhmtl & css

Created with free software