Início / dba / Perguntas / 8111
Accepted
Jérôme Verstrynge
Asked: 2011-11-10 06:25:38 +0800 CST

PgAdmin III - Como conectar ao banco de dados quando a senha está vazia?

  • 772

Instalei o PostgreSQL 9.1 no meu PC (Win 7). Eu tenho um pequeno aplicativo Java conectando-se com sucesso a ele com login=sae password="". A conexão funciona.

No entanto, é recusado pelo próprio PgAdmin III. Eu recebo:

Error connecting to the server: fe_sendauth: no password supplied

Como me conecto ao meu banco de dados do PgAdmin III com uma senha vazia?

EDITAR

Este é apenas um teste, não um código de produção.

postgresql pgadmin

2 respostas

  1. Encontrei esta resposta em outro lugar.

    Se seu banco de dados estiver no host local, tente deixar o campo do host em branco na conexão em vez de usar “localhost” ou “127.0.0.1″. Isso diz ao PgAdmin para se conectar através do soquete unix local em vez de TCP.

    • 33
  2. Best Answer

    Eu posso me conectar à minha instância postgres do pgAdmin III sem uma senha para qualquer usuário, incluindo superusuários, como postgres.

    Como você está se conectando bem a partir de outro cliente, não há razão para que você não consiga se conectar a partir do pgAdmin se eles estiverem na mesma estação de trabalho - a menos que alguma regra de firewall no próprio cliente permita um programa, mas não outro.

    Se o problema for específico para este cliente, pode ser necessário alterar um ou mais dos seguintes itens:

    • pg_hba.conf 
    host sa all 192.168.0.nnn/32 trust
    • postgresql.conf
    listen_addresses = '*'
    • o firewall em seu servidor postgres, por exemplo, iptables:
    -A ENTRADA -s 192.168.0.nnn -m estado --estado NOVO -j ACEITAR

    Mas eu recomendo que você não faça nada disso. O manual diz o seguinte com razão:

    a autenticação de confiança só é adequada para conexões TCP/IP se você confiar em todos os usuários em todas as máquinas que têm permissão para se conectar ao servidor pelas linhas pg_hba.conf que especificam confiança. Raramente é razoável usar confiança para qualquer conexão TCP/IP que não seja do localhost (127.0.0.1).

    Em vez disso, considere:

    • usando uma senha e identificação md5
    • tunelamento da porta 5432 sobre ssh
    • 10

relate perguntas