Аутентификация пользователей на SSH-сервере с помощью Monkeysphere в Ubuntu

SSH, Ubuntu | Amber | Комментировать запись

Администрирование большого количества ключей и серверов SSH – задача не из простых, и она усложняется по мере роста вашей организации. Работа с действительными и недействительными ключами может привести к ошибкам и повлечь серьезные последствия для безопасности сервера.

Кроме того, иногда при изменении сервера пользователи могут получать предупреждения, связанные с тем, что установить подлинность сервера невозможно. Большинство пользователей не проверяют отпечаток ключа сервера перед подключением, а это потенциально  дает возможность посторонним подделать сервер и выполнить атаку  через посредника («man-in-the-middle»).

Проект под названием Monkeysphere создан для решения этих проблем. Он делает это за счет ключей GPG и доверенной сети, которые используются для проверки учетных данных сервера и упрощения управления пользователями.

В предыдущем мануале мы обсудили, как настроить Monkeysphere для проверки серверов. Мы продолжим с того места, на котором остановились в этом руководстве. Здесь мы расскажем, как автоматически проверить подлинность пользователей на серверах, основываясь только на их ключах GPG и доверии сервера к этим пользователям. Это позволяет создавать файлы аутентификации, которые используют простой язык вместо криптографических данных.

В мануале предполагается, что вы выполнили предыдущий мануал, так как здесь мы будем использовать настройку из него (server.example.com, admin.example.com, client.example.com и установленные между ними отношения).

1: Настройка сертификатора личности на сервере SSH

Первый шаг к  автоматической аутентификации пользователей на SSH-сервере – это настройка сертификатора. Это просто человек, которого вы делаете доверенным при установлении личности пользователей.

В большинстве случаев просто и логично, чтобы пользователей, которые должны иметь возможность войти в систему, идентифицировал сам администратор сервера. Так мы и сделаем. Вы также можете выбрать больше сертификаторов, если ваша ситуация требует распределения этой ответственности.

Для начала получите отпечаток вашего администратора. На его машине используйте такую команду:

gpg --with-colons --fingerprint admin@fakedomain.com

Найдите такую строку:

fpr:::::::::A61256B85307B7ED9AD8D93E9E06881E49E95F19:

Необходимая часть выделена красным.

На сервере SSH (server.example.com) добавьте этот ключ в качестве сертификатора. Вы можете сделать это так:

monkeysphere-authentication add-identity-certifier A61256B85307B7ED9AD8D93E9E06881E49E95F19

Затем Monkeysphere извлечет соответствующую информацию GPG с серверов ключей и сохранит ее в своем наборе ключей. Он пометит этот ключ как сертификатор – ключ, который может проверять личность других пользователей.

2: Генерирование подключей аутентификации для пользователей SSH

Теперь, когда администратор сервера может определить, какие пользователи являются валидными, нужно немного поработать на стороне клиента.

Каждый клиент должен сгенерировать подключ GPG, который будет использоваться для фактической аутентификации. В то время как открытый ключ GPG используется для идентификации пользователя, подключ используется для фактической процедуры входа в систему.

Команда monkeysphere предоставляет подкоманду, которая позволит вам легко создать подключ для аутентификации. На вашем клиенте введите:

monkeysphere gen-subkey

Подключ будет создан и добавлен в локальную строку GPG под главным ключом.

Теперь необходимо снова загрузить смену ключа на сервер ключей, чтобы SSH-сервер мог использовать этот подключ для создания внутренних файлов аутентификации данного пользователя. Ключ, который нужно опубликовать – это главный ключ, который содержит изменение подключа. Чтобы получить необходимую информацию, введите:

gpg --list-keys client@fakedomain.com
pub   2048R/87791BD0 2014-03-14
uid                  client <client@fakedomain.com>
sub   2048R/3294D31D 2014-03-14
sub   2048R/0FECF512 2014-03-14

Выделенная часть – это идентификатор ключа, который нужно отправить на сервер. Используйте это, чтоб отправить ключ обратно на сервер:

gpg --keyserver pool.sks-keyservers.net --send-key 87791BD0

Теперь подключ доступен на серверах ключей (возможно, его добавление займет некоторое время). Пора настроить SSH-сервер для создания файлов аутентификации, используя этот ключ.

3: Создание файлов аутентификации на сервере SSH

Теперь нужно создать реальные файлы аутентификации. Файлы аутентификации Monkeysphere делятся на две категории.

Файлы пользовательского уровня – это те, с которыми нужно взаимодействовать для установления политик аутентификации. Это простые удобочитаемые файлы, в которых просто по имени и электронной почте (как указано в GPG) указываются люди, которым разрешено входить в систему. Эти файлы находятся в специальном подкаталоге в домашнем каталоге каждого пользователя (так же, как SSH файлы authorized_keys).

Затем эти файлы Monkeysphere использует для создания файлов аутентификации, которые может понять SSH. Здесь и нужны подключи, связанные с каждым валидным пользователем. Monkeysphere генерирует файлы аутентификации для каждого пользователя в каталоге /var/lib/monkeysphere/authorized_keys.

В этом разделе мы создадим каталоги и файлы на SSH-сервере.

Перейдите в домашний каталог любого пользователя, для которого вы хотите настроить доступ. Так как ранее вам нужно было войти в систему с правами администратора, давайте настроим доступ для пользователя root. В домашнем каталоге создайте скрытый каталог .monkeysphere:

cd /root
mkdir .monkeysphere

Чтобы файл был действительным, Monkeysphere требует определенных прав доступа к  нему. В частности, требуется, чтобы ни у кого, кроме владельца файла или каталога, не было права на запись.

Давайте установим права доступа к каталогу в, а затем перейдем в него:

chmod 755 .monkeysphere
cd .monkeysphere

В этом каталоге нужно создать файл author_user_ids. Это файл аутентификации на уровне пользователя. Создайте его с помощью вашего текстового редактора:

nano authorized_user_ids

В этом файле мы просто перечислим пользователей (по имени и электронной почте – точно так же, как они находятся в GPG). Чтобы найти нужное  форматирование, можно снова ввести это на клиентском компьютере:

gpg --list-keys client@fakedomain.com
pub   2048R/87791BD0 2014-03-14
uid                  client <client@fakedomain.com>
sub   2048R/3294D31D 2014-03-14
sub   2048R/0FECF512 2014-03-14

Все, что вам нужно ввести в файл:

client <client@fakedomain.com>

Чтобы добавить других пользователей, просто введите их данные с новой строки:

client <client@fakedomain.com>
admin <admin@fakedomain.com>

Этот файл намного проще читать и редактировать, чем большие файлы author_keys. Эти файлы, как правило, устаревают, и трудно сказать, действителен ли тот или иной ключ. Если какой-либо пользователь не должен иметь доступа к машине, просто удалите его имя.

Сохраните и закройте файл, когда вы закончите.

Теперь нужно отнять право на запись у всех пользователей, кроме владельца:

chmod 644 authorized_user_ids

Повторите эту процедуру для всех пользователей, которые должны иметь удаленный доступ.

Генерация внутренних файлов аутентификации

Теперь, когда у нас есть файлы аутентификации на уровне пользователя, мы можем легко создать внутренние файлы аутентификации.

Все, что нам нужно сделать, это выполнить команду:

monkeysphere-authentication update-users

Вы должны выполнять эту команду после внесения любых изменений в файлы аутентификации на уровне пользователя.

Если вы хотите обновить только конкретного пользователя, вы можете добавить его имя в качестве аргумента:

monkeysphere-authentication update-users root

Давайте посмотрим, какие файлы были сгенерированы этой командой. Для этого нужно перейти в каталог, где они хранятся:

cd /var/lib/monkeysphere/authorized_keys

Внутри вы должны увидеть файл каждого пользователя, который имеет доступ. Одно маленькое предостережение: каждое имя в файле аутентификации на уровне пользователя должно иметь связанный подключ, доступный в открытой сети сервера ключей GPG.

ls
demouser  root

Если посмотреть на файлы, вы увидите ключ, который выглядит следующим образом:

ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQD0CdVIlUptYdZBz/0pn+7XIa2jdzy/VnayAZDXhFdHDTZU0hB8MDGHC9yjUrn9RCMj2NWD3Ls7JjqVAzmRsUn56UwyCJt8/GVmHpeIhYzmUAUjMaaMnjBG3Nhdpm9rsnJt0XVUvOu9oxrvTWYH6ZCVNwsY1O7aX/kQWnaXQW6/B6oiQJ76feZyoLEBR8D/nbxGTtNlkEMcTMTylHN0jHLACJy483SFUkSjHneNK9gNFoxTlUyF/ZBo5+Bo8Uld4iAyhaW7Di4HzfUJzvebZYX1Z1O0yS/db8anSJoZX90MLt7eIFsixuDMS3m31dsX26RI71tJGihvzF0fUsUPDg17
MonkeySphere2014-03-22T13:14:31 client <client@fakedomain.com>

Как вы можете видеть, это обычная запись authorized_keys. Мы абстрагировали ее для более простого управления пользователями и возможности динамически обновлять ключи через GPG.

В файле вы также можете увидеть дополнительные строки, которые не связаны с какой-либо записью, которую вы сделали в authorized_user_ids. Это связано с тем, что monkeysphere по умолчанию добавляет любые записи, найденные в существующих файлах authorized_keys, в конец сгенерированного файла. Это поможет в переходе между двумя системами вам и пользователям, которые по какой-либо причине не могут переключаться.

Теперь, сгенерировав новые файлы авторизации, вы должны обновить конфигурацию демона SSH, чтобы он просматривал эти файлы, а не файлы в каталоге каждого пользователя.

Откройте конфигурационный файл в вашем редакторе (убедитесь, что вы выбираете sshd_config, а не ssh_config):

nano /etc/ssh/sshd_config

В этом файле найдите и измените параметр AuthorizedKeysFile или создайте его, если он не существует. Установите такое значение:

AuthorizedKeysFile /var/lib/monkeysphere/authorized_keys/%u

Сохраните и закройте файл, когда вы закончите.

Теперь нам нужно просто перезапустить демон SSH, чтобы активировать изменения:

service ssh restart

4: Настройка аутентификации клиента по ключам GPG

Теперь сервер полностью настроен для принятия подключа GPG для аутентификации.

Нам нужно настроить аутентификацию клиента по этим ключам, а не по обычному паролю или ключу RSA. Monkeysphere делает это с помощью утилиты ssh-agent, которая используется для хранения деталей аутентификации SSH-соединений в течение продолжительных периодов времени.

Мы можем протестировать такую аутентификацию без запуска агента, используя одноразовую команду:

ssh-agent sh -c 'monkeysphere subkey-to-ssh-agent && ssh server.example.com'

После того как вы введете свой пароль от ключа GPG, вы сможете подключиться к серверу без ввода пароля учетной записи.

Теперь можно запустить агент. Вы можете сделать это в текущей оболочке, набрав:

eval $(ssh-agent)

Чтобы добавить его в автозагрузку, поместите его в файл ~/.bash_profile клиента:

echo 'eval $(ssh-agent)' >> ~/.bash_profile

В любом случае нужно добавить подраздел GPG в агент SSH, чтобы он мог использовать его для аутентификации. Сделайте это с помощью команды:

monkeysphere subkey-to-ssh-agent

Вам нужно будет ввести свой пароль ключа GPG, но это потребуется только один раз за сеанс.

Чтобы убедиться, что ключ был принят, введите:

ssh-add -l
2048 2a:1a:1d:52:32:e5:f4:45:b2:a3:ff:d0:c0:6e:69:f6 client <client@fakedomain.com> (RSA)

Теперь можно войти в систему без запроса пароля учетной записи, по подключу:

ssh server.example.com

Заключение

Благодаря Monkeysphere в вашей инфраструктуре будет надежное средство управления взаимодействием сервера и человека. Этот метод может обрабатывать добавление и удаление администраторов серверов, поскольку вся аутентификация на уровне пользователя выполняется на простом английском языке. Кроме того, вам не придется беспокоиться о том, что злоумышленники смогут подделать доступ к вашим серверам.