SSH via RSA SecurID Authentifizierung
Machen wir es kurz ... dieses Thema bringt einen schier zur Verzweifelung, wenn der Administrator des RSA/ACE Server sich strikt weigert, den Benutzern eine Shell einzutragen.
Damit fällt das PAM-Modul von RSA scheinbar für die Benutzung im Kontext SSH aus - denkt man - und alle Welt verweist sofort auf die Kombination Radius / ACE.
Diese Empfehlung scheint aber eher eine Verschwörung, denn ein sinnvoller Hinweis zu sein, denn einige Stunden "googeln" brachten zutage, dass alle Welt davon spricht, jeder es benutzen möchte, niemand weiß, wie es geht und letztlich wohl kaum jemand es jemals realisiert hat.
Dabei sollte man tunlichst - wie in meinem Falle - einfach mal zurück zur eigentlichen Fragestellung gehen: was will ich eigentlich?
In meinem Falle ist dies der Wunsch, einen SSH Login sowohl durch das "lokale" Passwort, als auch durch einen gültigen SecurID Token authentifizieren zu lassen.
In der Praxis wollen die meisten Administratoren eine Abfolge "Login", "Password", "Token" - dies führt, in Zusammenhang mit der Ablehnung des Eintrages einer gültigen Shell im RSA / ACE Server, dazu, dass man keinen Erfolg hat (die "Dummy"-Shell wirft den Benutzer sofort wieder raus).
Die Abfolge "Login", "Token", "Password" eröffnet aber im Reich der PAM Module ganz ungeahnte Möglichkeiten ...
Lange Rede, kurzer Sinn - PAM Agent von RSA herunterladen, installieren, sdconf.rec vom RSA Admin holen und in /etc/pam.d die sshd editieren:
#%PAM-1.0
auth required pam_securid.so
auth include common-auth
auth required pam_nologin.so
account include common-account
password include common-password
session include common-session
Ein rcsshd restart und fertig.
Was passiert? Nun, ganz einfach: die Authentifizierung am RSA / ACE ist erforderlich, ist aber nicht die einzige Methode, da die anderen - entgegengesetzt der Empfehlung der Dokumentation von RSA - noch aktiv sind.
Um zu verschleiern, ob wir nun einen falschen Token oder ein falsches PW angegeben haben, werden immer alle PAM-Einträge abgearbeitet und dann ggf ein "Access denied" ausgegeben.
Ergo: die Authentifizierung läuft zunächst gegen RSA / ACE, dann erfolgt eine Authentifizierung gegenüber den "lokalen" Mechanismen (z.B. /etc/passwd und /etc/shadow), welche auch eine gültige Umgebung inkl Shell beinhalten.
Referenzen:
http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/Linux-PAM_SAG.html
http://gruen24.gr.funpic.de/selflinux/html/grundlagen_sicherheit05.html
http://www.mpipks-dresden.mpg.de/~mueller/docs/suse9.2/suselinux-adminguide_de/html/ch21s03.html
http://www.softpanorama.org/Authentication/SecurID/installation_of_securid_client_on_suse.shtml