Здесь, на работе, у нас есть общая учетная запись без полномочий root в UNIX, которая используется для администрирования определенного приложения. Политика запрещает прямой вход в общую учетную запись; вы должны войти в систему как вы и использовать команду «su» для перехода на общую учетную запись. Это сделано для регистрации / безопасности.
Я начал использовать SSH-аутентификацию с открытым / закрытым ключом с агентом, чтобы позволить мне вводить свой пароль один раз в день и позволить агенту пересылать запросы на ввод пароля до конца дня. Это действительно хорошо.
Однако некоторые системы заблокированы, поэтому мне действительно нужно использовать команду «su», чтобы получить доступ к общей учетной записи. Арг! Вернемся к постоянному вводу паролей!
Достаточно ли информации, зарегистрированной с помощью аутентификации с открытым / закрытым ключом SSH, чтобы я имел разумные шансы запросить изменение политики, чтобы разрешить удаленный вход в общую учетную запись, если используются открытые / закрытые ключи?
У меня был администратор, который заглянул в / var / log / secure, и он просто сказал, что открытый ключ был принят для учетной записи пользователя с определенного IP-адреса. Он не сказал, чей это был открытый ключ или чей закрытый ключ выполнял аутентификацию.
Есть много уровней ведения журнала, доступных через sshd_config файл. Увидеть страница руководства и ищи LogLevel. Уровень по умолчанию INFO но это банально легко поднять до VERBOSE или даже один из DEBUG# уровни.
Кроме того, вам следует изучить sudo как альтернатива su. Полное обсуждение преимуществ sudo это будет отдельный вопрос. Но я могу сказать это с помощью sudo вы можете настроить, как часто вам нужно вводить пароль, какие команды можно запускать и т. д., все это можно контролировать через sudoers файл конфигурации.
Другой способ - переехать authorized_keys вне области действия пользователя (например, чтобы /etc/ssh/authorized_keys), чтобы только системные администраторы могли контролировать, какие открытые ключи могут использоваться для входа в указанные учетные записи.
Раньше мы меняли AuthorizedKeysFile директива в sshd_config примерно к следующему.
AuthorizedKeysFile /etc/ssh/authorized_keys/%u
Затем создайте и заполните /etc/ssh/authorized_keys каталог с файлами для каждого пользователя, который должен иметь возможность войти, убедившись, что root файл доступен для чтения / записи только пользователю root, а другие файлы доступны для чтения соответствующему пользователю, например:
-rw------- 1 root root 1,7K 2008-05-14 14:38 root
-rw-r----- 1 root john 224 2008-11-18 13:15 john
Каждый файл содержит набор открытых ключей, которым будет разрешен вход в данную учетную запись. Довольно часто для каждой учетной записи пользователя есть соответствующая группа.
Использование открытых / закрытых ключей - лучший метод управления доступом удаленных пользователей. Вам не нужно менять пароль каждый месяц (вам также не нужно его устанавливать), и вам не нужно менять его только потому, что сотрудник покинул вашу компанию, просто удалите свой открытый ключ; и, конечно же, с параметрами SSH (http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8#SSHRC) вы можете уточнить, что и откуда у данного пользователя может быть доступ.
Аутентификация открытого / закрытого ключа SSH отличается от аутентификации хоста. Тебе здесь не повезло. Вы можете запросить, чтобы членам определенной группы было разрешено запускать определенные административные команды через sudo без пароля - как в примере ниже, пользователи secretaries группа для управления счетами:
# file: /etc/sudoers
...
%secretaries ALL= NOPASSWD: /usr/bin/adduser, /usr/bin/rmuser
...