Возможности ведения журнала SSH эквивалентны возможности ведения журнала su для аутентификации с помощью закрытого / открытого ключа?

Здесь, на работе, у нас есть общая учетная запись без полномочий root в UNIX, которая используется для администрирования конкретного приложения. Политика запрещает прямой вход в общую учетную запись; Вы должны войти под своим именем и использовать команду "su", чтобы перейти к общей учетной записи. Это для целей ведения журнала / безопасности.

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

Однако некоторые системы заблокированы, поэтому мне действительно нужно использовать команду «su» для доступа к общей учетной записи. Arg! Вернуться к вводу паролей все время!

Достаточно ли информации, зарегистрированной с аутентификацией открытого / закрытого ключа 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файл доступен для чтения / записи только для корневого пользователя, а другие файлы доступны для чтения соответствующему пользователю, например:

-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   
...