Wie sieht die /etc/exports jetzt eigentlich aus?
Muss ich dazu in der /etc/ssh/sshd_config:
KerberosAuthentication yes
KerberosTicketCleanup yes
aktivieren und dann mit:
ssh -1 tux.gehr.lan
verbinden?
Die Option “-1” kenne ich nicht. Das sollte reichen sofern du ein Ticket hast:
ssh tux.gehr.lan
Läuft eigentlich der rpc-gssd.service auf dem Client:
systemctl status rpc-gssd.service
EDIT: So oder so mußt du ihn nach dem Erstellen der Keytab neustarten:
systemctl restart rpc-gssd.service
Nein, funktioniert nicht.
root@pc001:~# systemctl status rpc-gssd.service
● rpc-gssd.service - RPC security service for NFS client and server
Loaded: loaded (/lib/systemd/system/rpc-gssd.service; static; vendor preset: enabled)
Active: active (running) since Fri 2019-12-06 20:57:51 CET; 21min ago
Process: 712 ExecStart=/usr/sbin/rpc.gssd $GSSDARGS (code=exited, status=0/SUCCESS)
Main PID: 731 (rpc.gssd)
Tasks: 1 (limit: 4915)
Memory: 28.1M
CGroup: /system.slice/rpc-gssd.service
└─731 /usr/sbin/rpc.gssd
Dez 06 20:57:51 pc001 systemd[1]: Starting RPC security service for NFS client and server...
Dez 06 20:57:51 pc001 systemd[1]: Started RPC security service for NFS client and server.
Siehe EDIT
“Beitrag muss mindestens 20 Zeichen lang sein”
also die beiden am Master aktiviert und den ssh neu gestartet. Danach konnte ich mich vom Client aus mit:
s.gehr@pc001:~$ ssh tux.gehr.lan
anmelden. Hat er hier nun Kerberos benutzt?
Es ging um den CLIENT (die Konfigurations-Anpassung muß entsprechend auf dem CLIENT erfolgen):
kinit s.gehr
ssh pc001.gehr.lan
EDIT: Und wie siehts damit nun aus?
systemctl restart rpc-gssd.service
Also diese beiden am SSH-Server auf dem Client und nicht auf dem Master und dann auf dem Master:
kinit s.gehr
ssh pc001.gehr.lan
und dies:
systemctl restart rpc-gssd.service
dann auch auf dem Client?
Korrekt. Die Keytab ist nun hoffentlich auch auf dem CLient?
Ja. Am Client habe ich die beiden Zeilen in der sshd.conf aktiviert und ssh neu gestartet. Am Master habe ich mich als s.gehr angemeldet und:
kinit s.gehr
ssh pc001.gehr.lan
aufgerufen. Da konnte ich mich auf dem Client anmelden.
Verändert hat sich jedoch nichts. Mounten klappt nicht:
root@pc001:/home/s.gehr# systemctl restart rpc-gssd.service
root@pc001:/home/s.gehr# mount -vvv -t nfs4 -o sec=krb5i tux.gehr.lan:/home /home
mount.nfs4: timeout set for Fri Dec 6 21:38:02 2019
mount.nfs4: trying text-based options 'sec=krb5i,vers=4.2,addr=192.168.24.5,clientaddr=192.168.24.111'
mount.nfs4: mount(2): Permission denied
mount.nfs4: access denied by server while mounting tux.gehr.lan:/home
Dann solltest du doch mal in die Logs gucken. Wie sieht die /etc/exports auf dem SERVER aus?
Wenn ich:
journalctl -f
auf dem Master aufrufe erscheint keine Meldung die mit dem Mount zu tun hat. Die /etc/exports enthält:
"/home" -rw,root_squash,sync,subtree_check,sec=krb5i * # LDAP:cn=home,cn=tux.gehr.lan,cn=shares,dc=gehr,dc=lan
Und die Logs auf dem CLIENT? Hast du ihn mal rebootet?
Master und Client neu gestartet. Am Client:
root@pc001:~# journalctl -f
-- Logs begin at Wed 2019-12-04 21:08:48 CET. --
Dez 06 21:50:28 pc001 systemd[1774]: Listening on GnuPG cryptographic agent (ssh-agent emulation).
Dez 06 21:50:28 pc001 systemd[1774]: Listening on REST API socket for snapd user session agent.
Dez 06 21:50:28 pc001 systemd[1774]: Listening on D-Bus User Message Bus Socket.
Dez 06 21:50:28 pc001 systemd[1774]: Reached target Sockets.
Dez 06 21:50:28 pc001 systemd[1774]: Reached target Basic System.
Dez 06 21:50:28 pc001 systemd[1774]: Condition check resulted in Sound Service being skipped.
Dez 06 21:50:28 pc001 systemd[1774]: Reached target Main User Target.
Dez 06 21:50:28 pc001 systemd[1774]: Startup finished in 33ms.
Dez 06 21:50:28 pc001 systemd[1]: Started User Manager for UID 0.
Dez 06 21:50:28 pc001 systemd[1]: Started Session 4 of user root.
Dez 06 21:50:39 pc001 kernel: FS-Cache: Loaded
Dez 06 21:50:39 pc001 kernel: FS-Cache: Netfs 'nfs' registered for caching
Dez 06 21:50:39 pc001 kernel: NFS: Registering the id_resolver key type
Dez 06 21:50:39 pc001 kernel: Key type id_resolver registered
Dez 06 21:50:39 pc001 kernel: Key type id_legacy registered
Dez 06 21:50:45 pc001 PackageKit[1293]: daemon quit
Dez 06 21:50:45 pc001 systemd[1]: packagekit.service: Main process exited, code=killed, status=15/TERM
Dez 06 21:50:45 pc001 systemd[1]: packagekit.service: Succeeded.
Aber selbst wenn ich in den erweiterten NFS-Einstellungen sec=krb5i entferne und den Mount ohne -o sec=krb5i aufrufe kommt die gleiche Fehlermeldung.
Eine generelle Frage noch. Ist der WIKI-Artikel den generell zu ignorieren sprich keine der dort genannten Schritte durchzuführen? Hintergrund der Frage ist, ich habe alle Schritte nocheinmal ausgeführt. Inklusive der:
kvno=$(ldapsearch -D $(ucr get ldap/hostdn) -w $(cat /etc/machine.secret ) -h $(ucr get ldap/master) cn=$(hostname) -p 7389 krb5KeyVersionNumber | grep krb5KeyVersionNumber: | cut -d" " -f2)
ktutil add -w $(cat /etc/machine.secret ) -V $kvno -p nfs/$(hostname -f)@$(ucr get kerberos/realm) -e aes256-cts-hmac-sha1-96
ktutil add -w $(cat /etc/machine.secret ) -V $kvno -p nfs/$(hostname -f)@$(ucr get kerberos/realm) -e aes128-cts-hmac-sha1-96
ktutil add -w $(cat /etc/machine.secret ) -V $kvno -p nfs/$(hostname -f)@$(ucr get kerberos/realm) -e des-cbc-md5
ktutil add -w $(cat /etc/machine.secret ) -V $kvno -p nfs/$(hostname -f)@$(ucr get kerberos/realm) -e des-cbc-crc
und nun funktioniert es. Nun möchte ich die Schritte aber noch einmal durchführen d.h. ich setze den Master auf den Stand bevor ich damit angefangen habe zurück und pc001 wird auch neu aufgesetzt. Damit der Vorgang künftig für mich auch zu reproduzieren ist.
Ich habe ihn zumindest ignoriert.
Ich habe hier im Beitrag einen Befehlsaufruf mit leicht unterschiedlicher Formatierung:
/usr/share/univention-samba4/scripts/create_spn_account.sh --samaccountname "nfs-$HOSTNAME" --serviceprincipalname "nfs/$(hostname -f)" --privatekeytab nfs.keytab
und
/usr/share/univention-samba4/scripts/create_spn_account.sh --samaccountname "nfs-$HOSTNAME" --serviceprincipalname "nfs/$(hostname -f)" --privatekeytab nfs-$hostname.keytab
ist das Relevant?
und wie müssen in der Hauptmaske der Freigabe im UMC die Besitzverhältnisse sein. Ich habe hier:
Besitzer des Wurzelverzeichnis der Freigabe: Administrator
Besitzergruppe für das Wurzelverzeichnis der Freigabe: Domain Users
Dateiberechtigungen für das Wurzelverzeichnis der Freigabe: 770
ist das ok?
Naja wenn die Keytabs alle auf dem DC Master erzeugt werden, sollten diese in unterschiedlichen Dateien landen. Insofern ja.
Ich denke du willst da eher 750. Sonst hat die Gruppe Schreiberechtigung.