2016-03-08 6 views
0

Я использовал MySQL в течение многих лет, поэтому я мог бы наивно накладывать свои ожидания MySQL на Позрес, но я ударяю о стену. Я создал пользователь, flasktut с LOGIN CREATEDB, но когда я пытаюсь войти в системе, я получаю psql: FATAL: Peer authentication failed for user "flasktut" - Я попытался сбросить пароль:Почему я не могу войти в Postgres?

postgres=# ALTER USER flasktut WITH PASSWORD 'zx80xb1'; 
ALTER ROLE 

и я до сих пор вижу ошибку. Я подозреваю, что я делаю что-то сверх очевидное здесь неправильно?

+0

Когда вы создаете одного пользователя, вы должны дать ему разрешение на один бит, а затем, когда пользователь попытается войти в систему, он должен указать, какой db он пытается получить. Если он не суперпользователь. Как вы создаете пользователя? –

+0

_Первая аутентификация_ происходит без пароля. См. Http: //www.postgresql.org/docs/current/static/auth-pg-hba-conf.html и адаптируйте свою конфигурацию к политике безопасности, которая наилучшим образом соответствует вашим потребностям. –

+0

Как вы подключаетесь к серверу? Напишите команду psql, которую вы запускаете. Сервер работает на вашем локальном компьютере или удаленном? Если он находится на локальном хосте, вы подключаетесь через сокет или IP-адрес домена? Посмотрите файл pg_hba.conf. Здесь перечислены все схемы входа и методы проверки подлинности. – kliron

ответ

0

Если вы опустите имя хоста, psql будет подключаться через сокет Unix-домена к серверу на локальном хосте или через TCP/IP в localhost на компьютерах, не имеющих сокетов Unix-домена.

Так редактировать файл pg_hba.conf и добавлять/обновлять строки:

# "local" is for Unix domain socket connections only 
local all    all          trust 
# IPv4 local connections: 
host all    all    127.0.0.1/32   trust 
# IPv6 local connections: 
host all    all    ::1/128     trust 

Перезапустите сервер для того, чтобы изменения вступили в силу.

Теперь запустите psql -d <your_db> -U flasktut

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

Когда вы чувствуете себя уверенно с вашими Postgres навыками, вы, вероятно, следует изменить «доверие» выше к чему-то более безопасному, например «md5».

1

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

Вход в Postgres, состоит из двух частей:

  1. Внешняя проверка безопасности гарантирует, что определенные IP-адреса/подсети/местные или иностранные хозяева могут быть (не) разрешено даже «достичь» базы данных Postgres. Второй аспект заключается в том, что данная комбинация пользователя/базы данных разрешается проходить. Важно отметить, что ваша текущая настройка, вероятно, не учитывает этот аспект, и хотя вы, похоже, позаботились о пункте 2 (ниже), это не имеет значения, поскольку попытки входа в систему даже не достигают этапа 2.

  2. Как только процесс входа в систему проходит через внешнюю проверку, сам Database/User должен быть действительным/существующим и использоваться.

Первый аспект (выше) управляются файлом pg_hba.conf, и то, что вам нужно убедиться в том, что, когда база данных разбирает через файл pg_hba.conf, «первую» линию, которая является достаточно разрешающей применять для данного сценария входа, является тем, что принято как эффективное «правило» для этой попытки входа в систему.

См., Например,

Если вход локально (без 127.0.0.1 или eth0 и т.д. IP-адреса)

# "local" is for Unix domain socket connections only 
local all    all          trust 

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

Важно отметить, что последующие строки, хотя могут быть более безопасными/apt, они не будут применяться, если предыдущая строка в файле конфигурации уже рассматривается как кандидат для попытки входа в систему. Кроме того, не забудьте перезагрузить/перезагрузить Postgres после каждый изменить на pg_hba.conf.

0

Здесь есть две вещи.

Во-первых, settings in pg_hba.conf необходимо разрешить вам подключаться к любой базе данных, к которой вы пытаетесь подключиться. Типичная запись в файле выглядит следующим образом:

host  my_db myself 192.168.1.17/32 md5 
host  all  all  192.168.1.0/24 md5 

Первая строка позволяет конкретный пользователь (myself) от конкретного удаленного клиента (192.168.1.17/32) для подключения к определенной базе данных (my_db) по протоколу TCP/IP (host). Вторая строка позволяет любому пользователю подключаться к любой базе данных в сети 192.168.1.0/24, типичный сетевой адрес для дома или небольшого офиса. Оба должны пройти аутентификацию с помощью пароля (md5). Вы должны добавить строку, подобную приведенной выше, чтобы разрешить flasktut, даже достигнуть сервера для установления соединения. Обратите внимание: при изменении этого файла вам необходимо перезапустить сервер, чтобы изменения вступили в силу.

Второй вопрос заключается в том, что ваш новый пользователь flasktut должен иметь разрешение на подключение к любой базе данных s/он хочет подключиться к:

GRANT CONNECT ON DATABASE some_db TO flasktut; 

И тогда в этой базе данных, вы должны предоставить привилегии доступа объекты, либо непосредственно, либо путем предоставления роль, flasktut членство в группе роли, которая имеет необходимые разрешения:

GRANT some_role TO flasktut; 

Если flasktut будет иметь ее/его собственную базу данных, у НУ, вероятно, лучше, как суперпользователь выдает себя пользователь flasktut создать базу данных, а затем выпускающего реального журнала пользователя в к этой базе данных ее/сами:

SET SESSION AUTHORIZATION flasktut; 
CREATE DATABASE some_db; -- somedb is owned by flasktut 
RESET SESSION AUTHORIZATION; 
0

я думаю, что вы уже использовали сервер локального порта, так что вы можете создать еще одну базу данных в локальный порт сервера (нет необходимости добавлять сервер в Postgres, создать БД непосредственно с этого сервера порта)

или
вы можете проверить настройки в pg_hba.conf? https://help.ubuntu.com/stable/serverguide/postgresql.html

0

Система проверки подлинности PostgreSQL находится в pg_hba.conf. Множество authentication mechanisms может быть настроено в зависимости от того, как делается соединение, к какой базе данных и к какому пользователю.

Что может быть удивительным, исходя из фона MySQL - это настройка по умолчанию, часто используемая при установке Linux: для локальных подключений по умолчанию используется peer.

Здесь значения по умолчанию на системе Debian/Ubuntu:

# Database administrative login by Unix domain socket 
local all    postgres        peer 
# TYPE DATABASE  USER   ADDRESS     METHOD 
# "local" is for Unix domain socket connections only 
local all    all          peer 
# IPv4 local connections: 
host all    all    127.0.0.1/32   md5 
# IPv6 local connections: 
host all    all    ::1/128     md5 
  • peer выглядит для текущего пользователя Linux работает psql (или любой другой клиент PostgreSQL). В этом случае аутентификация пароля не используется, но она зависит от ОС, предоставляющей имя пользователя. Это работает только локально, используя здесь Unix-сокет (который является значением по умолчанию, когда вы ничего не указываете psql).

  • md5 запросит пароль, но он настроен только для сетевых подключений в этой конфигурации.

В результате, если я создаю пользователя и БД следующим образом (вход в качестве postgres):

[email protected]:~$ createuser -S -D -R -P myuser 
Enter password for new role: 
Enter it again: 

[email protected]:~$ createdb -E UTF-8 -O myuser mydb 

Это будет пытаться подключиться, используя сокет UNIX, и не потому, что я м по-прежнему регистрируется в качестве postgres, а не как myuser (который может или не может даже существовать в этой системе):

[email protected]:~$ psql -U myuser mydb 
psql: FATAL: Peer authentication failed for user "myuser" 

(Если бы я вошел в систему как myuser в этом Linux Shel Л., Он работал бы)

В отличие от этого, если я явно указать я хочу подключить через сеть (хотя 127.0.0.1), я запрошен пароль, и я могу войти в систему:

[email protected]:~$ psql -U myuser -h 127.0.0.1 mydb 
Password for user myuser: 
psql (9.1.20) 
SSL connection (cipher: DHE-RSA-AES256-GCM-SHA384, bits: 256) 
Type "help" for help. 

mydb=> 

Механизм trust - это тот, который представляет наибольшую угрозу безопасности, поскольку он ничего не проверяет, а режим подключения на этой линии.

Например:

# This will let any local user connect to any DB via the Unix socket 
# without any authentication: 
local all    all          trust 

# This will let any user connect to any DB via 127.0.0.1 
# without any authentication: 
host all    all    127.0.0.1/32   trust 

# And worse (DO NOT USE): 
# This will let any user connect to any DB from anywhere 
# without any authentication: 
host all    all    0.0.0.0/0   trust 

Там не много случаев, кроме сброса потерянной postgres (администратор) пароля, где использование trust оправданно.


В качестве примечания, вы говорите, вы использовали это, чтобы изменить пароль в psql:

postgres=# ALTER USER flasktut WITH PASSWORD 'zx80xb1'; 
ALTER ROLE 

Это действительно работает, но есть несколько побочных эффектов: пароль теперь вероятно, будет зарегистрирован в ящике ~/.psql_history, и он также может быть зарегистрирован на стороне сервера (везде, где его журналы отправлены).

psql В, как правило, лучше использовать \password команду:

postgres=# \password flasktut 
Enter new password: 
Enter it again: 

Это не оставит след пароля в незашифрованном виде в журналах или истории.

Смежные вопросы