EDV:OpenAFS/Install i386 linux26
Installation eines OpenAFS-Clients bei Linux mit 2.6.x Kernel
Als Beispiel dient Debian 4.0 Codename Etch.
Heimdal Kerberos (Client) installieren
Dies ist optional, kann aber unter Umständen einiges vereinfachen, da unser AFS auch auf Heimdal zurückgreift.
aptitude install heimdal-clients
Die folgenden Fragen wie folgt beantworten:
| Kerberos Realm | KIP.UNI-HEIDELBERG.DE |
| Hesiod-Domain | .kip.uni-heidelberg.de |
| Kerberos Server | ldap.kip.uni-heidelberg.de ldap2.kip.uni-heidelberg.de |
| Admin Server von Kerberos | ldap.kip.uni-heidelberg.de |
OpenAFS installieren
Binaries installieren:
aptitude install openafs-client openafs-krb5
Es empfielt sich mindestens die Version 1.4.2 zu installieren. Diese gibt es ab Debian 4.0 Codename etch oder für sarge in den sarge-backports:
echo "## Backports deb http://www.backports.org/debian sarge-backports main contrib non-free " >>/etc/apt/sources.list aptitude update aptitude update aptitude -t sarge-backports install openafs-client openafs-doc openafs-modules-source |
Die folgenden Fragen wie folgt beantworten:
| AFS-Zelle | kip.uni-heidelberg.de |
| Größe des AFS-Cache (kb) | 50000 |
| /afs dynamisch ? | Nein |
| Rechnernamen des Datenbank-Servers | afsdb1.kip.uni-heidelberg.de afsdb2.kip.uni-heidelberg.de |
| Openafs-Client starten | Ja (oder Nein wenn nicht erwünscht) |
OpenAFS Kernel Modul erstellen/installieren
Um das Kernel-Modul für OpenAFS zu erstellen, ist Folgendes zu tun:
aptitude install module-assistant openafs-modules-source cd /usr/src module-assistant prepare openafs module-assistant build openafs dpkg -i openafs-modules-2.6.18-5-686_1.4.2-6+2.6.18.dfsg.1-13_i386.deb
| Dies gilt nur für den aktuellen Kernel und muss dann für andere Kernel wiederholt werden! |
Nun kann auch der OpenAFS-Client gestartet werden:
/etc/init.d/openafs-client force-start
Test
$ ls -l /afs lrwxr-xr-x 1 daemon root 21 2007-01-31 12:37 kip -> kip.uni-heidelberg.de drwxr-xr-x 2 root root 2048 2007-02-12 12:05 kip.uni-heidelberg.de
Link für die Homeverzeichnisse anlegen
Als Homeverzeichnis steht dann nicht der ganze Pfad '/afs/kip/user/userX' im LDAP, sondern /afsuser/userX. Daher muss dieser Link angelegt werden, falls AFS als Homeverzeichnis verwendet werden soll:
ln -s /afs/kip.uni-heidelberg.de/user /afsuser
NSS-Konfiguration (Namensauflösung)
Für die Namensauflösung (Nutzername/Gruppenname zu uid/gid-Nummer) ist LDAP zuständig, sofern das auf den jeweiligen Client gewünscht ist.
Hier ist beschrieben, wie die Konfiguration erfolgen sollte: EDV:LDAP#NSS (Namensauflösung)
PAM-Konfiguration (Pluggable Authentication Modules)
Wenn zum Login die AFS bzw. LDAP-Accounts verwendet werden sollen, muss PAM entsprechend konfiguriert werden.
Zur Vorbereitung muss erst einmal das LDAP-PAM-Module wie hier beschrieben konfiguriert werden: EDV:LDAP#PAM (Pluggable Authentication Modules)
Nun die PAM-Module installieren:
aptitude install libpam-heimdal libpam-openafs-session
Jetzt nur noch einen Eintrag für pam_krb5.so für den jeweiligen Dienst hinzufügen oder allgemein in den common-*-Dateien. Damit es nicht zu einfach wird teilen wir jetzt alles auf. Die Authentisierung läuft über Kerberos, das Accountmanagement über LDAP und für die Session benötigen wir AFS. Die fertigen PAM-Dateien/Einträge sehen dann zum Beispiel so aus:
#/etc/pam.d/common-auth auth sufficient pam_unix.so nullok_secure auth required pam_krb5.so ignore_root minimum_uid=1000 ignore_k5login use_first_pass
#/etc/pam.d/common-account account sufficient pam_unix.so account required pam_ldap.so ignore_unknown_user
#/etc/pam.d/common-session session required pam_unix.so session optional pam_krb5.so ignore_root session optional pam_openafs_session.so
Single-Sign-On über SSH
Gleich vorweg, die normale Public-Key-Authentisierung von SSH funktioniert nicht, da kein anonymer Zugriff auf das '.ssh'-Verzeichnis im AFS möglich ist und auch nicht sein sollte!
Aber als Lösung für ein Single-Sign-On bietet sich die GSSAPI-Authentisierung von SSH an. Nun sind dazu einige Schritte nötig:
SSH-Server konfigurieren
In der /etc/ssh/sshd_config folgendes rein schreiben:
KerberosAuthentication yes GSSAPIAuthentication yes GSSAPICleanupCredentials yes
SSH-Server neustarten:
/etc/init.d/ssh restart
SSH-Client konfigurieren
Damit der Client auch GSSAPI verwendet muss dies explizit eingestellt werden. Dazu entweder in der globales /etc/ssh/ssh_config oder in der Nutzerspezifischen ~/.ssh/config folgendes eintragen:
GSSAPIAuthentication yes GSSAPIDelegateCredentials yes
Kerberos Host-Key erstellen
Für die Authentisierung ist ein Host-Key von Kerberos notwendig!
 Dieser kann allerdings nur von der EDV-Abteilung erstellt und eingetragen werden!
|
Dazu Key im LDAP erstellen (gq)!
Nun als root auf dem Rechner einloggen (hostY):
root@hostY:~# kadmin -p user/admin kadmin> cpw -r host/hostY.kip.uni-heidelberg.de kadmin> get host/hostY.kip.uni-heidelberg.de kadmin> ext host/hostY.kip.uni-heidelberg.de kadmin> quit
Kontrolle:
root@hostY:~# ktutil list
keytab erzeugen ohne sich auf dem Server einzuloggen
Ist mal ein versuch:
# env KRB5_KTNAME=hostY.keytab kadmin -p user/admin
kadmin> cpw -r host/hostY.kip.uni-heidelberg.de
user/admin@KIP.UNI-HEIDELBERG.DE's Password:
kadmin> get host/hostY.kip.uni-heidelberg.de
Principal: host/hostY.kip.uni-heidelberg.de@KIP.UNI-HEIDELBERG.DE
Principal expires: never
Password expires: never
Last password change: never
Max ticket life: 1 day
Max renewable life: 1 week
Kvno: 2
Mkvno: 0
Last successful login: never
Last failed login: never
Failed login count: 0
Last modified: 2008-07-09 12:52:42 UTC
Modifier: unknown
Attributes:
Keytypes: des3-cbc-sha1(pw-salt), des-cbc-md5(pw-salt), des-cbc-md4(pw-salt), des-cbc-crc(pw-salt), arcfour-hmac-md5(pw-salt), aes256-cts-hmac-sha1-96(pw-salt)
PK-INIT ACL:
Aliases:
kadmin> ext host/hostY.kip.uni-heidelberg.de
kadmin> quit
Damit hat man die Datei hostY.keytab erzeugt.
Kerberos Key holen und einloggen
Damit wir uns nun einloggen können müssen wir uns den entsprechenden Kerberos-Key holen.
kinit userX klist -v
Das krbtgt (Kerberos-Ticket-Granting-Ticket) muss forwardable sein! Das kann mit 'klist -v' kontrolliert werden:
klist -v |
Nun sollte ein Login ohne weitere Passwordeingabe auf den Server möglich sein:
ssh -l userX hostY
