Impossibile connettersi a PostgreSQL in remoto su Amazon istanza EC2 utilizzando PgAdmin

Question

ho un livello gratuito micro RHEL 6 istanza in esecuzione e hanno PostgreSQL 9.2 installato seguendo le istruzioni yum qui: http://yum.pgrpms.org/howtoyum.php

e sono in grado di connettersi al server PG localmente usando questo sul server:

03:46:20 root@xxx[~]$ psql -hlocalhost -p5432 -Upostgres 

Tuttavia, non mi sono mai collegato correttamente al di fuori della scatola. Il messaggio di errore è simile a:

12:11:56 saladinxu@GoodOldMBP[~]$ psql -h ec2-xxx.ap-southeast-1.compute.amazonaws.com -p5432 -Upostgres 
    psql: could not connect to server: Connection refused 
    Is the server running on host "ec2-54-251-188-3.ap-southeast-1.compute.amazonaws.com" (54.251.188.3) and accepting TCP/IP connections on port 5432? 

Ho provato un sacco di modi diversi. Ecco come i miei file di configurazione guardano ora:

/var/lib/pgsql/9.2/data/postgresql.conf:

... 

# - Connection Settings - 

listen_addresses = '*'  # what IP address(es) to listen on; 
       # comma-separated list of addresses; 
       # defaults to 'localhost'; use '*' for all 
port = 5432    # (change requires restart) 
max_connections = 100   # (change requires restart) 
... 

/var/lib/pgsql/9.2/data/pg_hba.conf:

# TYPE DATABASE  USER   ADDRESS     METHOD 
host all    pgadmin   0.0.0.0/24    trust 
host all    all    [my ip]/24   md5 
# "local" is for Unix domain socket connections only 
local all    all          peer 
# IPv4 local connections: 
host all    all    127.0.0.1/32   ident 
# IPv6 local connections: 
host all    all    ::1/128     ident 

Ho provato a rendere l'indirizzo sopra a 0.0.0.0/0 ma id non ha funzionato.

E ogni volta che ho fatto un cambiamento che ho rimesso in moto eseguendo questo

service postgresql-9.2 restart 

al gruppo di protezione di questa istanza EC2 posso vedere questa regola già:

TCP 
Port (Service) Source Action 
22 (SSH) 0.0.0.0/0 Delete 
80 (HTTP) 0.0.0.0/0 Delete 
5432 0.0.0.0/0 Delete 

netstat spettacoli di comando che la porta è già aperta:

04:07:46 root@ip-172-31-26-139[~]$ netstat -na|grep 5432 
tcp  0  0 0.0.0.0:5432    0.0.0.0:*     LISTEN  
tcp  0  0 :::5432      :::*      LISTEN  
unix 2  [ ACC ]  STREAM  LISTENING  14365 /tmp/.s.PGSQL.5432 

Per rispondere alla domanda di bma:

Se eseguo il comando nmap sul server locale che sembra suggerire che attraverso DNS interno è andare a un altro host, dove 5432 è aperto:

10:16:05 root@ip-172-31-26-139[~]$ nmap -Pnv -p 5432 ec2-54-251-188-3.ap-southeast-1.compute.amazonaws.com 

Starting Nmap 5.51 (http://nmap.org) at 2013-07-22 10:16 EDT 
Nmap scan report for ec2-54-251-188-3.ap-southeast-1.compute.amazonaws.com (172.31.26.139) 
Host is up (0.00012s latency). 
rDNS record for 172.31.26.139: ip-172-31-26-139.ap-southeast-1.compute.internal 
PORT  STATE SERVICE 
5432/tcp open postgresql 

Nmap done: 1 IP address (1 host up) scanned in 0.07 seconds 

e il comando iptables ha pronunciato la seguente uscita

10:16:14 root@ip-172-31-26-139[~]$ iptables -nvL 
Chain INPUT (policy ACCEPT 0 packets, 0 bytes) 
pkts bytes target  prot opt in  out  source    destination   
25776 14M ACCEPT  all -- *  *  0.0.0.0/0   0.0.0.0/0   state RELATED,ESTABLISHED 
0  0 ACCEPT  icmp -- *  *  0.0.0.0/0   0.0.0.0/0   
45 1801 ACCEPT  all -- lo  *  0.0.0.0/0   0.0.0.0/0   
251 15008 ACCEPT  tcp -- *  *  0.0.0.0/0   0.0.0.0/0   state NEW tcp dpt:22 
35 2016 REJECT  all -- *  *  0.0.0.0/0   0.0.0.0/0   reject-with icmp-host-prohibited 

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) 
pkts bytes target  prot opt in  out  source    destination   
0  0 REJECT  all -- *  *  0.0.0.0/0   0.0.0.0/0   reject-with icmp-host-prohibited 

Chain OUTPUT (policy ACCEPT 21695 packets, 5138K bytes) 
pkts bytes target  prot opt in  out  source    destination 

[Modificato dopo aver aggiunto secondo il suggerimento di BMA]

iptables sembra che questo dopo la nuova aggiunta:

11:57:20 root@ip-172-31-26-139[~]$ iptables -nvL 
Chain INPUT (policy ACCEPT 0 packets, 0 bytes) 
pkts bytes target  prot opt in  out  source    destination   
26516 14M ACCEPT  all -- *  *  0.0.0.0/0   0.0.0.0/0   state RELATED,ESTABLISHED 
0  0 ACCEPT  icmp -- *  *  0.0.0.0/0   0.0.0.0/0   
47 1885 ACCEPT  all -- lo  *  0.0.0.0/0   0.0.0.0/0   
255 15236 ACCEPT  tcp -- *  *  0.0.0.0/0   0.0.0.0/0   state NEW tcp dpt:22 
38 2208 REJECT  all -- *  *  0.0.0.0/0   0.0.0.0/0   reject-with icmp-host-prohibited 
0  0 ACCEPT  tcp -- *  *  [my ip]   54.251.188.3  tcp spts:1024:65535 dpt:5432 state NEW,ESTABLISHED 
0  0 ACCEPT  tcp -- *  *  0.0.0.0/0   54.251.188.3  tcp spt:5432 dpts:1024:65535 state ESTABLISHED 

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) 
pkts bytes target  prot opt in  out  source    destination   
0  0 REJECT  all -- *  *  0.0.0.0/0   0.0.0.0/0   reject-with icmp-host-prohibited 

Chain OUTPUT (policy ACCEPT 5 packets, 1124 bytes) 
pkts bytes target  prot opt in  out  source    destination   
0  0 ACCEPT  tcp -- *  *  54.251.188.3   [my ip]  tcp spt:5432 dpts:1024:65535 state ESTABLISHED 
0  0 ACCEPT  tcp -- *  *  54.251.188.3   0.0.0.0/0   tcp spts:1024:65535 dpt:5432 state NEW,ESTABLISHED 

Ma non riesco ancora a connettermi (stesso errore). Quale potrebbe essere il pezzo mancante qui?

Answer 1

Avete una porta di blocco del firewall 5432? Una nmap veloce mostra che viene filtrato.

nmap -Pnv -p 5432 ec2-54-251-188-3.ap-southeast-1.compute.amazonaws.com 

Starting Nmap 6.00 (http://nmap.org) at 2013-07-21 11:05 PDT 
Nmap scan report for ec2-54-251-188-3.ap-southeast-1.compute.amazonaws.com (54.251.188.3) 
Host is up (0.19s latency). 
PORT  STATE SERVICE 
5432/tcp filtered postgresql 

Cosa indica l'iptables dell'EC2 per la porta 5432?

iptables -nvL 

[dopo OP aggiunti ulteriori dettagli]

Netstat mostra che è in ascolto, ma l'uscita firewall non sembra la porta 5432 è aperta (confesso di non essere molto di un ragazzo di rete). Facendo riferimento ad alcuni dei miei appunti delle installazioni precedenti, potrebbe essere necessario aprire la porta EC2 5432 sul proprio IP.

Per consentire l'accesso firewall di ingresso, sostituire il vostro-REMOTE-IP con l'IP si sta collegando da:

iptables -A INPUT -p tcp -s YOUR-REMOTE-IP --sport 1024:65535 -d 54.251.188.3 --dport 5432 -m state --state NEW,ESTABLISHED -j ACCEPT 
iptables -A OUTPUT -p tcp -s 54.251.188.3 --sport 5432 -d YOUR-REMOTE-IP --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT 

accesso --outbound

iptables -A OUTPUT -p tcp -s 54.251.188.3 --sport 1024:65535 -d 0/0 --dport 5432 -m state --state NEW,ESTABLISHED -j ACCEPT 
iptables -A INPUT -p tcp -s 0/0 --sport 5432 -d 54.251.188.3 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT 

Cosa iptables -nvL lista dopo. Puoi connetterti?

Answer 2

Ho trovato la risoluzione a questo problema. Sono necessarie due cose.

1. Utilizzare un editor di testo per modificare pg_hba.conf. Individua l'host di linea tutto 127.0.0.1/0 md5. Immediatamente al di sotto di esso, aggiungere questa nuova linea: ospitare tutti tutti 0.0.0.0/0 md5

2. Modifica del file postgresql.conf PostgreSQL:

   Utilizzare un editor di testo per modificare postgresql.conf. Individua la riga che inizia con #listen_addresses = 'localhost'. Decommentare la riga eliminando il # e modificare localhost su . La riga dovrebbe ora apparire così: listen_addresses = '' # quale indirizzo IP (i) da ascoltare ;.

Ora basta riavviare il servizio Postgres e sarà in grado di connettersi

Answer 3

Sembra tua pg_hba.conf manca la "+" dopo il nome del gruppo. provare

# TYPE DATABASE USER ADDRESS METHOD host all pgadmin+ 0.0.0.0/24 trust host all all [my ip]/24 md5

Il pg_hba.conf spiega sull'utente:

Il valore tutto specifica che corrisponde a tutti gli utenti. Altrimenti, si tratta del nome di un utente di database specifico o di un nome di gruppo preceduto da +. (Ricorda che non c'è una vera distinzione tra utenti e gruppi in PostgreSQL: un segno + significa veramente "abbina i ruoli che sono direttamente o indirettamente membri di questo ruolo", mentre un nome senza un segno + corrisponde solo a quel ruolo specifico.)