Параметры подключения
Теперь рассмотрим параметры подключений!
Типы подключений:
- 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 – запрашивает имя пользователя у операционной системы (только для Linux и только для локальных подключений);
- cert – аутентификация с использованием клиентского SSL-сертификата;
- gss – аутентификация Kerberos по протоколу GSSAPI;
- sspi – аутентификация Kerberos/NTLM для Windows.
Аутентификация unix_socket в MySQL и MariaDB
Суть аутентификации по unix_socket в том, что если пользователь уже выполнил вход в систему, то ему не нужно вводить пароль при подключении к СУБД, поскольку его подлинность уже была проверена при входе в ОС.
На практике, большинство работает под обычным пользователем, а подключается к MySQL как root. В результате возникает обозначенная выше ошибка.
Можно выбрать один из вариантов:
1. Всегда использовать sudo при подключении как root.
2. Внести изменения в настройки MySQL, чтобы к СУБД могли подключаться и обычные пользователи.
3. Создать пользователя MySQL с таким же именем, как имя вашего системного пользователя
Настройка ротации паролей
Данная настройка позволит автоматически по таймеру менять пароли в СУБД PostgreSQL для определенных учетных записей.
На стороне хранилища паролей необходимо:
- Создать роль, которая будет менять пароль в базе данных.
- Проверить настройки, создав новый пароль и подключившись к базе данных.
Переходим к настройке.
Создаем роль для смены пароля
Настройка задается с помощью static-roles. В нашем Vault вводим команду:
vault write database/static-roles/postgresql-rotate \
db_name=postgresql \
rotation_statements=»ALTER USER \»`name`\» WITH PASSWORD ‘`password`’;» \
username=»dmosk» \
rotation_period=720h
* обратите внимание, что запрос rotation_statements важно написать именно так — первая кавычка двойная, вторая одинарная. ** в данном примере:
** в данном примере:
- Мы создадим роль с названием postgresql-rotate (с тем названием, которое мы использовали в allowed_roles, когда создавали конфигурацию).
- Опция db_name должна называться как настройка, которую мы создали на предыдущем шаге (database/config/postgresql).
- Наша роль будет выполнять команду rotation_statements (менять пароль для пользователя).
- Каждые 720 часов (30 дней) пароль будет меняться автоматически.
Мы должны увидеть что-то на подобие:
Success! Data written to: database/static-roles/postgresql-rotate
Готово.
Меняем пароль и проверяем доступ
Давайте посмотрим текущий пароль:
vault read database/static-creds/postgresql-rotate
Мы получим что-то на подобие:
Key Value
— ——
last_vault_rotation 2021-09-07T11:35:07.796668266+03:00
password Cai-dzsJDtKTLHSl6Bvt
rotation_period 720h
ttl 719h48m55s
username dmosk
Где Cai-dzsJDtKTLHSl6Bvt — наш пароль от учетной записи dmosk.
Перейдем на сервер с PostgreSQL и попробуем войти в СУБД с использованием этих данных:
psql -Udmosk -W template1
Мы должны подключиться с использованием пароля, который получили от Vault.
Выходной#
Так, наконец, команда нашего альтер пользователя будет выглядеть psql в Изменить имя пользователя с паролем ‘md5d6a35858d61d85e4a82ab1fb044aba9d’;
Полезные ссылки (обратите внимание, я только ссылки на последние версии документов для пожилых он изменяет некоторые но MD5-это по-прежнему поддерживают некоторое время назад.)
пароль всегда хранится в зашифрованном виде в системных каталогах. Зашифрованные сайта не имеет никакого эффекта, но принимается для обеспечения обратной совместимости. Метод шифрования определяется конфигурацией password_encryption параметра. Если строка пароль уже в MD5 зашифрован или катись-зашифрованном виде, то оно хранится как есть, независимо от password_encryption (поскольку система не может расшифровать указанный зашифрованную строку пароля, шифровать его в другой формат). Это позволяет перезаряжать зашифрованные пароли во время сброса/восстановления.
Основные настройки
Конфигурационный файл отвечающий за настройки аутентификации – pg_hba.conf. Он находится в каталоге PGDATA:
postgres@s-pg13:~$ ls -l $PGDATA/pg_hba.conf -rw------- 1 postgres postgres 4760 июн 21 15:15 /usr/local/pgsql/data/pg_hba.conf
Его местоположение можно изменить задав параметр hba_file в конфигурационном файле postgresql.conf:
postgres@s-pg13:~$ cat $PGDATA/postgresql.conf | grep hba #hba_file = 'ConfigDir/pg_hba.conf' # host-based authentication file
При изменении этого файла конфигурацию сервера нужно перечитать, выполнив:
- – из операционной системы;
- – если вы подключены к СУБД.
Если вы подключены к СУБД, то узнать местоположение файла можно таким способом:
postgres@s-pg13:~$ psql
Timing is on.
psql (13.3)
Type "help" for help.
postgres@postgres=# SHOW hba_file;
hba_file
-----------------------------------
/usr/local/pgsql/data/pg_hba.conf
(1 row)
Time: 0,740 ms
Файл pg_hba.conf состоит из строк, а строки состоят из следующих полей:
- тип подключения;
- имя БД;
- имя пользователя;
- адрес узла;
- метод аутентификации;
- необязательные дополнительные параметры в виде имя=значение. Эти параметры нужны некоторым методам аутентификации.
Эти строки обрабатываются сверху вниз и применяется первая найденная строка. Таким образом если тип подключения, имя БД, имя пользователя и адрес сервера совпали, то применяется определённый метод аутентификации.
pg_hba – если-то
При подключении выполняется аутентификация и проверяется привилегия CONNECT. Если результат отрицательный, доступ запрещается и строки ниже не рассматриваются. Если ни одна запись не подошла, доступ запрещается. Таким образом записи должны идти сверху вниз от частного к общему.
Вот пример файла pg_hba.conf, который создаётся при сборке из исходников:
# TYPE DATABASE USER ADDRESS METHOD local all all trust host all all 127.0.0.1/32 trust host all all ::1/128 trust local replication all trust host replication all 127.0.0.1/32 trust host replication all ::1/128 trust
Первая строчка это тип подключения 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:
postgres@postgres=# SELECT * FROM pg_hba_file_rules;
line_number | type | database | user_name | address | netmask | auth_method | options | error
-------------+-------+---------------+-----------+-----------+-----------------------------------------+-------------+---------+-------
88 | local | {all} | {all} | | | trust | |
90 | host | {all} | {all} | 127.0.0.1 | 255.255.255.255 | trust | |
92 | host | {all} | {all} | ::1 | ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff | trust | |
95 | local | {replication} | {all} | | | trust | |
96 | host | {replication} | {all} | 127.0.0.1 | 255.255.255.255 | trust | |
97 | host | {replication} | {all} | ::1 | ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff | trust | |
(6 rows)
Time: 2,006 ms
Если в строке допущена ошибка, то это представление в поле error покажет ошибку.
2: Перезапуск сервера базы данных без проверки прав доступа
Режим MySQL и MariaDB без проверки привилегий позволяет получить доступ к командной строке БД с правами root, не предоставляя действительного пароля. Чтобы включить этот режим, необходимо запретить базе данных загружать таблицы привилегий, в которых хранится информация о доступе пользователей. Поскольку такой режим представляет некоторую угрозу безопасности, рекомендуем также отключить сеть, чтобы другие клиенты не смогли подключиться к временно уязвимому серверу.
Процедура запуска сервера без загрузки таблиц привилегий в MariaDB и MySQL различается.
Запуск MariaDB без таблиц привилегий
Чтобы запустить сервер MariaDB без таблиц привилегий, мы воспользуемся юнит-файлом systemd – в нем нужно установить дополнительные параметры для демона сервера MariaDB.
Выполните следующую команду, которая устанавливает переменную среды MYSQLD_OPTS, которую MariaDB использует при запуске. Параметры –skip-grant-tables и –skip-networking запустят MariaDB без загрузки таблиц привилегий или сетевых функций.
![Как восстановить доступ к debian linux в случае проблем с sudo или утратой root-пароля [вики it-kb]](https://fuzeservers.ru/wp-content/uploads/4/b/b/4bbf8e03b4e03b43261d030f8105bdbd.png)
Затем запустите сервер MariaDB:
Эта команда не выведет на экран никаких результатов, но перезапустит сервер базы данных с учетом новых настроек.
Вы можете убедиться, что сервер запущен с помощью команды:
Теперь вы сможете подключиться к базе данных как root пользователь MariaDB без пароля:
На экране сразу появится командная оболочка базы данных.
Теперь, когда у вас есть доступ к серверу базы данных MariaDB, вы можете изменить пароль root – перейдите к разделу 3.
Запуск MySQL без таблиц привилегий
Чтобы запустить сервер MySQL без таблиц привилегий, нужно изменить конфигурацию systemd для MySQL: при запуске сервер должен передавать дополнительные параметры командной строки.
Для этого выполните следующую команду:
Эта команда откроет в редакторе nano новый файл, который вы будете использовать для редактирования переопределений сервиса MySQL. Они изменяют стандартные параметры MySQL.
Этот файл сейчас пуст. Добавьте в него следующие строки:
Первый оператор ExecStart сбрасывает значение по умолчанию, а второй предоставляет systemd новую команду для запуска сервиса – она содержит параметры, которые отключат загрузку таблиц привилегий и сетевые соединения.
Нажмите Ctrl-x, чтобы выйти из файла, затем y, чтобы сохранить внесенные изменения. Чтобы подтвердить имя файла, нажмите ввод.
Перезагрузите конфигурацию systemd, после чего эти изменения вступят в силу:
Теперь запустите сервер MySQL:
Команда не покажет на экране никаких данных, но сервер БД запустится. Таблицы привилегий и сетевые соединения буду отключены.
Подключитесь к базе данных как пользователь root:
Вы попадете в командную строку БД сразу, без ввода пароля.
Теперь все готово, вы можете изменить свой утерянный пароль.
Если пароли пользователей SYS и SYSTEM забыты или утеряны.
Вы можете использовать инструмент ORAPWD.EXE для изменения пароля. Меню «Пуск» -> Выполнить -> Введите «CMD», чтобы открыть окно командной строки, и введите следующую команду: orapwd file=D:\oracle10g\database\pwdctcsys.ora password=newpass Эта команда повторно создает файл паролей базы данных. Расположение файла паролей находится в каталоге \ database в каталоге ORACLE_HOME. Этот пароль предназначен для изменения пароля пользователя sys. Пароли пользователей, отличных от sys, не будут изменены. Однако Oracle предоставляет два метода проверки: один — это проверка ОС, а другой — проверка файла пароля. Если это первый метод, используйте следующие методы для изменения пароля: sqlplus /nolog; connect / as sysdba alter user sys identified by ; alter user system identified by ; Если это второй метод, используйте указанный выше метод для изменения или вы можете изменить пароль следующим образом: orapwd file = pwdxxx.ora password = Новый пароль, который вы установили, entry = 10 После настройки перезапустите службу и снова войдите в систему.
Как установить пароль root для начала использования MySQL
Для только что установленной MySQL пароль пользователя root является пустым.
Вы можете выполнить вход в MySQL (MariaDB) с помощью следующей команды, даже не вводя пароль:
sudo mysql -u root
Чтобы установить пароль root запустите и следуйте инструкциям:
sudo mysql_secure_installation
Давайте внимательно разберёмся со всем, что говорит нам этот скрипт, поскольку вопросам безопасности вер-сервера следует уделять особое внимание.
NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB SERVERS IN PRODUCTION USE! PLEASE READ EACH STEP CAREFULLY!
Перевод:
Примечание: запуск всех элементов этого скрипта рекомендуется для всех серверов MariaDB в продакшене (реальном рабочем использовании).
In order to log into MariaDB to secure it, we'll need the current password for the root user. If you've just installed MariaDB, and you haven't set the root password yet, the password will be blank, so you should just press enter here.
Перевод:
Для того, чтобы войти в MariaDB для настройки безопасности, нам нужен текущий пароль пользователя root. Если вы только что установили MariaDB и ещё не установили пароль рута, то пароль будет пустым, т.е. просто нажмите Enter.
Затем у нас спрашивают:
OK, successfully used password, moving on... Setting the root password or using the unix_socket ensures that nobody can log into the MariaDB root user without the proper authorisation. You already have your root account protected, so you can safely answer 'n'. Switch to unix_socket authentication [Y/n] n
Перевод:
ОК, пароль успешно использован, идём дальше …
Установка пароля root или использование unix_socket гарантирует, что никто не сможет войти в систему под пользователем root MariaDB без надлежащей авторизации.
Ваша учётная запись root уже защищена, поэтому вы можете спокойно ответить «n».
Переключиться на аутентификацию unix_socket [Y/n] n
Я ответил n (нет).
Далее новый вопрос:
Change the root password? [Y/n]
Перевод:
Изменить пароль root?
Отвечаем Y (да) и дважды вводим новый пароль. Не используйте в пароле символ точка с запятой и вообще аккуратнее со специальными символами в пароле.
Далее:
By default, a MariaDB installation has an anonymous user, allowing anyone to log into MariaDB without having to have a user account created for them. This is intended only for testing, and to make the installation go a bit smoother. You should remove them before moving into a production environment. Remove anonymous users? [Y/n]
Перевод:
По умолчанию, установленная MariaDB имеет анонимного пользователя, позволяющего любому войти в MariaDB даже если для него не было создано пользовательского аккаунта. Это сделано в целях тестирования и упрощения установки. Вам следует удалить их перед переходом в реальное рабочее окружение.
Удалить анонимного пользователя? [Да/нет]
Затем:
Normally, root should only be allowed to connect from 'localhost'. This ensures that someone cannot guess at the root password from the network. Disallow root login remotely? [Y/n]
Перевод:
Обычно, root’у следует разрешать подключаться только с ‘localhost’. Это гарантирует, что кто-то из сети не сможет угадать пароль root’а.
Отключить удалённый вход рута? [Да/нет]
Затем:
By default, MariaDB comes with a database named 'test' that anyone can access. This is also intended only for testing, and should be removed before moving into a production environment. Remove test database and access to it? [Y/n]
Перевод:
По умолчанию MariaDB поставляется с базой данных ‘test’, к которой может любой получить доступ. Это также сделано в целях тестирования и она должна быть удалена перед переходом в реальное рабочее окружение.
Удалить тестовую базу данных и доступ к ней? [Да/нет]
Далее:
Reloading the privilege tables will ensure that all changes made so far will take effect immediately. Reload privilege tables now? [Y/n]
Перевод:
Перезагрузка таблицы привилегий гарантирует, что все сделанные изменения немедленно будут иметь эффект.
Перезагрузить таблицу привилегий сейчас? [Y/n]
Наконец:
All done! If you've completed all of the above steps, your MariaDB installation should now be secure.
Перевод:
Всё сделано! Если вы завершили все вышеописанные шаги, ваша установленная MariaDB должна быть безопасной.
Ещё раз о пароле MariaDB. Это должен быть надёжный и уникальный пароль. Думайте о нём как о пароле входа на ваш сервер. Он должен отличаться от пароля пользователя Linux.
Включение и отключение аутентификации по unix_socket
Переключиться на аутентификацию по паролю можно следующим SQL запросом:
ALTER USER 'root'@'localhost' IDENTIFIED BY 'ПАРОЛЬ';
Обратите внимание, что вам нужно ввести ПАРОЛЬ.
Чтобы переключиться на аутентификацию по unix_socket выполните следующий SQL запрос:
ALTER USER 'root'@'localhost' IDENTIFIED VIA unix_socket;
Проверим:
SELECT plugin from mysql.user where User='root';
Если выведено mysql_native_password, то это означает, что используется вход по паролю.
На самом деле, аутентификацию по unix_socket можно сочетать с аутентификацией по паролю, но я не буду на этом останавливаться.
Управление пользователями
В PostgreSQL используется концепция ролей. Одну роль можно рассматривать как отдельного пользователя или как группу пользователей. Роли могут владеть объектами БД и выдавать разрешения другим ролям.
По умолчанию была создана роль postgres. Давайте создадим еще одну роль. Для этого из консоли системы выполняем команду:
createuser -P --interactive
Система запросит имя для новой роли, пароль, а также позволит настроить привилегии — например, нужно ли давать права суперпользователя или разрешать создавать другие роли и базы данных.
Если вы уже зашли в psql, то создать новую роль можно командой:
CREATE ROLE имя_новой_роли WITH LOGIN CREATEDB CREATEROLE; // В конце обязательно ставим ;
Затем задаем пароль:
\password имя_роли
Вывести список всех ролей можно командой /du. Кроме имен отобразятся привилегии каждого роли.
Чтобы закрыть список ролей, выполняем команду q.
Для удаления пользователя выполняем команду:
DROP ROLE имя_роли;
Это можно также сделать из консоли системы с помощью команды:
drop user имя_роли
Чтоб сменить пароль пользователя, подключаемся к psql с правами суперпользователя. Затем выполняем следующую команду:
ALTER USER имя_роли WITH PASSWORD 'новый_пароль';
Эта операция сохраняется в файле .psql_history вместе с паролем, который не будет зашифрован. В качестве дополнительной меры безопасности эту запись рекомендуется удалить. Файл обычно находится в директории /var/lib/postgresql.
Как проверить, какой метод аутентификации используется
Для просмотра используемого метода аутентификации можно использовать следующий SQL запрос:
select * from mysql.global_priv where User='root';
Или такую, для большей наглядности вывода:
SELECT CONCAT(user, '@', host, ' => ', JSON_DETAILED(priv)) FROM mysql.global_priv where user='root';
Можно увидеть, что в качестве плагина установлены mysql_native_password и unix_socket:
{
"access": 18446744073709551615,
"plugin": "mysql_native_password",
"authentication_string": "invalid",
"auth_or":
}
При такой конфигурации, у меня работала только аутентификация по unix_socket.
Шаг 1 — Определяем версию системы управления базой данных
Самые современные дистрибутивы Linux поставляются с MySQL или MariaDB, последняя является полностью совместимой заменой MySQL. В зависимости от используемой СУБД и её версии, вам нужно использовать различные команды для восстановления пароля рута.
Вы можете проверить вашу версию следующей командой:
mysql --version
Для MySQL вы увидите что-то вроде:
mysql Ver 14.14 Distrib 5.7.17, for Linux (x86_64) using EditLine wrapper
Для MariaDB вывод будет примерно таким:
mysql Ver 15.1 Distrib 10.0.29-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2
Запомните какая база данных и какой версии у вас запущена, поскольку они пригодятся нам позже. Далее вам нужно остановить базу данных для ручного доступа к ней.
Как изменить пароль пользователя PostgreSQL?
Как я могу изменить пароль пользователя PostgreSQL?
Пароль меньше логин:
Чтобы сбросить пароль, если вы забыли:
Затем бросить psql в :
Если это не помогает, настройте проверку подлинности.
Редактировать/и т. д./в PostgreSQL/9.1/основные/файл pg_hba.конф` (путь будет отличаться) и изменение:
Затем перезапустите сервер:
Вы можете и должны иметь пользователи’с зашифрованным паролем:
Я считаю, что лучший способ изменить пароль, просто использовать:
в консоли Постгреса.
Чтобы изменить пароль с помощью командной строки в Linux, используйте:
Перейти с вашим PostgreSQL config и отредактировать файл pg_hba.конф
судо ВИМ /и т. д./в PostgreSQL/9.3/главная/файле pg_hba.conf и
Затем измените эту строку :
потом перезапустить сервис PostgreSQL через команду sudo затем
команду psql-у Постгреса
Вы сейчас вошли и увидите терминал с PostgreSQL
и введите новый пароль для Postgres пользователя по умолчанию, после успешного изменения пароля перейдите в файле pg_hba.conf и отменить изменения, чтобы «мд5, то»
теперь вы будете зарегистрированы в качестве
команду psql-у Постгреса
с вашим новым паролем.
Дайте мне знать, если вы обнаружите какие-либо проблемы в нем.
Для Изменения Пароля
теперь введите новый пароль и подтвердите
затем \Q для выхода
Чтобы запросить новый пароль сервер пользователь (не показывая его в команду):
Это был первый результат в Google, когда я искал как переименовать пользователя, так:
Несколько других команд полезно для управления пользователями:
Переместить пользователя в другую группу
Конфигурации, что я’ve получили на моем сервере была настроена много и я успел поменять пароль только после того, как я поставил доверие аутентификация в файл pg_hba.файл conf :
Дон’т забудьте изменить этот пароль или MD5
В моем случае на Ubuntu 14.04, установлен с Постгреса 10.3. Я нужно выполнить следующие действия
местные все Постгреса с MD5`
введите новый пароль для этого пользователя, а затем подтвердите его. Если вы Don’т помню пароль и вы хотите изменить его, вы можете войти как Postgres и затем использовать это:
Похож на другие ответы в синтаксис, но это должно быть известно, что вы также можете пройти MD5 для паролей, так что вы не передавая простой текстовый пароль.
Вот несколько сценариев непреднамеренных последствий изменения пароля пользователей в виде обычного текста.
С что сказал, Вот как мы можем изменить пользователя’пароля путем построения MD5 для пароля.
Постгреса, когда хэш пароля как MD5, солей пароль с именем пользователя, затем добавляет текст «и в MD5» на результирующий хэш.
и GT; например: «в виде MD5» В+С MD5(пароль + логин)
$То StringBuilder = Новый-Системный Объект.Текст.То StringBuilder
$То StringBuilder.Метод toString();
Сброс пароля Ubuntu с помощью sudo
Сброс пароля Ubuntu — дело не такое уж сложное. Все может оказаться еще проще, если у вас есть другие пользователи, к которым вы помните пароль и у которых есть право использования утилиты sudo. Для того чтобы изменить пароль для пользователя достаточно авторизоваться от имени другого пользователя и выполнить команду passwd, передав ей имя нужного пользователя, например losstuser:
А затем ввести пароль текущего пользователя:
И два раза ввести новый пароль для пользователя, пароль которого вы забыли.
Но не всегда все так просто и о запасном варианте мы вспоминаем только тогда, когда создавать его уже поздно. Поэтому есть еще один способ, которым можно выполнить восстановление пароля Ubuntu.
