Як змусити спільні ключі .ssh / санкціоновані_кеї та судо працювати разом?


15

Я налаштував .ssh / санкціонований_кейс і можу увійти з новим "користувачем" за допомогою паб / приватного ключа ... Я також додав "користувача" до списку судорів ... проблема, яку я маю зараз, це коли Я намагаюся виконати команду sudo, щось таке, як:

$ sudo cd /root

він підкаже мені про свій пароль, який я ввожу, але він не працює (я використовую пароль приватного ключа, який я встановив)

Також я відключив пароль користувача за допомогою

$ passwd -l user

Що я пропускаю?

Десь мої початкові зауваження не зрозуміли ...

Я намагаюся посилити свою систему ... кінцевою метою є використання паб / приватних ключів для входу в систему, порівняно з простою автентифікацією пароля. Я зрозумів, як налаштувати все це через файл санкціонованих_кіїв.

Додатково я перешкоджаю входу в систему через кореневий обліковий запис. Але перед цим мені потрібно судо, щоб працювати для другого користувача (користувача, якого я весь час буду входити в систему).

Для цього другого користувача я хочу запобігти регулярним входам паролів і примушувати входити лише в паб / приватний ключ, якщо я не заблокую користувача через "passwd -l user ... зайти на сервер із звичайним паролем.

Але ще важливіше, що мені потрібно отримати sudo для роботи з налаштуванням паб / приватного ключа з користувачем, у якого був відключений пароль.


Редагувати: Гаразд, я думаю, у мене це є (рішення):

1) Я відкоригував / etc / ssh / sshd_config і встановив PasswordAuthentication no Це запобігає входу в ssh-пароль (обов'язково встановіть робочий відкритий / приватний ключ до цього

2) Я відкоригував список судерів visudoі додав

root      ALL=(ALL) ALL
dimas     ALL=(ALL) NOPASSWD: ALL

3) root - це єдиний обліковий запис користувача, у якого буде пароль, я тестую два облікові записи користувача "dimas" та "sherry", у яких не встановлено пароль (паролі порожні, passwd -d user)

Сказане по суті заважає всім входити в систему за допомогою паролів (публічний / приватний ключ повинен бути налаштований).

Крім того, користувачі зі списку судерів мають можливості адміністратора. Вони також можуть suна різні рахунки. Таким чином, "dimas" може sudo su sherry, однак "dimas НЕ МОЖЕТ робити su sherry. Аналогічно, будь-який користувач NOT у списку sudoers НЕ може робити su userабо sudo su user.

ПРИМІТКА Вищезазначене працює, але вважається поганою безпекою. Будь-який скрипт, який може отримати доступ до коду як користувачі "dimas" або "sherry", зможе виконати sudo, щоб отримати root-доступ. Помилка в ssh, яка дозволяє віддаленим користувачам входити в систему, незважаючи на налаштування, віддалене виконання коду на щось на зразок Firefox або будь-який інший недолік, який дозволяє запускати небажаний код, оскільки користувач тепер зможе запускатися як root. Судо завжди повинен вимагати пароль, або ви можете також увійти як root, а не якийсь інший користувач.

Відповіді:


10

sshі не sudoмають нічого спільного між собою. Налаштування sshметоду аутентифікації не збирається нічого робити sudo. sudoне розуміє sshпароль.

passwd -lпризначений для блокування облікового запису користувача, щоб він більше не міг підтвердити автентифікацію паролем. Це майже протилежне тому, що ви хочете, - це дозволяє користувачеві автентифікуватись без пароля.

Я думаю, що те, що ви хочете, це NOPASSWDваріант у вашому sudoersфайлі .

(PS, немає ніяких причин , щоб запустити cdкоманду з sudo. cdЧи не поширюється на батьківські процеси, так як тільки sudoвиходить, ви туди , де ви почали.)

Редагувати: Ви постійно твердите, що хочете заблокувати пароль облікового запису і хочете, щоб sudo розумів публічні / приватні ключі. Вибачте, sudo не збирається використовувати ключі ssh. Це не ssh. Якщо ви не хочете, щоб користувачі могли входити в систему за допомогою своїх паролів, я думаю, що відповідь полягає в тому, щоб вимкнути аутентифікацію пароля ssh , а не блокувати обліковий запис. Тоді ви можете зберегти пароль для користувачів, який вони можуть використовувати для sudo після входу в систему через ssh санкціоновані_кейси.


Гаразд, але чи факт, що користувач не має пароля через: passwd -l user ... викликає, що команда sudo не працює?
farinspace

@farinspace Так, я розумію це питання краще і значно розширив свої зауваження. passwd -lвилучає пароль у тому сенсі, що обліковий запис ЗАКЛЮЧЕНО - тобто жоден пароль не буде працювати. Ви хочете вимкнути автентифікацію пароля в sudo.
конусник

як ця логіка: вимкнення пароля у файлі sudoers все одно буде безпечним, оскільки система загартована через вхід у систему pub / private key ... і знову лише адміністратор зможе додати користувачів до списку sudoers
farinspace

при використанні приватного ключа типово встановити пароль, чи достатньо безпечно його просто не встановити та обійти будь-який запис пароля при вході на сервер
farinspace

4
@coneslayer ця відповідь не на 100% точна. Як ви бачите нижче, sudo може бути налаштований на дотримання аутентифікації ssh.
Андре де Міранда

18

Те, що ви хочете зробити, можливо, але це зажадає певного досвіду, оскільки вам доведеться скласти модуль PAM під назвою pam-ssh-agent-auth .

Процес досить простий:

$ sudo aptitude install libssl-dev libpam0g-dev build-essential checkinstall
$ wget "http://downloads.sourceforge.net/project/pamsshagentauth/pam_ssh_agent_auth/v0.9.3/pam_ssh_agent_auth-0.9.3.tar.bz2"
$ tar -xjvf pam_ssh_agent_auth-0.9.3.tar.bz2
$ cd pam_ssh_agent_auth-0.9.3

$ ./configure --libexecdir=/lib/security --with-mantype=man

$ make
$ sudo checkinstall

Редагування конфігурації sudo:

$ sudo visudo

Додайте наступне:

Defaults env_keep += SSH_AUTH_SOCK

Продовжуйте, змінюючи настройки sudo PAM:

$ sudo vi /etc/pam.d/sudo

Додати (трохи вище рядків @include):

**auth [success=2 default=ignore] pam_ssh_agent_auth.so file=~/.ssh/authorized_keys**
@include common-auth
@include common-account


4
Це має бути прийнята відповідь
Крістофер Монсанто

1
Ці інструкції (особливо /etc/pam.d/sudoінструкції) застаріли для поточних версій Ubuntu. Я надав оновлені інструкції у своїй відповіді.
Кріс Пік

4

Відповідь Андре де Міранди забезпечує приємне рішення, використовуючи pam_ssh_agent_auth , але частини застаріли. Особливо /etc/pam.d/sudoінструкції при використанні багатьох сучасних версій Linux.

Якщо ви працюєте з Ubuntu 12.04 точно, я фактично спростив процес, надавши побудову пам_сш_агент_аут з ppa: ppa: cpick / pam-ssh-agent-auth .

Ви можете встановити пакет, виконавши:

sudo add-apt-repository ppa:cpick/pam-ssh-agent-auth
sudo apt-get install pam-ssh-agent-auth

Після встановлення, якщо ви хочете використовувати цей модуль PAM з sudo, вам доведеться налаштувати параметри sudo та конфігурацію PAM, в Ubuntu 12.04 точно це можна зробити, створивши наступні два файли:

/etc/sudoers.d/pam-ssh-agent-auth:

Defaults    env_keep+="SSH_AUTH_SOCK"

/etc/pam.d/sudo:

ent#%PAM-1.0

auth       required   pam_env.so readenv=1 user_readenv=0
auth       required   pam_env.so readenv=1 envfile=/etc/default/locale user_readenv=0
auth       sufficient pam_ssh_agent_auth.so file=/etc/security/authorized_keys
@include common-auth
@include common-account
@include common-session-noninteractive

Якщо ви використовуєте шеф-кухаря, описаний вище процес може бути автоматизований за допомогою моєї кулінарної книги, знайденої в будь-якому з двох наступних місць:
https://github.com/cpick/pam-ssh-agent-auth
http: //community.opscode .com / кулінарні книги / pam-ssh-agent-auth .

Каталог кулінарної книги filesмістить описані вище файли /etc/pam.d/sudoта /etc/sudoers.d/pam-ssh-agent-authфайли, які точно працюють з Ubuntu 12.04 і повинні стати корисною відправною точкою при використанні інших версій / дистрибутивів.


-1

Єдиний спосіб я обійти введення пароля - це відключити його у вашому sudoersфайлі.

Щось подібне надасть rootусім учасникам wheel повний доступ без пароля:

root    ALL=(ALL)   NOPASSWD: ALL
%wheel  ALL=(ALL)   NOPASSWD: ALL

Однак це абсолютно не радиться . Якщо у вас є певна команда для виконання цього сервера, надайте їм доступ лише до цієї команди. Або ще краще, знайдіть інший спосіб виконати те, що ви хочете зробити, який не вимагає пробивання отвору в безпеці.


Я не проти використання пароля, проблема, здається, після відключення пароля користувача через: passwd -l користувач ... Я все одно можу ввійти в систему через паб / приватний ключ (приватний ключ має захищений пароль) , коли я роблю судо, він запитує пароль, але це не пароль із приватного ключа, здається, де встановити цей пароль, якщо я його відключив для користувача (я б швидше намагався уникати збереження пароля в ssystem і на приватному ключі)
farinspace

"де встановлений цей пароль, якщо я його відключив для користувача?" Ніде. Немає пароля, який можна ввести, який буде працювати, оскільки ви заблокували обліковий запис.
coneslayer

Вам доведеться знову включити обліковий запис у віддаленій системі, а потім встановити пароль. У будь-якому випадку, ви обов'язково повинні підтримувати пароль на обох машинах. Якщо з іншої причини, ніж локальні логіни, у випадку несправності.
Джек М.
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.