Чи можливості ведення журналу SSH еквівалентні су-реєстрації для аутентифікації приватного / відкритого ключа?

Тут на роботі у нас є UNIX-аккаунт для спільного входу в 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), щоб лише sysadmins контролював, які відкриті ключі можуть використовуватися для входу в дані облікові записи.

Ми раніше змінювали 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   
...