Kerberos на Ubuntu 18.04 — сервер, клиент и SSH

Схема Kerberos: KDC и клиенты

К чему это пригодится

Централизованная проверка подлинности для серверов и сервисов в сети.
Без паролей при подключении по SSH при корректной настройке GSSAPI.
Совместимость с инфраструктурами на базе MIT Kerberos и Active Directory (при дополнительной интеграции).

Важно: перед началом убедитесь, что часы на всех машинах синхронизированы (например, с помощью NTP), иначе Kerberos-тикеты будут недействительны.

Предварительные требования

Два сервера Ubuntu 18.04 с root-доступом:
- 10.10.10.15 — krb5.ahmad.io (KDC)
- 10.10.10.16 — client1.ahmad.io (клиент)
Рабочая сеть между хостами.
Базовые навыки работы в терминале.

Что мы сделаем

Настроим FQDN и /etc/hosts
Установим KDC (krb5-kdc, krb5-admin-server)
Сконфигурируем KDC: realm, admin principal, host keytab
Установим клиентские пакеты и добавим client principal
Настроим SSH для GSSAPI и протестируем вход без пароля

Шаг 1 — Настройка FQDN

На сервере KDC установите имя хоста:

hostnamectl set-hostname krb5.ahmad.io

Откройте файл ‘/etc/hosts’ и добавьте соответствующую строку (замените IP на свои при необходимости):

vim /etc/hosts

Вставьте:

10.10.10.15     krb5.ahmad.io   krb5

Сохраните и закройте. Проверьте, что FQDN разрешается корректно:

ping -c 3 $(hostname -f)

Проверка имени хоста

Совет: если у вас несколько интерфейсов, убедитесь, что в /etc/hosts прописан именно используемый IP.

Шаг 2 — Установка KDC на krb5.ahmad.io

Установите серверные пакеты Kerberos:

sudo apt install krb5-kdc krb5-admin-server krb5-config -y

В процессе установки вас попросят указать Kerberos Realm и серверы. По умолчанию Realm преобразуется в верхний регистр на основе домена (например, AHMAD.IO). В поле Kerberos server и Admin server укажите ‘krb5.ahmad.io’.

Указание realm и серверов

Если служба не запустилась автоматически — это нормально: далее мы создадим базовые записи и ключи, и затем перезапустим сервисы.

Шаг 3 — Конфигурация KDC

Создайте мастер-пароль REALM и инициализируйте базу данных:

sudo krb5_newrealm

Пароль будет сохранён в ‘/etc/krb5kdc/stash’. Это мастер-ключ KDC; храните файл доступно только для root.

Далее добавим административный principal и создадим ключи для хоста KDC. Запустите локальную панель администратора:

sudo kadmin.local

В kadmin.local выполните:

addprinc root/admin

Введите сложный пароль для root/admin.

Добавьте principal для хоста KDC и запишите его в keytab, чтобы служба могла использовать ключи без ввода пароля:

addprinc -randkey host/krb5.ahmad.io
ktadd host/krb5.ahmad.io

Затем выйдите:

quit

Создание principal и keytab

Откройте файл контроля доступа администратора и разрешите root/admin управлять принципалами:

vim /etc/krb5kdc/kadm5.acl

Добавьте строку:

root/admin *

Сохраните и перезапустите службу администратора KDC:

sudo systemctl restart krb5-admin-server.service

Перезапуск kerberos admin

Проверьте статус служб KDC и krb5-admin-server через systemctl.

Шаг 4 — Установка и настройка Kerberos-клиента на client1.ahmad.io

На клиенте настройте hostname и /etc/hosts:

hostnamectl set-hostname client1.ahmad.io
vim /etc/hosts

Добавьте обе записи:

10.10.10.15     krb5.ahmad.io   krb5
10.10.10.16     client1.ahmad.io    client1

FQDN и hosts на клиенте

Установите клиентские пакеты:

sudo apt install -y krb5-user libpam-krb5 libpam-ccreds auth-client-config

Во время установки укажите тот же Realm (AHMAD.IO), Kerberos server и Admin server — ‘krb5.ahmad.io’.

Указание сервера при установке клиента

После установки подключитесь к KDC через kadmin и добавьте principal для клиента (этот шаг можно выполнять на KDC с kadmin.local или с клиента через kadmin, если у вас есть права):

kadmin
addprinc -randkey host/client1.ahmad.io
ktadd host/client1.ahmad.io
quit

Теперь у клиента есть keytab. Проверьте, что файл keytab создан и имеет правильные права доступа.

Шаг 5 — Настройка SSH и тестирование аутентификации

Цель: позволить пользователю входить по SSH с помощью Kerberos-тикета (GSSAPI), без ввода пароля на сервере.

На KDC (krb5.ahmad.io) создайте системного пользователя и Kerberos principal пользователя:

useradd -m -s /bin/bash ammar
sudo kadmin.local
addprinc ammar
quit

Затем откройте ‘/etc/ssh/sshd_config’ и включите GSSAPI:

vim /etc/ssh/sshd_config

Найдите и измените строки:

GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

Перезапустите sshd:

sudo systemctl restart sshd

Настройка sshd для GSSAPI

На клиенте создайте такого же системного пользователя и войдите под ним:

useradd -m -s /bin/bash ammar
su - ammar

Инициализируйте Kerberos-тикет для пользователя:

kinit ammar

Введите пароль, затем проверьте тикеты:

klist

Вы должны увидеть активный Ticket Granting Ticket (TGT).

Результат klist с активным тикетом

Теперь подключитесь по SSH к серверу:

ssh krb5.ahmad.io

Если всё настроено верно, SSH использует GSSAPI для аутентификации, и пароль на сервере вводить не нужно.

Вход по SSH через Kerberos

Ниже — лог SSH на сервере (пример вывода) — сохраняйте логи при отладке.

Контрольный список для развёртывания (роль: администратор)

Синхронизация времени (NTP или chrony)
Правильно прописанные FQDN и /etc/hosts
Установлены пакеты krb5-kdc, krb5-admin-server на KDC
Сгенерирован мастер-пароль realm и ключ stash
Создан root/admin в kadmin.local и добавлен в kadm5.acl
Создан host principal и keytab для KDC
Установлены клиентские пакеты на всех клиентах
Созданы host principal и keytab для каждого клиента
SSHd настроен на GSSAPI и перезапущен
Протестированы kinit, klist и ssh без пароля

Критерии приёмки

Пользователь получает действительный TGT при kinit.
ssh с клиента на сервер проходит при включённом GSSAPI без запроса пароля.
Логи KDC не содержат ошибок при оформлении тикетов.
Файл ‘/etc/krb5kdc/stash’ доступен только root и не хранится в публичных резервных копиях.

Устранение неполадок — быстрый набор действий

Синхронизация времени: проверьте timedatectl и ntpq -p.
DNS / hosts: host $(hostname -f) и getent hosts krb5.ahmad.io.
Правильность realm: проверьте файл ‘/etc/krb5.conf’ на клиенте и сервере.
Тест получения тикета: kinit ammar → klist.
Отладка SSH: на клиенте ssh -vvv krb5.ahmad.io покажет попытки GSSAPI.
Проверьте права на keytab: обычно 600, владелец root.

Важно: многие ошибки связаны с несовпадением регистра в realm (AHMAD.IO vs ahmad.io) или с неправильным SPN (host/имя.домен).

Мини-методология развёртывания (шаги высокой уверенности)

Подготовить сеть и синхронизацию времени.
Развернуть KDC в отдельном хосте, инициализировать базу.
Добавить хосты и сервисные principals (host/, HTTP/, sshd/ если нужно).
Настроить клиентов и проверить получение TGT.
Включить GSSAPI в сервисах и проверить пользовательские сценарии.

Модель зрелости внедрения Kerberos

Уровень 0 — нет Kerberos, локальные пароли.
Уровень 1 — KDC развернут, базовые principals созданы.
Уровень 2 — клиенты интегрированы, SSH через GSSAPI работает.
Уровень 3 — автоматическое управление keytab, мониторинг и ротация ключей.
Уровень 4 — интеграция с корпоративным каталогом, SSO и аудитом.

Тестовые случаи и приёмочные критерии

TC-01: После kinit ammar команда klist возвращает валидный TGT — PASS.
TC-02: ssh с клиента на server проходит без запроса пароля при действующем тикете — PASS.
TC-03: Удаление/продление пароля principal корректно отражается в возможности аутентификации — PASS.

Быстрый сценарий отката

Отключите GSSAPI в ‘/etc/ssh/sshd_config’ и перезапустите sshd.
При необходимости восстановите старые keytab из безопасного бэкапа.
Если KDC неправильно настроен, восстановите ‘/etc/krb5kdc’ и ‘/etc/krb5kdc/stash’ из бэкапов.

Примечательности и когда способ не подойдёт

Kerberos требует точного совпадения времени и имён. В среде с динамическими IP или плохо настроенным DNS настройка может стать трудной.
Для мобильных клиентов и NAT-сценариев Kerberos может требовать дополнительных настроек.
Для единой аутентификации между разными организациями стоит рассмотреть SAML/OAuth/LDAP в дополнение к Kerberos.

Мермайд-дерево принятия решения (простое)

flowchart TD
  A[Нужен централизованный SSO?] -->|Да| B[Есть контролируемая сеть и NTP?]
  A -->|Нет| Z[Kerberos не нужен]
  B -->|Да| C[Можно развернуть KDC]
  B -->|Нет| Y[Настроить NTP и DNS сначала]
  C --> D{Критично ли SSH SSO}
  D -->|Да| E[Настроить GSSAPI на sshd]
  D -->|Нет| F[Только служебные principals]

Краткий глоссарий (1 строка)

KDC: Центр выдачи ключей (Key Distribution Center).
Realm: Административная область Kerberos, обычно домен в верхнем регистре.
principal: Уникальное имя субъекта в Kerberos (user@REALM или host/fqdn@REALM).
keytab: Файл с зашифрованными ключами principal для автоматической аутентификации.
TGT: Ticket Granting Ticket — билет, выдаваемый KDC для получения сервисных тикетов.

Частые вопросы

Как сбросить пароль principal?

Используйте kadmin.local на KDC:

sudo kadmin.local
cpw имя_principal
quit

Можно ли интегрировать Kerberos с Active Directory?

Да, Kerberos совместим на протоколе уровне. Для интеграции требуется схема доверия и синхронизация учётных записей или использование AD как KDC.

Безопасно ли хранить keytab на клиенте?

Keytab — чувствительный файл. Храните его с правами 600 и минимизируйте число системных пользователей, имеющих доступ.

Ссылки

Официальный проект Kerberos: https://web.mit.edu/kerberos/

Настройка Kerberos на Ubuntu 18.04: сервер, клиент и проверка SSH