256bit.org Blog

Jetzt habe ich bereits beschrieben, wie ssh keys generiert werden, wie man diese ssh keys mit putty benutzen kann und wie man sich die die Entschlüsselung der SSH Schlüssel vereinfachen kann.

Jetzt beschreibe ich, wie mit Single-Sign on bereits beim Einloggen die SSH Schlüssel entschlüsselt werden können.

Zunächst installiert man das Paket libpam-ssh. Dieses Pam-Paket (Die Möglichkeiten von PAM würden den Rahmen dieses Artikels sprengen) ermöglicht es, bereits bei der Anmeldung am System die SSH-Schlüssel zu entschlüsseln und den ssh-agent zu starten. Dafür stellt es die beiden Module pam-ssh-auth (Authentifizierung anhand des ssh-keys) und pam-ssh-session (Start des SSH Agents sowie Laden der Schlüssel) zur Verfügung.

Nach der Installation muß man dann das System so konfigurieren, dass bei bestimmten Aktionen die beiden Module geladen werden. Möchte man z.B. beim Einloggen auf einer Konsole, dass die vorhandenen Schlüssel geladen werden, dann sollte man diese beiden Module in die Datei /etc/pam.d/login (Für den Loginzugriff bei Debian System verantwortlich) hinzufügen. Beim Start des grafischen Loginmanagers ist dann die Datei /etc/pam.d/gdm bzw, kdm, wdm oder xdm für den jeweiligen Loginmanager zuständig. Weitere Module könnten angepasst werden (z.B. ssh für den Login per ssh) In diesen Scripten steht im Prinzip in welcher Reihenfolge bestimmte Pam Module geladen werden sollen

Nun wird in vielen Howtos und Anleitungen empfohlen das Modul pam-ssh-auth vor dem Modul common-auth zu laden. Der Effekt der dadurch erzielt wird, ist, dass man beim Login dann grundsätzlich sein SSH Schlüssel Passwort eingeben muß und nicht sein Standard Unix Passwort. Wer das möchte, der kann das gerne machen, ich finde das nicht so schön, v.a. weil es mich nervt, wenn ich mich als User einlogge, der gar keine SSH Schlüssel besitzt.

Es ist aber auch möglich, sich mit seinem Unix Passwort anzumelden und dennoch die SSH Schlüssel zu laden, vorausgesetzt, die beiden Passwörter stimmen überein. Prinzipiell sollte es auch möglich sein, wenn das Passwort anders ist, denn über den Parameter try_first_pass sollte pam-ssh in der Lage sein, bei einem nicht passenden Passwort extra nachzufragen. Das tut er aber hier nicht:

root@t41:/etc/pam.d# cat pam-ssh-auth
auth sufficient pam_ssh.so try_first_pass keyfiles=id_dsa,id_rsa,identity,id_dsa1,id_dsa2,id_dsa3
root@t41:/etc/pam.d# man libpam-ssh
[...]
try_first_pass This option is similar to the use_first_pass option,
except that if the previously obtained password fails,
the user is prompted for another password.
root@t41:/etc/pam.d#

Wo wir gerade bei den Parametern sind, die weiteren Parameter geben an, in welche SSH Schlüssel beim Start geladen werden sollen. D.h. falls noch mehr Schlüssel geladen werden sollen, müssen hier die Namen angepasst werden.

Ein Beispiel Modul (hier wdm):

root@t41:/etc/pam.d# cat wdm
#%PAM-1.0
auth required pam_nologin.so
auth required pam_env.so
@include common-auth
@include pam-ssh-auth
@include common-account
@include common-session
@include pam-ssh-session

Login sieht ähnlich aus, auch hier wird nach der Zeile @include common-auth die Zeile @include pam-ssh-auth hinzugefügt. Und die Zeile @include pam-ssh-session wird hinter die Zeile @include pam-session eingefügt.

Wenn man das Prinzip verstanden hat, wie pam konfiguriert wird, ist es relativ simpel. Man könnte z.B. auch die obigen Zeilen an das Ende der Dateien common-auth bzw. common-session hinzufügen. Der Vorteil hier ist, dass automatisch alle Services, die diese beiden Module benutzen automatisch die pam-ssh Module benutzen.

Ich muß noch hinzufügen, dass pam-ssh hier bei grafischer Anmeldung nicht funktioniert hat. Es wurden keinerlei Keys geladen. Woran das lag, konnte ich jetzt nicht feststellen. Außerdem sollte man vielleicht noch erwähnen, dass es unter Berücksichtigung der Sicherheit eventuell kein so guter Rat ist, dass alle Schlüssel das gleiche Passwort haben und das diese Schlüssel dann auch alle gleich beim Start geladen werden. Wenn der Zugang kompromittiert wurde, müssen dann nämlich auch die Zugänge zu allen anderen Systemen als kompromittiert gelten, wenn die Schlüssel ohne Passwort benutzbar ist. (Das gilt natürlich im gleichen Maße für keychain).

Vielleicht wäre es auch keine schlechte Idee, wenn ssh-add mit dem Parameter -t gestartet würde. So kann man angeben, dass diese Schlüssel nur eine bestimmte Zeitspanne gültig sind:

cb@t41:~$ ssh-add -t 5 ~/.ssh/id_dsa && ssh-add -l && sleep 5 && ssh-add -l
Enter passphrase for /home/cb/.ssh/id_dsa:
Identity added: /home/cb/.ssh/id_dsa (/home/cb/.ssh/id_dsa)
Lifetime set to 5 seconds
1024 d4:3d:21:a7:fe:16:39:a4:f5:12:d7:cd:8f:aa:6d:10 /home/cb/.ssh/id_dsa (DSA)
The agent has no identities.
cb@t41:~$

SSH Schlüssel sind erstellt und Putty wurde konfiguriert. Ein Nachteil der bisherigen Lösung ist, dass für jede Shell ein neuer ssh-agent gestartet werden muß. D.h. es kann sein, dass mehr ssh-agent laufen, als unbedingt nötig, weil man sich z.B. auf mehreren Konsolen eingeloggt hat. Das Problem hierbei ist, dass die Shells nicht ihre Umgebung voneinander erben, sondern jedesmal mit einer neuen Umgebung initialisiert werden und demzufolge einen eigenen ssh-agent starten.

Das ist nicht nur eine Verschwendung von Ressourcen, sondern auch für den Benutzer unbequem, weil er doch wieder x-mal sein Passwort eingeben muß.

Hier kommt nun keychain ins Spiel. Dabei handelt es sich um ein Wrapper - Shellscript, dass die Umgebungsvariablen vom ssh-agent persistent speichert und so auch neuen Login-Shells zur Verfügung stellt. Nebenbei schreibt es diese Umgebungsvariablen automatisch für Bourne-Shell, C-Shell und neuerdings wohl auch für die Fishshell, so dass jede Shell sie entsprechend auswerten kann.

Wenn keychain gestartet wird, schaut es nach, ob die gespeicherten Variablen noch valide sind, falls nein startet es einen neuen ssh-agent, schreibt dessen Umgebungsvariablen in ein Shellscript und fügt einen neuen Schlüssel mit ssh-add hinzu. Man muß also nur dann die Passphrase für den Schlüssel eingeben, wenn dieser das erstemal entschlüsselt wird.

Darüber hinaus besitzt keychain noch einige weitere nützliche Parameter. Hier hilft die manpage weiter.

Um keychain automatisch beim Login zu starten, sollte man einen Aufruf in das Startscript der Shell schreiben. Für die bash könnte man z.B. das folgende in ~/.bash_profile schreiben:

Ein Problem gibt es noch. Was passiert, wenn X11 gestartet wird? Man kann dem ssh-add über eine Umgebungsvariable noch mitteilen, welches Programm zur Abfrage der Passphrase gestartet werden soll. So hab ich z.B. in meiner .xinitrc folgendes definiert:

Für Debian muß dafür noch das Paket ssh-askpass installiert werden und schon fragt der ssh-agent grafisch nach, was gestartet werden soll. Alternative Pakete existiern. apt-cache search ssh-askpass zeigt sie an

Mittlerweile beherrscht keychain auch den Umgang mit dem gpg-agent. Vereinfacht gesagt, ist die Funktion von gpg-agent ähnlich dem ssh-agent - es verwaltet das Passwort des geheimen gpg-Schlüssels.

Weitere Informationen zu keychain bekommt man auf der Website des Projekts. Eine genaue Vorstellung liefert eine Artikelserie auf developerworks (Teil 1, Teil 2 und Teil 3)

weitere Artikel kommen bestimmt...

Im vorigen Artikel wurde beschrieben, wie man ssh mit Schlüsseln benutzt. Man kann einen so generierten privaten Schlüssel auch mit Putty benutzen. Im Lieferumfang von putty befindet sich das Programm Putty Key Generator (puttygen.exe). Diese Programm startet man.

Dann clickt man auf Conversions, Import Key:

Und dann muß man seinen privaten Schlüssel id_rsa entschlüsseln:

Und dann speichert man diesen Schlüssel im Putty eigenen Format (putty private key):



Mit dem Programm Putty Authentication Agent (pageant.exe) kann ein so generierter Schlüssel geladen werden und steht dann putty zum Anmelden im Speicher zur Verfügung.


Mit einem kleinen Batchscript kann man beim Start von Windows dafür sorgen, dass immer pageant.exe gestartet wird:

Im Skript einfach die Pfade anpassen und in den Startup/Autostart Ordner kopieren und schon startet bei der Anmeldung von Windows ein kleines Fenster von pageant.exe und möchte gern das Passwort für den angegebenen Schlüssel haben.

Das könnte man natürlich noch ausbauen und gleich eine ssh-Verbindung zu einem Server starten.

Dies ist eine kurze Anleitung, wie man ssh mit keys benutzt. Vergleichbare Anleitungen finden sich wahrscheinlich haufenweise bei Google. Dies hier ist meine, damit ich nicht immer Google bemühen muss.

Voraussetzung dafür ist natürlich, dass PublicKey-Authentifizierung überhaupt erlaubt ist. Dies geschieht durch die Anweisung PubkeyAuthentication yes in /etc/ssh/sshd_config Und wenn man schon mal die Konfiguration prüft, kann man auch gleich überprüfen, dass Protokoll 2 verwendet wird und nicht das veraltete 1:

Sieht gut aus. Nun können wir einen Key erstellen. Dies geschieht auf dem Client, von dem nachher auf den Server zugegriffen werden soll.
Grundsätzlich gibt es 2 vershiedene Arten: DSA und RSA. Die Art des Keys wird mit dem Parameter -t angegeben(default ist hier RSA). Für RSA-keys kann mit dem Parameter -b noch die bitlänge angegeben werden (default sind hier 768bit, DSA ist nur gültig mit 1024 bit).

Wichtig: Der Key sollte immer verschlüsselt werden. Also nie eine leere Passphrase angegeben, denn falls dieser Schlüssel in falsche Hände gerät, dann hat der Angreifer damit auch gleich Zugriff auf den Server.
Der Schlüssel besteht dabei aus einem privaten und einem öffentlichen Teil. Der öffentliche Schlüssel (id_rsa.pub) authentifiziert gegen den privaten Schlüssel (id_rsa), d.h. er muß auf den Server kopiert werden. Dafür gibt es den Befehl ssh-copy-id. Man kann es aber auch händisch machen:

Fertig. Jetzt noch die Verbindung testen:

user@host ~$ ssh -v -i id_rsa user@server "exit"
[...]
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type
Enter passphrase for key 'id_rsa':
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).

Es wurde einfach eine SSH-Verbindung mit dem Schlüssel id_rsa (-i) aufgebaut, die gleich wieder beendet wurde.Die Logausgaben (-v) zeigen, dass auch wirklich die PublicKey Methode verwendet wurde (Hervorhebung durch mich).
Das Passwort wird nur zur Entschlüsselung des privaten Schlüssels (id_rsa) benötigt und nicht, um sich auf dem Server anzumelden. Es wandert also nicht über die "Leitung".

Nun ist es bisher nicht sonderlich komfortabel, die Passphrase muß auch weiterhin jedesmal eingegeben werden. Deshalb gibt es den ssh-agent. Wenn dieser gestartet wird, speichert er das Passwort im RAM und nutzt dieses dann zum einloggen. Auch diesem muß einmal das Passwort mitgegeben werden, dann jedoch benötigt er es nicht mehr, vorausgesetzt, der ssh-client weiß, dass er den ssh-agent benutzen soll.
Einen Schlüssel kann dem ssh-agent über ssh-add mitgegeben werden. Hier wird dann auch nach dem Passwort des Schlüssels gefragt.

Zunächst wird der ssh-agent gestartet:

Wenn der ssh-agent gestartet wird, startet er sofort im Hintergrund und gibt ein paar Umgebungsvariablen aus. Die Ausgabe erfolgt so, dass sie sofort an die bash weitergegeben werden kann. Damit der ssh-agent also genutzt werden kann, müssen diese Umgebungsvariablen der Shell zur Verfügung gestellt werden. Dies kann z.B. mit eval geschehen.
Neue Schlüssel können mit ssh-add hinzugefügt werden:

Damit dies z.B. automatisch bei jedem Einloggen geschieht, kann man das folgende in seine .bashrc schreiben (falls die bash die login Shell ist):

Der Nachteil, loggt man sich auf verschiedenen Terminals ein, so werden u.U. mehrere ssh-agent gestartet. Wie man das komfortabel löst, erklärt eine andere Geschichte.

Ah, das ist irgendwie beruhigend:


Fail2ban ist in Debian Unstable enthalten, scannt verschiedene logfiles und sperrt IPs (mittels iptables), die zu oft fehlerhafte, also abgelehnte Logins verursachten.