У пользователя A есть два закрытых ключа SSH, и со временем он использовал этот открытый ключ на нескольких серверах. Он потерял один из них и создал новую пару.
Как пользователь А сообщает мне (системному администратору), что он потерял свой ключ, и как мне управлять всеми серверами, к которым у него был доступ (у меня нет списка всех серверов, к которым у пользователя А есть доступ). Другими словами, как мне вспомнить открытый ключ, связанный с этим закрытым ключом.
При аутентификации на основе LDAP все серверы будут связываться с одним репозиторием сервера для аутентификации, и если я удалю доступ или изменю пароль на сервере, все системы, которые используют этот LDAP для аутентификации, будут защищены, когда пользователь A потеряет свой пароль.
Какую версию sshd вы используете? OpenSSH 5.4, по-видимому, имеет ключевой вариант отзыва:
* Add the ability to revoke keys in sshd(8) and ssh(1). User keys may
be revoked using a new sshd_config(5) option "RevokedKeys". Host keys
are revoked through known_hosts (details in the sshd(8) man page).
Revoked keys cannot be used for user or host authentication and will
trigger a warning if used.
Если вы используете более раннюю версию, вам, вероятно, придется просмотреть все возможные файлы authorized_keys на всех ваших серверах, чтобы найти и удалить подозрительный открытый ключ. Это будет включать любую учетную запись, в которую пользователь-A может использовать ssh, включая root. Это предполагает, что вы не используете централизованное управление authoried_key.
Одним из возможных краткосрочных решений этой ситуации является использование некоторого инструмента управления конфигурацией (анзибль здесь может быть хорошей ставкой).
Вы могли бы особенно использовать authorized_key модуль (https://docs.ansible.com/ansible/authorized_key_module.html), чтобы удалить один (или несколько) конкретных отпечатков открытого ключа из файла authorized_key данного пользователя.
Пример для ваших нужд отсутствует, но может сработать что-то вроде этого:
- name: Set authorized key took from url
authorized_key:
user: charlie
state: absent
key: https://github.com/charlie.keys
Вы также можете (по крайней мере, недоступно) запустить команду для создания списка всех пользователей в системе, запросив / etc / passwd.
Вы также можете просто создать новый белый список ключей и удалить все остальное, но это может быть непрактично в вашей ситуации.
В доступных документах приводится примерный пример того, как это может работать:
- name: Set authorized key, removing all the authorized key already set
authorized_key:
user: root
key: '{{ item }}'
state: present
exclusive: True
with_file:
- public_keys/doe-jane
В конечном итоге вы можете подумать о наличии прыжковых узлов - я обнаружил телепорт быть довольно хорошим.
И в OpenSSH, и в Putty вы можете регенерировать открытый ключ из закрытого ключа, но не наоборот.
Используйте ssh-keygen -y -f filename
В PuttyGen импортируйте ключ, и он покажет вам открытый ключ.
Если это пользовательский ключ (как кажется), то он будет расположен в authorized_keys файл для идентификаторов пользователей, к которым у пользователя был доступ. Вам нужно будет выполнить поиск в подкаталоге .ssh домашних каталогов. (Если у вас есть автоматически смонтированные домашние каталоги, вам нужно выполнить поиск в каталоге только на одном сервере; в противном случае вам нужно будет выполнить поиск на всех серверах, к которым у них мог быть доступ.)
Проблема будет в том, чтобы найти первую копию старого ключа. Домашний каталог пользователя в часто используемых системах будет хорошим местом для начала. Получив ключ, вы можете найти его в других системах и с идентификаторами пользователей. Поиск по значению ключа, а не по комментарию, с большей вероятностью найдет все ключи.
как мне вспомнить открытый ключ, связанный с этим закрытым ключом.
Хотя отзыв ключей SSH, безусловно, неплохая идея, лучшим (или более масштабируемым) решением является реализация MFA (многофакторная аутентификация, также известная как двухфакторная аутентификация). Это приводит к обесцениванию ключа, поскольку пользователь не может войти в систему, если не удовлетворяет (1) дополнительному фактору.
Существует пара решений с открытым исходным кодом, таких как Google Authenticator и Oath. Затем гибридное решение с открытым исходным кодом / коммерческое, такое как Duo. С Duo вы даже можете использовать геозоны для входа и push-уведомления.
Для 100% работающего примера реализации проверьте этот бастион, реализованный как контейнер Docker: https://github.com/cloudposse/bastion