
Ich habe auf meinem lokalen Host einen Radius-Server installiert und konfiguriert – er delegiert die Authentifizierung an einen Remote-LDAP-Server.
Zunächst sieht es gut aus: Ich kann über die Konsole testen:
# export user=skemp
# export pass=xxx
# radtest $user $pass localhost 1812 $secret
Sending Access-Request of id 185 to 127.0.0.1 port 1812
User-Name = "skemp"
User-Password = "xxx"
NAS-IP-Address = 192.168.1.168
NAS-Port = 1812
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=185,
In ähnlicher Weise kann ich das Anmeldetool verwenden, um dasselbe zu tun:
bash-4.0# /usr/libexec/auth/login_radius -d -s login $user radius
Password: $pass
authorize
Allerdings schlagen Remote-Logins über SSH fehl, ebenso wie Aufrufe von „login“, die von root gestartet werden. Wenn ich mir /var/log/radiusd.log ansehe, sehe ich kein tatsächliches Erfolgs-/Fehlerprotokoll, was bei Verwendung eines der vorherigen Tools der Fall ist.
Stattdessen protokolliert sshd nur:
sshd[23938]: Failed publickey for skemp from 192.168.1.9
sshd[23938]: Failed keyboard-interactive for skemp from 192.168.1.9 port 36259 ssh2
sshd[23938]: Failed password for skemp from 192.168.1.9 port 36259 ssh2
In /etc/login.conf habe ich Folgendes:
# Default allowed authentication styles
auth-defaults:auth=radius:
...
radius:\
:auth=radius:\
:radius-server=localhost:\
:radius-port=1812:\
:radius-timeout=1:\
:radius-retries=5:
Antwort1
Ich hatte ähnliche Probleme bei der Konfiguration von OpenBSD, um Authentifizierungen an einen LDAP-Server zu delegieren. Die einzige Möglichkeit, es zum Laufen zu bringen, war, einen Benutzer zur lokalen Datenbank hinzuzufügen, z. B.
useradd -s /bin/ksh -L ldap neuer_Benutzer
In deinem Fall wäre das sowas wie
useradd -s /bin/ksh -L radius neuer_Benutzer2
Da Sie jedoch für jeden Computer, der LDAP zur Authentifizierung verwendet, manuell einen Benutzereintrag erstellen müssen, würde dies die Notwendigkeit eines zentralen LDAP-Authentifizierungsservers untergraben. Mir gehen auch die Ideen aus.