2017-01-28 2 views
0

Ich habe eine PHP-Anwendung, mit Benutzernamen und öffentlichen SSH-Schlüssel drin. Ich möchte diese Konten als das Benutzer-Back-End von openssh verwenden.Externes Skript für Konto mit pam_exec für openssh

Ich denke, ich brauche pam_exec und ein PHP/Bash-Skript. Ich habe ein PHP-Skript geschrieben, das ich am CLI ausführen kann (Der Shebang setzt ein env der PHP-Programmdatei). Wenn ich dies in ein Bash-Skript einbinden muss, um auf Umgebungsvariablen zuzugreifen, kann ich das tun. Das Skript nimmt zur Zeit einen Benutzername als erster und einziger Parameter wie folgt:

/opt/scripts/my-auth-script.php user_to_look_for 

Die Skript Null auf Erfolg beenden wird (der Benutzer vorhanden ist) oder Ausgang 1, wenn nicht. Es ist momentan in Ordnung oder Fehlgeschlagen, aber ich kann das einfach ausschalten.

Also, meine Frage ist, wie habe ich pam_exec Anruf mein Skript nach Benutzerkonten suchen, bevor Sie auf das eigentliche Host-System für Benutzerkonten?

Antwort

0

Ich habe es funktioniert. Dazu müssen Sie die Einstellungen authorizedKeysCommand und AuthorizedKeyUser von openssh in sshd_config festlegen. Es gibt einen Vorbehalt. Der Grund dafür, dass github und andere ssh als Service über einen einzelnen Login-Benutzer bereitstellen, ist, dass der aufgerufene Benutzer durch das angemeldete System auflösbar sein muss, also lokal existieren muss, oder die Benutzer-db muss mit einer entfernten Quelle wie LDAP verbunden sein, die dann ebenfalls in die Anwendung integriert werden müsste.

Der Weg, um dies zu umgehen, ist jedoch, dass der AuthorizedKeyCommand Parameter annehmen kann,% u für Benutzername und auch in diesem Fall% k für Schlüssel oder% f für sha256 Fingerabdruck des Schlüssels. Dann kann dieses Skript den generischen Benutzernamen ignorieren, den es erhalten hat, und dann einfach die Datenbank nach einer Übereinstimmung für den Schlüssel oder Fingerabdruck überprüfen. Wenn wir es finden, haben wir den Benutzer für diesen Schlüssel und die erfolgreiche Authentifizierung. Wenn nicht, wir nicht.