Linux postgresql задать пароль

Sysadminium

База знаний системного администратора

Методы аутентификации в PostgreSQL

Рассмотрим процесс подключения к базам данных, методы подключения и аутентификации в PostgreSQL, а также сопоставление пользователей ОС и ролей БД.

Процесс подключения

Процесс подключение можно разделить на три этапа:

• Идентификация – определение имени роли базы данных.
• Аутентификация – проверка того, что пользователь тот за кого себя выдаёт. Есть много разных методов аутентификации, например проверка пароля.
• Авторизация – проверка прав этого пользователя. Например может ли этот пользователь подключаться к этой базе данных или нет.

Настройки по умолчанию используется метод аутентификации trast, который позволяет подключаться без аутентификации любым локальным пользователям.

Метод аутентификации trast (alex@deb:

$ psql -U postgres)

Основные настройки

Конфигурационный файл отвечающий за настройки аутентификации – pg_hba.conf. Он находится в каталоге PGDATA:

Его местоположение можно изменить задав параметр hba_file в конфигурационном файле postgresql.conf:

При изменении этого файла конфигурацию сервера нужно перечитать, выполнив:

• pg_ctl reload – из операционной системы;
• SELECT pg_reload_conf(); – если вы подключены к СУБД.

Если вы подключены к СУБД, то узнать местоположение файла можно таким способом:

Файл pg_hba.conf состоит из строк, а строки состоят из следующих полей:

• тип подключения;
• имя БД;
• имя пользователя;
• адрес узла;
• метод аутентификации;
• необязательные дополнительные параметры в виде имя=значение. Эти параметры нужны некоторым методам аутентификации.

Эти строки обрабатываются сверху вниз и применяется первая найденная строка. Таким образом если тип подключения, имя БД, имя пользователя и адрес сервера совпали, то применяется определённый метод аутентификации.

pg_hba – если-то

При подключении выполняется аутентификация и проверяется привилегия CONNECT. Если результат отрицательный, доступ запрещается и строки ниже не рассматриваются. Если ни одна запись не подошла, доступ запрещается. Таким образом записи должны идти сверху вниз от частного к общему.

Вот пример файла pg_hba.conf, который создаётся при сборке из исходников:

Первая строчка это тип подключения local, в котором используется локальный unix сокет, и не задействована сеть. При таком подключении все пользователи (all) могут подключаться методом trust. О методах поговорим позже.

Третья и четвёртая строки относятся к tcp подключениям (host). При таком подключении все пользователи могут подключаться только из локального хоста (127.0.0.1/32 или ::1/128) используя метод trust.

Последние три строки относятся к репликации. Репликация возможна по сокету (local) и по сети (host) но только с локального хоста (127.0.0.1/32 или ::1/128). Здесь тоже используется метод trust.

Если вы подключены к СУБД, то сможете посмотреть содержимое файла pg_hba.conf с помощью представления pg_hba_file_rules:

Если в строке допущена ошибка, то это представление в поле error покажет ошибку.

Параметры подключения

Теперь рассмотрим параметры подключений!

Типы подключений:

• local – использует unix сокет;
• host – использует TCP/IP, оно может быть шифрованным с помощью SSL или не шифрованным;
• hostssl – только зашифрованный TCP/IP;
• hostnossl – только не зашифрованный TCP/IP.

Имя базы данных:

• all – подключение к любой БД;
• sameuser – БД, совпадающая по имени с ролью;
• samerole – БД, совпадающая по имени с ролью или группой, в которую она входит;
• replication – специальное разрешение для протокола репликации;
• имя базы данных – имя конкретной базы данных, или через запятую можно перечислить список баз данных.

Адрес узла:

• all – любой IP-адрес;
• ip-адресс – конкретный ip адрес, подсеть, или диапазон (172.20.143.0/24 или 172.20.143.0 255.255.255.0)
• samehost – означает адрес сервера с которого ведётся подключение, аналог 127.0.0.1;
• samenet – означает любой ip адрес из подсети сервера;
• доменное имя (или часть доменного имени, начиная с точки) – при этом postgresql проверяет ip-адрес подключающегося клиента на принадлежность к этому домену.

Имя роли:

• all – любая роль;
• – роль с указанным именем, при этом можно перечислить роли через запятую;
• + – групповая роль, в которую включены другие роли.

Тип аутентификации:

• Аутентификация без проверок:
  • trust – разрешает подключение без аутентификации, то есть без проверки пароля или любых других проверок;
  • reject – запрещает подключение ничего не проверяя;
• Аутентификация по паролю:
  • md5 – пароль хранится в СУБД и шифруется MD5;
  • scram-sha-256 – пароль хранится в СУБД, используется протокол SCRAM (более надёжно);
  • ldap [параметры] – пароль хранится на сервере LDAP;
  • radius [параметры] – пароль хранится на сервере RADIUS;
  • pam [параметры] – пароль хранится в подключаемом модуле PAM;
• Внешняя аутентификация:
  • peer [map=…] – запрашивает имя пользователя у операционной системы (только для Linux и только для локальных подключений);
  • cert [map=…] – аутентификация с использованием клиентского SSL-сертификата;
  • gss [map=…] – аутентификация Kerberos по протоколу GSSAPI;
  • sspi [map=…] – аутентификация Kerberos/NTLM для Windows.

Пароль в СУБД

Пароль хранится в СУБД в зашифрованном виде при использовании методов аутентификации md5 и scram-sha-256.

Задать пароль роли при её создании можно так:

Создать пароль для уже существующей роли можно так:

Пользователю с пустым паролем будет отказано в доступе при аутентификации по паролю.

Пароли в зашифрованном виде хранятся в системном каталоге, в таблице pg_authid.

При аутентификации пароль можно вводить вручную, но не всегда это удобно. Еще можно установить переменную $PGPASSWORD на клиенте, в неё нужно задать пароль, тогда утилита psql будет использовать пароль из этой переменной. Но это не очень удобно и не безопасно.

Также можно создать файл

/.pgpass. Там можно прописать разные пароли к разным серверам следующим образом:

Такой файл должен иметь права 600 (rw- — —). Строки в нем просматриваются сверху вниз и используется первая найденная строка.

Сопоставление имен

Когда вы используете метод аутентификации peer, cert, gss или sspi вам нужно сопоставить имя пользователя в ОС и имя роли в СУБД. Это делается с помощью конфигурационного файла pg_ident.conf. Этот файл также состоит из строчек, строчки состоят из полей.

Поля в этом файле такие:

• Название соответствия – оно затем прописывается в параметре map в файле pg_hba.conf;
• Внешнее имя, или регулярное выражение;
• Внутреннее имя роли базы данных.

В примере выше записано следующие настройки:

• Если идет шифрованное соединение, то разрешается подключаться к одноименной базе с именем пользователя. При этом используется метод аутентификации по сертификату с сопоставлением имен m1. Это сопоставление вытаскивает имя из сертификата и если оно соответствует регулярному выражению /^(.*)@domain.com$, то первая часть имени (до @domain.com) будет именем роли.
• Если идет локальное соединение по сокету, то разрешается подключаться всем с помощью метода идентификации peer. При этом используется сопоставление имён m2. Таких сопоставлений (m2) две строчки, это означает что пользователь ОС student может подключиться только под ролью alice или bob.
• Если идет подключение по сети, но с адреса сервера (samehost), то используется метод аутентификации md5 (по паролю).

Подробнее про аутентификацию можете почитать тут.

Источник

Пароль пользователя postgres — как задать и изменить пароль

Команды по администрированию базами и пользователями выполняются от имени системного пользователя postgres

root может стать им выполнив su — postgres

Затем можно без пароля попасть в интерфейс БД psql

Или то же самое одной командой

Пользователь может создать базу

Затем добавить пользователя и задать для него пароль

=# create user appadmin with encrypted password ‘jdfh8jhtghnjkfrvhyu’;

После этого пользователю нужно дать права для работы с базой данных

=# grant all privileges on db1 mydb to appadmin;

Изменить пароль пользователя Postgres

Пользователя можно создавать и задавать ему пароль двумя раздельными командами

sudo -u postgres createuser anotheruser

Вторая служит для изменения паролей уже существующих пользователей, выполняется из консоли psql

=# alter user anotheruser with encrypted password ‘NEW_STRONG_PASSWORD’;

Непосредственно для системного пользователя postgres пароль не нужен, им может стать root выполнив su как показано ранее. Если нужна авторизация root может установить для postgres новый пароль

Затем пароль нужно ввести дважды, отображаться он не будет.

Пользователь appadmin — не системный, он существует только в postgresql.

Подключаться к базе из консоли от имени этого пользователя нужно указывая имя базы и ключ -W

psql -h myhost -d db1 -U appadmin -W

Последний ключ не обязателен, но без него в интерактивном режиме в некоторых версиях СУБД не будет запрашиваться пароль, пароль должен запрашиваться.

Про создание дампов баз данных Postgres и их загрузку.

Источник

Как работать с пользователями в PostgreSQL

Часть нижеописанных операций нужно выполнять в командной оболочке PostgreSQL. Она может быть запущена от пользователя postgres — чтобы войти в систему от данного пользователя, вводим:

* если система выдаст ошибку, связанную с нехваткой прав, сначала повышаем привилегии командой sudo su или su.

Теперь запускаем командную оболочку PostgreSQL:

$ psql -Upostgres template1

* в данном примере, вход выполняется от учетной записи postgres к шаблонной базе template1.

Для просмотра всех пользователей СУБД:

=# select * from pg_user;

Создание нового пользователя

Для того, чтобы была возможность подключения к СУБД PostgreSQL от нового пользователя, необходимо создать данного пользователя, назначить ему права, выполнить настройку файла pg_hba.conf.

1. Создание пользователя

а) Добавление новой роли (пользователя) из оболочки SQL:

=# CREATE USER dmosk WITH PASSWORD ‘myPassword’;

* в примере создана роль dmosk с паролем myPassword.

б) Добавление новой роли (пользователя) из командной строки Linux:

createuser -P dmosk

2. Назначение прав на использование базы данных

Даем права на базу командой:

=# GRANT ALL PRIVILEGES ON DATABASE «database1» to dmosk;

Теперь подключаемся к базе, к которой хотим дать доступ:

* в примере подсоединимся к базе с названием database1.

а) Так мы добавим все права на использование всех таблиц в базе database1 учетной записи dmosk:

database1=# GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO «dmosk»;

* в большинстве случаев, используется схема по умолчанию public. Но администратор может создать новую схему. Это нужно учитывать при назначении прав.

б) Также можно дать доступ к базе для определенных таблиц:

database1=# GRANT ALL PRIVILEGES ON TABLE table1 IN SCHEMA public TO «dmosk»;

* в данном примере мы даем права на таблицу table1.

Выходим из SQL-оболочки:

3. Настройка файла pg_hba.conf

Для возможности подключиться к СУБД от созданного пользователя, необходимо проверить настройки прав в конфигурационном файле pg_hba.conf.

Для начала смотрим путь расположения данных для PostgreSQL:

В ответ мы получим, что-то на подобие:

* в данном примере /var/lib/pgsql/9.6/data/ — путь расположения конфигурационных файлов.

Добавляем права на подключение нашему созданному пользователю:

.
# IPv4 local connections:
host all dmosk 127.0.0.1/32 md5
.

* в данном примере мы разрешили подключаться пользователю dmosk ко всем базам на сервере (all) от узла 127.0.0.1 (localhost) с требованием пароля (md5).
* необходимо, чтобы данная строка была выше строки, которая прописана по умолчанию
host all all 127.0.0.1/32 ident.

После перезапускаем службу:

systemctl restart postgresql-9.6

* в данном примере установлен postgresql версии 9.6, для разных версий на разных операционных системах команды для перезапуска сервиса могут быть разные.

4. Проверка

Для теста пробуем подключиться к Postgre с помощью созданного пользователя:

psql -Udmosk template1 -h127.0.0.1

Настройка прав доступа к базе с помощью групп

Сначала создадим групповую роль:

=# CREATE ROLE «myRole» NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION;

* данной командой создана группа myRole с минимальными правами.

Теперь добавим ранее созданного пользователя dmosk в эту группу:

=# GRANT «myRole» TO dmosk;

Подключимся к базе данных, для которой хотим настроить права

и предоставим все права для группы myRole всем таблицам базы database1

database1=# GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO GROUP «myRole»;

Редактирование пользователя

1. Смена пароля

Рассмотрим несколько примеров смены пароля пользователя.

=# ALTER USER postgres PASSWORD ‘password’

* в данном примере мы зададим пароль password для пользователя postgres.

С запросов ввода пароля:

* после ввода данной команды система потребует дважды ввести пароль для пользователя (в нашем примере, postgres).

Из командной строки Linux:

sudo -u postgres psql -U postgres -d postgres -c «ALTER USER postgres PASSWORD ‘password'»

* по сути, мы выполняем также запрос в оболочке sql.

Удаление пользователей и групп

Удаление пользователя выполняется следующей командой:

=# DROP USER dmosk;

database1=# REVOKE ALL PRIVILEGES ON ALL TABLES IN SCHEMA public FROM «dmosk»;

* обратите внимание, данный запрос отличается от предоставления прав двумя моментами: 1) вместо GRANT пишем REVOKE; 2) вместо TO «dmosk» пишем FROM «dmosk»;

Назначение особых прав пользователям PostgreSQL

Помимо ALL PRIVILEGES можно выдавать права на особые операции, например:

=# GRANT SELECT, UPDATE, INSERT ON ALL TABLES IN SCHEMA public TO «dmosk»;

* команда позволит выдать права на получение данных, их обновление и добавление. Другие операции, например, удаление будут запрещены для пользователя dmosk.

Назначение прав для определенной таблицы:

database1=# GRANT ALL PRIVILEGES ON table_users TO «dmosk»;

* в данном примере мы предоставим все права на таблицу table_users в базе данных database1;

Учетная запись для резервного копирования

Для выполнения резервного копирования лучше всего подключаться к базе с минимальными привилегиями.

Сначала создаем роль, которую будем использовать для выполнения резервного копирования:

=# CREATE USER bkpuser WITH PASSWORD ‘bkppasswd’;

* мы создадим учетную запись bkpuser с паролем bkppasswd.

Предоставляем права на подключения к базе

=# GRANT CONNECT ON DATABASE database TO bkpuser;

* в данном примере к базе database.

Подключаемся к базе (в нашем примере database):

Даем права на все последовательности в схеме:

=# GRANT SELECT ON ALL SEQUENCES IN SCHEMA public TO bkpuser;

* мы дали права для схемы public. Это схема является схемой по умолчанию, но в вашем случае она может быть другой. В таком случае, подставляем свое значение.

Графический интерфейс

Иногда проще воспользоваться программой для выставления прав и работы с PostgreSQL. Могу посоветовать приложение pgAdmin. Оно позволит в оконном режиме не только создать и удалить пользователей, но и полноценно работать с СУБД.

Источник