14.7. KerberosIV

Írta: Mark Murray. Eredetileg írta: Mark Dapoz.

A Kerberos egy olyan járulékos rendszer/protokoll, amellyel a felhasználók egy biztonságos szerver szolgáltatásain keresztül tudják hitelesíteni magukat. Ilyen szolgáltatás többek közt a távoli bejelentkezés, távoli másolás, a rendszeren belüli biztonságos másolás és minden olyan egyéb veszélyes feladat, amit számottevően megbízhatóbbá és irányíthatóbbá tettek.

A következő utasítások a FreeBSD-hez mellékelt Kerberos beállításához adnak útmutatást. A teljes leíráshoz azonban érdemes fellapoznunk a menet közben hivatkozott man oldalakat is.

14.7.1. A KerberosIV telepítése

A Kerberos a FreeBSD egyik választható komponense. Legkönnyebben úgy tudjuk feltelepíteni, ha a FreeBSD telepítése során a sysinstall programban kiválasztjuk a krb4 vagy krb5 terjesztések valamelyikét. Ezzel felrakhatjuk a Kerberos “eBones” (KerberosIV) vagy “Heimdal” (Kerberos5) elnevezésű változatait. A FreeBSD azért tartalmazza ezeket az implementációkat, mert nem az Amerikai Egyesült Államokban vagy Kanadában fejlesztették, így az Egyesült Államok titkosításokkal kapcsolatos kiviteli korlátozások korában minden olyan rendszer adminisztrátora el tudta érni, aki nem ezekben az országokban lakott.

A Kerberos MIT által fejlesztett implementációját egyébként a Portgyűjteményből a security/krb5 porton keresztül érhetjük el.

14.7.2. A kezdeti adatbázis létrehozása

Ezt a lépést csak a Kerberos szerveren kell elvégezni. Először is győződjünk meg róla, hogy semmilyen korábbi Kerberos adatbázis nem található a gépen. Váltsunk az /etc/kerberosIV könyvtárra és ellenőrizzük a következő állományok meglétét:

# cd /etc/kerberosIV
# ls
README		krb.conf        krb.realms

Ha rajtuk kívül további állományok is feltűnnének (mint például a principal.* vagy master_key), akkor a kdb_destroy paranccsal pusztítsuk el a régi Kerberos adatbázist, vagy ha nem fut már a Kerberos, akkor egyszerűen csak törüljük le ezeket.

Ezután lássunk neki a krb.conf és krb.realms állományok átírásán keresztül a Kerberos egyes övezeteinek (realm) létrehozásához. Itt most az EXAMPLE.COM lesz a létrehozandó övezet, a hozzá tartozó szerver pedig a grunt.example.com. Így szerkesszük át vagy készítsünk el a neki megfelelő krb.conf állományt:

# 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

A többi övezetnek valójában nem feltétlenül kell itt lennie. Ezek csupán azért szerepelnek itt, hogy bemutassák miként lehet egyetlen géphez hozzárendelni egyszerre több övezetet is. Az egyszerűség kedvéért nyugodtan elhagyhatóak.

Az első sor nevezi meg a rendszer által működtetett övezeteket. Az utána következő sorokban övezeteket és hálózati neveket láthatunk. Itt az első elem egy övezetet nevez meg, a második elem pedig az övezet “kulcselosztó központját” (key distribution center). A hálózati nevet követő admin server kulcsszavak arra utalnak, hogy az adott gép adminisztratív szerepet ellátó adatbázist is tartalmaz. Ezeket a fogalmakat részleteiben a Kerberos man oldalain ismerhetjük meg.

Ezután hozzá kell adnunk a grunt.example.com nevű gépet az EXAMPLE.COM övezethez, valamint az .example.com tartományban levő összes géphez létre kell hoznunk egy bejegyzést az EXAMPLE.COM övezetben. A krb.realms állományt ehhez a következőképpen kellene módosítanunk:

# 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

Ismét hozzátesszük, hogy a többi övezetnek nem kötelező itt szerepelnie. Ezek csupán azt demonstrálják, hogy miként kell egy gépet egyszerre több övezethez is beállítani. Az átláthatóság kedvéért minden további nélkül eltávolíthatjuk ezeket.

Itt az első sor az adott rendszert elhelyezi egy nevesített övezetbe. A többi sor azt mutatja meg, hogyan kell alapértelmezett módon a meghatározott altartományokba tartozó gépeket egy nevesített övezethez hozzárendelni.

Most már készen állunk az adatbázis létrehozására. Ehhez egyedül a Kerberos szerverét (avagy Kulcselosztó központját) kell elindítanunk. Adjuk ki a kdb_init parancsot:

# 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: 

Az üzenet fordítása:

Most az adatbázis mesterkulcsát kell megadni.  Fontos, hogy
NE FELEJTSÜK EL ezt a jelszót.

Most el kell mentenünk a kulcsot, így a helyi gépen futó szerverek fel tudják szedni. Ehhez a kstash parancsra van szükségünk:

# kstash

Enter Kerberos master key:

Current Kerberos master key version is 1.

Master key entered. BEWARE!

Az üzenet fordítása:

A Kerberos mesterkulcsának jelenlegi változata: 1.

VIGYÁZAT, megadták a mesterkulcsot!

Ez elmenti a titkosított mesterkulcsot az /etc/kerberosIV/master_key állományba.

14.7.3. Az egész beüzemelése

Mindegyik Kerberosszal őrzött rendszerrel kapcsolatban két ún. szereplőt (principal) kell még hozzátennünk az adatbázishoz. A nevük kpasswd és rcmd. Minden rendszerhez létre kell hoznunk ezeket a szereplőket, példányonként (instance) az egyes rendszerek neveivel.

A kpasswd és rcmd démonok teszik lehetővé a többi rendszer számára, hogy megváltoztathassák a Kerberos jelszavukat, valamint hogy futtathassák az rcp(1), rlogin(1) és rsh(1) parancsokat.

Vegyük fel ezeket a bejegyzéseket is:

# 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:                    <---- írjuk be, hogy “RANDOM”
Verifying password

New Password: <---- írjuk be, hogy “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:		<---- írjuk be, hogy “RANDOM”
Verifying password

New Password:           <---- írjuk be, hogy “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:         <---- ha nem adunk meg semmit, akkor kilép

14.7.4. A szerver állomány létrehozása

Most pedig kivonatolni kell azokat a példányokat, amelyek szolgáltatást definiálnak a gépen. Erre az ext_srvtab parancsot használjuk. Ennek eredményeképpen keletkezik egy állományt, amelyet biztonságos eszközökkel át kell másolni vagy át kell mozgatni az egyes Kerberos kliensek /etc könyvtárába. Ennek az állománynak egyaránt jelent kell lennie a szerveren és a kliensen is, nélküle a Kerberos működésképtelen.

# ext_srvtab grunt
Enter Kerberos master key:

Current Kerberos master key version is 1.

Master key entered. BEWARE!
Generating 'grunt-new-srvtab'....

Ez a parancs most létrehozott egy ideiglenes állományt, amit át kell nevezni az srvtab névre, hogy megtalálhassák a szerverek. Az eredeti rendszeren a mv(1) paranccsal tudjuk a helyére rakni:

# mv grunt-new-srvtab srvtab

Ha egy kliensnek szánjuk az állományt és a hálozatunkat nem tekinthetjük biztonságosnak, akkor a kliens-new-srvtab állományt másoljuk egy mozgatható adathordozóra és megbízható módon jutassuk el. Ne felejtsük el az állományt srvtab néven átrakni a kliens /etc könyvtárába és az engedélyeit 600-ra állítani:

# mv grumble-new-srvtab srvtab
# chmod 600 srvtab

14.7.5. Az adatbázis feltöltése

Ezt követően rögzítenünk kell néhány felhasználót is adatbázisban. Először is hozzunk létre egy bejegyzést a janos nevű felhasználónak. Ezt a kdb_edit parancs kiadásával tesszük meg:

# 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: janos
Instance:

<Not found>, Create [y] ? y

Principal: janos, Instance: , kdc_key_ver: 1
New Password:                <---- adjunk meg egy biztonságos jelszót
Verifying password

New Password:                <---- itt ismét adjuk meg a jelszót
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:		   <---- ha nem írunk be semmit, akkor kilép

14.7.6. Próbáljuk ki

Elsőként a Kerberos démonait kell beindítanunk. Ezzel kapcsolatban megjegyeznénk, hogy ha ehhez megfelelően átírtuk az /etc/rc.conf állományunkat, akkor ez az újraindítással együtt magától lezajlik. Ezt csak a Kerberos szerveren kell megcsinálni. A Kerberos kliensei maguktól összeszedik a működésükhöz szükséges adatokat az /etc/kerberosIV könyvtárból.

# 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!

A fenti figyelmeztetés fordítása:

A program leállítására ne a 'kill -9' parancsot, hanem a
normális kill parancsot használjuk

Ezután a kinit parancs használatával próbáljunk meg az előbb létrehozott janos azonosítónak kérni egy jegyet:

% kinit janos
MIT Project Athena (grunt.example.com)
Kerberos Initialization for "janos"
Password: 

A klist paranccsal most próbáljuk meg kilistázni a tokeneket és így ellenőrizni, hogy valóban rendelkezünk velük:

% klist
Ticket file:    /tmp/tkt245
Principal:      janos@EXAMPLE.COM

  Issued           Expires          Principal
Apr 30 11:23:22  Apr 30 19:23:22  krbtgt.EXAMPLE.COM@EXAMPLE.COM

Ezután a passwd(1) használatával próbáljuk meg megváltoztatni a jelszavunkat. Ezzel tudjuk ellenőrizni, hogy a kpasswd démon hozzáfér a Kerberos adatbázisához:

% passwd
realm EXAMPLE.COM
Old password for janos:
New Password for janos:
Verifying password
New Password for janos:
Password changed.

14.7.7. Adminisztrátori jogosultságok felvétele

A Kerberos lehetővé teszi, hogy mindegyik olyan felhasználónak, akinek rendszergazdai jogokra lenne szüksége, a su(1) eléréséhez külön meg tudjunk adni egy jelszót. Most már tudunk mondani egy olyan azonosítót is, amely jogosult a su(1) használatával root jogokat szerezni. Ezt úgy tudjuk megoldani, ha az adott szereplőhöz társítunk egy root példányt. A kdb_edit használatával készíteni tudunk egy janos.root bejegyzést a Kerberos adatbázisában:

# 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: janos
Instance: root

<Not found>, Create [y] ? y

Principal: janos, Instance: root, kdc_key_ver: 1
New Password:                    <---- ide csak egy BIZTONSÁGOS jelszót adjuk meg!
Verifying password

New Password:    	 	 <---- adjuk meg ismét a jelszót

Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
Max ticket lifetime (*5 minutes) [ 255 ] ? 12 <--- ne állítsuk nagyon hosszúra!
Attributes [ 0 ] ?
Edit O.K.
Principal name:		         <---- ha nem adunk meg semmit, akkor kilép

Ezt követően úgy tudunk megbizonyosodni a működéséről, hogy megpróbálunk neki tokeneket szerezni:

# kinit janos.root
MIT Project Athena (grunt.example.com)
Kerberos Initialization for "janos.root"
Password:

Most rakjuk bele a felhasználót a root .klogin állományába:

# cat /root/.klogin
janos.root@EXAMPLE.COM

Ezután próbáljunk meg kiadni a su(1) parancsát:

% su
Password:

Nézzük meg milyen tokenjeink is vannak:

# klist
Ticket file:	/tmp/tkt_root_245
Principal:      janos.root@EXAMPLE.COM

  Issued           Expires          Principal
May  2 20:43:12  May  3 04:43:12  krbtgt.EXAMPLE.COM@EXAMPLE.COM

14.7.8. Más parancsok használata

Az iménti példában létrehoztunk egy janos nevű szereplőt, amihez a root egy példányát rendeltük. Ez egy olyan felhasználón alapján történt, akinek a neve megegyezik a hozzá tartozó szereplővel, ami a Kerberosban alapértelmezés. Amennyiben a szükséges megjegyzések megtalálhatóak a root könyvtárában levő .klogin állományban, akkor a felhasználó.root formátumú szereplő.példány azonosító megengedi a felhasználó számára, hogy végrehajtsa a su(1) parancsot.

# cat /root/.klogin
janos.root@EXAMPLE.COM

Ehhez hasonlóan, ha a felhasználó saját könyvtárában megtalálható egy ilyen állomány:

% cat ~/.klogin
janos@EXAMPLE.COM
jozsef@EXAMPLE.COM

Ezzel a konfigurációval bárki, aki janos felhasználóként vagy jozsef felhasználóként (a kinit parancson keresztül) hitelesítette magát EXAMPLE.COM övezetből, ezen a rendszeren (grunt) bejelentkezhet a janos nevű felhasználóként vagy hozzáférhet az állományaihoz az rlogin(1), rsh(1) vagy rcp(1) használatával.

Például janos most egy másik Kerberost használó rendszerre jelentkezik be:

% 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

Vagy jozsef jelentkezik be ugyanazon a gépen janos hozzáférésével (a janos nevű felhasználónak a fentebb bemutatt .klogin állomány található a könyvtárában és a Kerberos üzemeltetéséért felelős személy létrehozott egy jozsef nevű szereplőt egy null példánnyal):

% kinit
% rlogin grunt -l janos
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

Ha kérdése van a FreeBSD-vel kapcsolatban, a következő címre írhat (angolul): <freebsd-questions@FreeBSD.org>.
Ha ezzel a dokumentummal kapcsolatban van kérdése, kérjük erre a címre írjon: <gabor@FreeBSD.org>.