Вопросы Теги

ЦС пользователя SSH: Подписать сертификат пользователя с выбранными хостами, а не со всеми хостами?

Старый добрыйpaste:

printf '%.2f\n' "${qy[@]}" | paste -d'|' textfile -
 61537000|COO|DI|VMD|2018-01-08 00:00:00|133.75
 61537000|COO|DI|VMD|2018-01-09 00:00:00|197.57
 61537000|COO|DI|VMD|2018-01-10 00:00:00|211.06
 61537000|COO|DI|VMD|2018-01-11 00:00:00|195.40
 61537000|COO|DI|VMD|2018-01-12 00:00:00|155.91

(Для краткости я скопировал только первые 5 записей ).

1
06.11.2019, 07:57
2 ответа

Без изменения файла sshd_configответа вообще нет. Для этого нужно настроитьAuthorizedPrincipalsFile(илиAuthorizedPrincipalsCommand). Без этой директивы в sshd_configповедение по умолчанию заключается в том, что имя пользователя для попытки аутентификации должно быть указано буквально как один из принципалов, встроенных в сертификат. Вот почему «root» работает, а «root@server1» — нет.

Чтобы сертификат, использующий «root@server1», работал (без добавления записей в /root/.ssh/authorized_keys), вам необходимо настроить AuthorizedPrincipalsFileдля пользователя root (более поздние версии OpenSSH разрешают эту директиву внутри блок Match)и список «root@server1» и сделайте что-то подобное на других серверах. Вы также можете расширить это, чтобы разрешить сертификаты, применимые к группам серверов, таким как «root@dev» или даже «root@ *», если каждый соответствующий вариант указан как принципал в AuthorizedPrincipalsFile.

Другой способ реализовать это — явно перечислить ключ ЦС и разрешенных принципалов в файле .ssh/authorized_keys,используя обе опции cert-authorityи principals=. Они описаны в справочной странице sshdформата файла авторизованных ключей _.

2
27.01.2020, 23:57

Проблема заключается в том, что при выпуске ssh-сертификата вы напрямую ставите rootв Principalsвы предоставите доступ ко всем серверам, которые доверяют вашему ЦС.

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

  • project-dev-Доступ к серверам разработки/тестирования
  • project-databases-Доступ к серверам баз данных
  • project-super-Доступ ко всем серверам

Для этого добавьте AuthorizedPrincipalsFile /etc/ssh/auth_principals/%uв файл sshd_config.

Таким образом, когда кто-то пытается войти на сервер с именем пользователя root, он проверяет файл /etc/ssh/auth_principals/root(, уведомление %uозначает пользователя ).

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

Авторизованный файл принципов для этого сценария будет

  • Серверы разработки-project-dev\nproject-super
  • Серверы баз данных-project-dev\nproject-super
  • Производственные серверы-project-super

Итак, создайте стратегию в соответствии с вашими потребностями.

Примечание. :Если вы по-прежнему выпускаете сертификат с rootв Principles, он все равно будет работать. Так что избегайте этого.

Я написал блог, чтобы настроить полную инфраструктуру сертификатов ssh:

https://medium.com/better-programming/how-to-use-ssh-certificates-for-scalable-secure-and-more-transparent-server-access-720a87af6617

1
17.04.2020, 16:51

Теги

Похожие вопросы