Kerberos to sieciowy system/protokół umożliwiający uwierzytelnianie się użytkownikom dzięki usługom udostępnianym przez bezpieczny serwer. Kerberos zwiększa bezpieczeństwo i poziom kontroli nad usługami takimi jak rlogin, zdalne kopiowanie, kopiowanie w obrębie systemu.
Poniższe instrukcje można zastosować jako przewodnik po konfiguracji Kerberosa w takiej postaci, w jakiej dystrybuowany jest on z systemem FreeBSD. Powinieneś jednak zajrzeć również do stron podręcznika aby mieć kompletny obraz systemu.
Kerberos jest opcjonalnym komponentem FreeBSD. Najprostszym sposobem instalacji jest wybranie pozycji 'krb4' lub 'krb5' podczas instalacji systemu za pomocą programu sysinstall. Zainstaluje to odpowiednio 'eBones' ( KerberosIV ) lub 'Heimdal' ( Kerberos5 ). Załączono je do dystrybucji systemu, ponieważ tworzone są poza USA/Kanadą i były dostępne w czasie restrykcji co do eksportu kodu kryptograficznego poza granice USA.
Możliwe jest również zastosowanie implementacji MIT Kerberosa, dostępnej w kolekcji portów jako security/krb5.
Operację tą przeprowadza się tylko na serwerze Kerberosa. Na początek upewnij się, że nie posiadasz starszych baz danych. Wejdź do katalogu /etc/kerberosIV i sprawdź, czy istnieją w nim tylko poniższe pliki:
# cd /etc/kerberosIV
# ls
README krb.conf krb.realms
Jeśli znajdują się tu jakieś dodatkowe pliki ( np.principal.* lub master_key ), musisz użyć najpierw polecenia kdb_destroy by skasować starą bazę Kerberosa - lub jeśli akurat usługa ta nie pracuje, skasować dodatkowe pliki.
Następnie powinieneś otworzyć do edycji pliki krb.conf i krb.realms by określić otoczenie (ang. realm) Kerberosa. W tym przypadku będzie to EXAMPLE.COM a serwerem grunt.example.com. Edytujemy lub tworzymy plik krb.conf:
# cat krb.conf
EXAMPLE.COM
EXAMPLE.COM grunt.example.com admin server
CS.BERKELEY.EDU okeeffe.berkeley.edu
ATHENA.MIT.EDU kerberos.mit.edu
ATHENA.MIT.EDU kerberos-1.mit.edu
ATHENA.MIT.EDU kerberos-2.mit.edu
ATHENA.MIT.EDU kerberos-3.mit.edu
LCS.MIT.EDU kerberos.lcs.mit.edu
TELECOM.MIT.EDU bitsy.mit.edu
ARC.NASA.GOV trident.arc.nasa.gov
Akurat w naszym przypadku pozostałe dziedziny (ang. ``realm'') nie muszą być wpisane. Zostały podane jako przykład jak wskazać wiele dziedzin jednocześnie. Na razie możesz ich nie wpisywać aby zachować klarowność.
Pierwsza linia nazywa konkretną dziedzinę w którym pracuje system. Pozostałe linijki zawierają pary kluczy w formacie dziedzina/host. Wskazywany host działa we wskazanej dziedzinie jako ``centrum dystrybucji kluczy''. Dodatkowy dopisek admin server po nazwie hosta oznacza, że pełni on również funkcje administracyjnego serwera bazy danych. Dalsze informacje tych terminów można znaleźć na stronie podręcznika Kerberosa.
Musimy teraz dodać grunt.example.com do dziedziny EXAMPLE.COM oraz wszystkie hosty w domenie .example.com do dziedziny EXAMPLE.COM. Plik krb.realms zostaje zatem uaktualniony do poniższej postaci:
# cat krb.realms
grunt.example.com EXAMPLE.COM
.example.com EXAMPLE.COM
.berkeley.edu CS.BERKELEY.EDU
.MIT.EDU ATHENA.MIT.EDU
.mit.edu ATHENA.MIT.EDU
I ponownie - nie musisz wymieniać wszystkich nazw dziedzin ponieważ zostały podane tylko dla przykładu. Nie musisz ich wpisywać aby zachować jasność.
Pierwsza linijka umieszcza ten konkretny system we wskazanym otoczeniu. Pozostałe linijki pokazują domyślne systemy w poszczególnych nazwanych dziedzin.
Jesteśmy teraz gotowi do stworzenia bazy danych. Należy to wykonać tylko na serwerze Kerberosa (lub na systemie pełniącym funkcje Centrum Dystrybucji Kluczy). Należy wykonać polecenie kdb_init:
# kdb_init
Realm name [default ATHENA.MIT.EDU ]: EXAMPLE.COM
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter Kerberos master key:
Należy teraz zapisać klucz tak, by serwery na lokalnej maszynie były w stanie go zlokalizować. W tym celu należy wydać polecenie kstash.
# kstash
Enter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Zaszyfrowane hasło główne zostaje zapisane w pliku /etc/kerberosIV/master_key.
Do każdej bazy danych należy dodać wpisy dotyczące dwóch poleceń, które będą zabezpieczane przez Kerberosa - kpasswd i rcmd.
Dwa wskazane demony umożliwiają innym systemom zmianę haseł Kerberosa i wykonywanie poleceń takich jak rcp, rlogin czy rsh.
Dodajmy te wpisy:
# kdb_edit
Opening database...
Enter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.
Principal name: passwd
Instance: grunt
<Not found>, Create [y] ? y
Principal: passwd, Instance: grunt, kdc_key_ver: 1
New Password: <---- wprowadź ciąg znaków RANDOM
Verifying password
New Password: <---- wprowadź ciąg znaków RANDOM
Random password [y] ? y
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
Max ticket lifetime (*5 minutes) [ 255 ] ?
Attributes [ 0 ] ?
Edit O.K.
Principal name: rcmd
Instance: grunt
<Not found>, Create [y] ?
Principal: rcmd, Instance: grunt, kdc_key_ver: 1
New Password: <---- wprowadź ciąg znaków RANDOM
Verifying password
New Password: <---- wprowadź ciąg znaków RANDOM
Random password [y] ?
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
Max ticket lifetime (*5 minutes) [ 255 ] ?
Attributes [ 0 ] ?
Edit O.K.
Principal name: <---- pusty wpis spowoduje opuszczenie programu
Musimy teraz uzyskać wszystkie instancje, definiujące zestaw usług na każdej maszynie. Wykonuje się to poleceniem ext_srvtab. Tworzy ono plik, który należy następnie skopiować lub przenieść w bezpieczny sposób do katalogu /etc/kerberosIV u każdego klienta Kerberosa. Plik musi istnieć na wszystkich serwerach i klientach, jest również niezbędny do pracy systemu Kerberos.
# ext_srvtab grunt
Enter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Generating 'grunt-new-srvtab'....
Polecenie tworzy tymczasowy plik, którego nazwę należy zmienić na srvtab tak by mogły go zlokalizować wszystkie serwery. Użyj polecenia mv aby przesunąć go w odpowiednie miejsce:
# mv grunt-new-srvtab srvtab
Jeśli plik znajduje się na systemie klienta, a sieć nie jest uważana za bezpieczną, skopiuj plik client-new-srvtab na nośnik przenośny i przetransportuj go do serwera. Upewnij się, że zmieniłeś nazwę na srvtab umieszczając go w katalogu /etc/kerberosIV i że zmieniłeś uprawnienia do pliku na 600:
# mv grumble-new-srvtab srvtab
# chmod 600 srvtab
Musimy teraz dodać trochę wpisów do bazy danych. Na początek stwórzmy wpis dla użytkownika jane. Użyjemy do tego polecenia kdb_edit:
# kdb_edit
Opening database...
Enter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.
Principal name: jane
Instance:
<Not found>, Create [y] ? y
Principal: jane, Instance: , kdc_key_ver: 1
New Password: <---- wpisz tutaj dobre hasło
Verifying password
New Password: <---- a teraz je potwierdź
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
Max ticket lifetime (*5 minutes) [ 255 ] ?
Attributes [ 0 ] ?
Edit O.K.
Principal name: <---- pusty wpis spowoduje opuszczenie programu
Na początek należy wystartować demony Kerberosa. Zwróć uwagę na to, że jeśli prawidłowo wyedytowałeś plik /etc/rc.conf stanie się to automatycznie podczas startu systemu. Demony powinny startować tylko na serwerze - klienci Kerberosa automagicznie ściągną sobie potrzebne rzeczy z katalogu /etc/kerberosIV.
# kerberos &
Kerberos server starting
Sleep forever on error
Log file is /var/log/kerberos.log
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Current Kerberos master key version is 1
Local realm: EXAMPLE.COM
# kadmind -n &
KADM Server KADM0.0A initializing
Please do not use 'kill -9' to kill this job, use a
regular kill instead
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Możesz teraz spróbować użyć polecenia kinit by otrzymać żeton dla konta jane ( które stworzyliśmy przed momentem ):
% kinit jane
MIT Project Athena (grunt.example.com)
Kerberos Initialization for "jane"
Password:
Możesz wylistować żetony przy użyciu polecenia klist by sprawdzić czy naprawdę zostały prawidłowo utworzone:
% klist
Ticket file: /tmp/tkt245
Principal: jane@EXAMPLE.COM
Issued Expires Principal
Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.EXAMPLE.COM@EXAMPLE.COM
Teraz spróbuj zmienić hasło przy użyciu polecenia passwd by sprawdzić, czy demon jest w stanie uwierzytelnienić się poprawnie w bazie danych Kerberosa:
% passwd
realm EXAMPLE.COM
Old password for jane:
New Password for jane:
Verifying password
New Password for jane:
Password changed.
Kerberos umożliwia nadawanie każdemu użytkownikowi wymagającemu przywilejów roota osobnego hasła do polecenia su. Dodamy teraz identyfikator użytkownika uprawnionego do użycia polecenia su. Proces ten kontrolowany jest przez skojarzenie instancji powłoki roota z demonem Kerberosa. Poleceniem kdb_edit tworzymy wpis jane.root w bazie danych Kerberosa:
# kdb_edit
Opening database...
Enter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.
Principal name: jane
Instance: root
<Not found>, Create [y] ? y
Principal: jane, Instance: root, kdc_key_ver: 1
New Password: <---- wprowadź dobre hasło
Verifying password
New Password: <---- ...a teraz je potwierdź
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
Max ticket lifetime (*5 minutes) [ 255 ] ? 12 <--- Niech będzie krótki!
Attributes [ 0 ] ?
Edit O.K.
Principal name: <---- pusty wpis spowoduje opuszczenie programu
Teraz spróbujmy uzyskać żetony by sprawdzić, czy nasz wpis działa
# kinit jane.root
MIT Project Athena (grunt.example.com)
Kerberos Initialization for "jane.root"
Password:
Musimy teraz dodać stworzone konto do pliku .klogin roota:
# cat /root/.klogin
jane.root@EXAMPLE.COM
Spróbuj teraz wykonać polecenie su:
% su
Password:
...i sprawdź jakie posiadasz żetony:
# klist
Ticket file: /tmp/tkt_root_245
Principal: jane.root@EXAMPLE.COM
Issued Expires Principal
May 2 20:43:12 May 3 04:43:12 krbtgt.EXAMPLE.COM@EXAMPLE.COM
W poprzednim przykładzie stworzyliśmy operatora jane z instancją konta roota. Tworząc konto użyliśmy nazwy opartej o identyfikator użytkownika systemowego i jest to domyślne działanie Kerberosa; że <principal>.<instance> w formie <username>.root umożliwi temu <username> dostęp do polecenia su jeśli wymagane wpisy znajdują się w pliku .klogin umieszczonym w katalogu domowym roota:
# cat /root/.klogin
jane.root@EXAMPLE.COM
Na tej samej zasadzie, wpiszemy podaną niżej treść do pliku .klogin w katalogu domowym użytkownika:
% cat ~/.klogin
jane@EXAMPLE.COM
jack@EXAMPLE.COM
Umożliwia to osobom z otoczenia EXAMPLE.COM uwierzytelnionym jako jane lub jack (przez kinit, patrz powyżej) wykonanie polecenia rlogin na konto jane na tym systemie (grunt) przez zastosowanie rlogin, rsh lub rcp.
Na przykład, jane loguje się do innego systemu stosując uwierzytelnianie zapewniane przez Kerberos:
% kinit
MIT Project Athena (grunt.example.com)
Password:
% rlogin grunt
Last login: Mon May 1 21:14:47 from grumble
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995
Na tej samej zasadzie Jack może zalogować się na konto Jane na tej samej maszynie (przy czym jane ma plik .klogin w postaci jak wyżej a osoba zarządzająca Kerberosem skonfigurowała konto jack z pustą instancją:
% kinit
% rlogin grunt -l jane
MIT Project Athena (grunt.example.com)
Password:
Last login: Mon May 1 21:16:55 from grumble
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995
| Poprzedni | Spis treści | Następny |
| S/Key | Początek rozdziału | Ściany Ogniowe |
This, and other documents, can be downloaded from ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
For questions about FreeBSD, read the
documentation
before contacting <questions@FreeBSD.org>.
For questions about this documentation, e-mail <doc@FreeBSD.org>.