Сборка пакета PAM-SQLite и NSS-SQLite

Как многим известно, аутентификация в Linux проходит централизованно в PAM. Стандартно PAM использует файлы /etc/passwd (и еще несколько: shadow, group,  и т.д.). В крупных компаниях предпочитают держать пользователей не в файлах, а в LDAP. Но если Вы пишете свое приложение, то наверняка хотите хранить пользователей в базе. Для MySQL и PostgreSQL в репозиториях Debian есть стандартные пакеты libpam-mysql и libpam-pgsql. Но что делать, если пользователи живут в SQlite? Об этом ниже, а пока небольшая вводная, важная к прочтению:

Подразумевается, что читатель знает разницу между аутентификацией и авторизацией.

Процесс происходит примерно так (рассмотрим на примере SSH). Демон SSH принимает соединение с логином и паролем.
Теперь перед SSH-демоном две задачи:
1) Identity. Установить, что пользователь вообще существует.
(это делается на первом слое: NSS)
2) Authnetication. Проверить его пароль.
(это делается на втором слое: PAM, если конечно в /etc/ssh/sshd_config стоит настройка "UsePAM yes" ).

Далее, через систему NSS он смотрит настройки. Находятся они в файле /etc/nsswitch.conf. По дефолту там стоит так:

passwd:         compat

group:           compat

shadow:        compat

compat - значит локальные файл (/etc/passwd,/etc/shadow,/etc/group)
Можно добавить своё, например:

passwd:         compat   ldap   sqlite

group:           compat   ldap   sqlite

shadow:        compat   ldap   sqlite

В таком случае система сначала будет искать пользователя в файлах, если нет, то в LDAP и наконец в SQLite.

Поэтому кроме пакета libpam-sqlite вам понадобится еще пакет libnss-sqlite, чтобы NSS вообще понимал такую инструкцию как "sqlite".

====
Теперь разберемся откуда брать код.
Поиск кода обоих приложений (libnss-sqlite и libpam-sqlite) приводит на аккаунт github Sectoid. Но ведет его достаточно вяло. libpam-sqlite остановился на версии 0.3. Эта версия поддерживает SQLite2, а вот SQLite3 - нет.
Версию 0.3 уже, в свою очередь форкнул ip1981 и добавил в неё поддержку SQLite3, назвав ее версией 0.4.
Но я внезапно нашел вот уже версию 1.0.1 (с поддержкой SQLite3).



Нам понадобятся пакеты:

apt-get install libpam0g-dev libmhash-dev libsqlite0-dev

И инструменты сборки:

apt-get install dh-make dpatch devscripts autoconf  shtool libtool

Переходим в директорию, где будем работать:

cd /usr/src

Скачиваем исходники с сайта:

git clone https://github.com/dtjm/pam_sqlite3.git libpam-sqlite-1.0.1

Логин в RHEL/CentOS/OEL под рутом с RSA-ключом

RHEL-like операционные системы, в отличии от Debian, очень сильно защищены. Сразу после инсталляции Вы получите полный набор заборов в виде SElinux, iptables и прочих. Привыкшему человеку это нормально (оно как бы даже спокойнее), а вот новичка такое состояние приведет к эйфории эфтаназии.
Особо "грамотные" советуют выключить все это. Но я бы им по губам бил за такие советы. Умные дяденьки не для того нас оберегали от безопасности, чтобы мы ей пренебрегали. Подобные вопросы надо решать только по-спортивному.

Одна из таких засад: невозможность залогиниться под рутом с ключом.

Причин две.
1) В RHEL-вском SSH по умолчанию стоит StrictModes yes. Это значит, что мы должны создавать директории и файлы SSH с нормальными правами, а не как рубахи-парни.

mkdir /root/.ssh
chmod 700 /root/.ssh

и

touch /root/.ssh/authorized_keys
chmod 600 /root/.ssh/authorized_keys

2) Но и после этого законнектиться ключем будет невозможно. В этот раз вредит SElinux.
Чинится так:

restorecon -R -v /root/.ssh