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.
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.
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.
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
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
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
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.
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
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 1995Vagy 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 1995Ha 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>.