Предоставил Mark Murray. Оригинальный текст предоставил Mark
Dapoz.
Kerberos это сетевая дополнительная система/протокол, которая делает возможной
аутентификацию пользователей через сервисы на защищенном сервере. Такие сервисы, как
удаленный вход, удаленное копирование, защищенное копирование файлов между системами и
другие задачи с высоким риском становятся допустимо безопасными и более
контролируемыми.
Последующие инструкции могут использоваться в качестве руководства по настройке
поставляемого с FreeBSD Kerberos. Тем не менее, вам могут потребоваться страницы
справочника полного дистрибутива.
Kerberos это опциональный компонент FreeBSD. Простейший способ установки этой
программы это выбор krb4 или krb5
из sysinstall во время первой установки FreeBSD. Будет
установлен ``eBones'' (KerberosIV) или ``Heimdal'' (Kerberos5) вариант Kerberos.
Включение этих реализаций объясняется тем, что они разработаны вне США/Канады и доступны
вне этих стран, поскольку на них не влияют ограничения на экспорт криптографического кода
из США.
Кроме того, реализация MIT Kerberos доступна из коллекции портов в виде пакета security/krb5.
Это необходимо сделать только на сервере Kerberos. Во-первых, убедитесь что не
осталось старой базы данных Kerberos. Войдите в каталог /etc/kerberosIV и убедитесь, что в нем находятся только эти
файлы:
# cd /etc/kerberosIV
# ls
README krb.conf krb.realms
Если присутствуют еще какие-то файлы (такие как principal.*
или master_key), используйте команду kdb_destroy для удаления старой базы данных Kerberos, или, если
Kerberos не запущен, просто удалите эти файлы.
Затем отредактируйте файлы krb.conf и krb.realms, введя ваши данные. В этом примере уникальный
идентификатор EXAMPLE.COM, сервер grunt.example.com. Отредактируем или создадим файл 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
В этом примере другие идентификаторы введены для иллюстрации настройки c несколькими
хостами. С целью упрощения настройки вы можете не включать их.
Первая строка содержит идентификатор, под которым работает эта система. Остальные
строки связывают идентификаторы с именами хостов. Сначала указывается идентификатор,
затем хост под этим идентификатором, работающий как ``центр распространения ключей''.
Слова admin server с последующим именем хоста означают, что
этот хост также является сервером администрирования базы данных. За дальнейшей
информацией об этих терминах обратитесь к страницам справочника по Kerberos.
Мы добавили grunt.example.com к идентификатору EXAMPLE.COM и кроме того сопоставили всем хостам в домене .example.com идентификатор EXAMPLE.COM.
Файл krb.realms будет выглядеть так:
# 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
Как и в предыдущем примере, другие идентификаторы добавлены только для примера. С
целью упрощения настройки вы можете не включать их.
В первой строке определенная
система сопоставляется с идентификатором. В остальных строках показано, сопоставить
идентификатору остальные системы определенного поддомена.
Теперь мы готовы к созданию базы данных. Потребуется всего лишь запустить сервер
Kerberos (или центр распространения ключей). Используйте для этого 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.
Введите главный ключ Kerberos:
Теперь мы должны сохранить ключ, чтобы сервера на локальных компьютерах могли его
взять. Используйте для этого команду kstash:
# kstash
Enter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Этой командой зашифрованный главный пароль сохранен в /etc/kerberosIV/master_key.
Для каждой системы, защищаемой Kerberos, в базу данных должны быть добавлены две
записи. Это kpasswd и rcmd. Они
добавляются вместе с именем системы.
Эти даемоны, kpasswd и rcmd
позволяют другим системам изменять пароли Kerberos и запускать такие команды как rcp(1), rlogin(1), rsh(1).
Теперь добавим эти записи:
# 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: <---- enter RANDOM here
Verifying password
New Password: <---- enter RANDOM here
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: <---- enter RANDOM here
Verifying password
New Password: <---- enter RANDOM here
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: <---- null entry here will cause an exit
Теперь необходимо создать все записи сервисов, которые были определены для каждого
компьютера. Используем для этого команду ext_srvtab. Будет
создан файл, который должен быть скопирован или перемещен безопасным способом в каталог /etc/kerberosIV каждого Kerberos клиента. Этот файл должен
присутствовать на каждом сервере и клиенте, он необходим для работы Kerberos.
# ext_srvtab grunt
Enter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Generating 'grunt-new-srvtab'....
Эта команда создаст временный файл, который должен быть переименован в srvtab, чтобы серверы смогли обратиться к нему. Используйте команду
mv(1) для перемещения
его в исходной системе:
# mv grunt-new-srvtab srvtab
Если файл предназначен для клиентской системы, и сеть не безопасна, скопируйте client-new-srvtab на съемный
носитель и перенесите файл с его помощью. Убедитесь, что переименовали его в srvtab в каталоге /etc/kerberosIV
клиента, и что режим доступа к нему 600:
# mv grumble-new-srvtab srvtab
# chmod 600 srvtab
Теперь необходимо добавить в базу данных пользователей. Во-первых, создадим запись для
пользователя jane. Используйте команду 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: <---- enter a secure password here
Verifying password
New Password: <---- re-enter the password here
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: <---- null entry here will cause an exit
Во-первых, запустите даемоны Kerberos. При правильном редактировании файла /etc/rc.conf они запустятся автоматически при перезагрузке. Это
необходимо только на сервере Kerberos. Клиенты Kerberos получат все необходимые данные из
каталога /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!
Теперь для получения доступа через созданного пользователя jane используйте kinit:
% kinit jane
MIT Project Athena (grunt.example.com)
Kerberos Initialization for "jane"
Password:
Попробуйте просмотреть имеющиеся данные с помощью klist:
% 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
Теперь попробуйте изменить пароль с помощью passwd(1), чтобы
убедиться, что даемон kpasswd может получить информацию из
базы данных Kerberos:
% passwd
realm EXAMPLE.COM
Old password for jane:
New Password for jane:
Verifying password
New Password for jane:
Password changed.
Kerberos позволяет назначить каждому пользователю, который нуждается в привилегиях root, свой собственный пароль su(1). Необходимо
добавить учетную запись, которой разрешено получать root доступ
через su(1). Это делается
путем связывания учетной записи root с пользовательской учетной
записью. Создадим в базе данных Kerberos запись jane.root с
помощью 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: root
<Not found>, Create [y] ? y
Principal: jane, Instance: root, kdc_key_ver: 1
New Password: <---- enter a SECURE password here
Verifying password
New Password: <---- re-enter the password here
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
Max ticket lifetime (*5 minutes) [ 255 ] ? 12 <--- Keep this short!
Attributes [ 0 ] ?
Edit O.K.
Principal name: <---- null entry here will cause an exit
Теперь проверим работоспособность этой записи:
# kinit jane.root
MIT Project Athena (grunt.example.com)
Kerberos Initialization for "jane.root"
Password:
Необходимо добавить пользователя к root файлу .klogin:
# cat /root/.klogin
jane.root@EXAMPLE.COM
Теперь попробуйте выполнить su(1):
% su
Password:
и посмотрите на имеющиеся данные:
# 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
В примере выше мы создали запись (principal) jane с
доступом к root (instance). Она основана на пользователе с
таким же именем, как и идентификатор, что принято Kerberos по умолчанию; <principal>.<instance> в форме <username>.root позволяет
использовать su(1) для доступа к
root, если соответствующие записи находятся в файле .klogin домашнего каталога root:
# cat /root/.klogin
jane.root@EXAMPLE.COM
Подобно этому, если в файле .klogin из домашнего каталога
пользователя есть строки в форме:
% cat ~/.klogin
jane@EXAMPLE.COM
jack@EXAMPLE.COM
это позволит любому с идентификатором EXAMPLE.COM, кто
аутентифицировался как jane или jack
(с помощью команды kinit, см. выше) получить доступ к учетной
пользователя jane или файлам этой системы (grunt) через rlogin(1), rsh(1) или rcp(1).
Например, jane может входить в другую систему используя
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
Или jack входит в учетную запись jane's на этом же компьютере (файл .klogin jane настроен как показано выше,
и в Kerberos настроена учетная запись jack):
% 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
🔥 VPS до 5.7 ГГц под любые задачи с AntiDDoS в 7 локациях
Виртуальные VPS серверы в РФ и ЕС
