2017-08-20 2 views
0

Ich versuche zum ersten Mal, eine Anwendung auf einem Remote/Cloud VPS einzurichten (ich verwende Digital Ocean, wenn es darauf ankommt). Ich versuche einen SSH-Tunnel von meinem Client zur entfernten Datenbank zu erstellen. Da dies nicht etwas ist, was ich zuvor versucht habe, habe ich auf this, this und this verwiesen.SSH Tunnel für PostgreSQL - Verbindung verweigert

Nach über die Artikel suchen, lief ich folgendes auf meinem Client/lokalen Rechner:

ssh -L 5433:localhost:5432 [email protected]_IP 

dann verbinde ich versucht:

, ich die folgende Fehlermeldung jedoch
psql -h localhost -p 5433 postgres; 

:

psql: could not connect to server: Connection refused 
Is the server running on host "localhost" (127.0.0.1) and accepting 
TCP/IP connections on port 5433? 

Zu meinem Wissen, meine pg_hba.conf (auf dem Remote-Server) ist der Standardwert:

# 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 

I changed "listen_addresses" in postgresql.conf zu *

# - Connection Settings - 

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

Ich habe auch versucht ohne Erfolg 127.0.0.1 forlocalhost ersetzen.

Jeder Rat würde geschätzt werden; SSH-Tunnel und ähnliches kenne ich nicht.

Danke. EDIT:

Per @drdaeman ausgezeichnete Beratung, lief ich folgendes:

sudo ssh -N -vvv -L 5433: localhost: 5432 user @ host

Die letzten Debug-Linien sind wie folgt :

debug1: Local forwarding listening on 127.0.0.1 port 5433. 
debug2: fd 5 setting O_NONBLOCK 
debug3: fd 5 is O_NONBLOCK 
debug1: channel 1: new [port listener] 
debug2: fd 3 setting TCP_NODELAY 
debug3: ssh_packet_set_tos: set IP_TOS 0x10 
debug1: Requesting [email protected] 
debug3: send packet: type 80 
debug1: Entering interactive session. 
debug1: pledge: network 
debug3: receive packet: type 80 
debug1: client_input_global_request: rtype [email protected] want_reply 0 

Ausgabe von sudo netstat -ltpn | grep 5432

tcp  0  0 127.0.0.1:5432   0.0.0.0:*    LISTEN  5835/postgres 

Es stoppt dort, reagiert auf keine Befehle.

Danke für jede Richtung.

+0

Server neu starten? – sibert

+0

Danke sibert. Ich habe versucht, PostgreSQL und den Server selbst neu zu starten, aber keine Änderung. – KellyMarchewa

Antwort

1

Basierend auf Ihrer Beschreibung sieht alles OK für mich aus - nicht sehen, wo das Problem liegt, aber die Befehle, die Sie ausführen, und Ihre Konfiguration sieht korrekt aus. Hier sind die allgemeinen Schritte, die Sie ergreifen können, um das Problem zu diagnostizieren:

Überprüfen Sie zuerst, ob Ihr PostgreSQL-Server tatsächlich zuhört. Auf Ihrem Server laufen diese:

$ sudo netstat -ltpn | grep 5432 

(Oder Sie ss -ltpn von iproute2 anstelle älterer netstat verwenden)

nichts sehen Wenn Sie, es bedeutet, dass kein Prozess auf tcp/5432 hört.Sie können versuchen, zu sehen, ob PostgreSQL ist überall überhaupt hören:

$ sudo netstat -lpn | grep postgre 

Wenn es nicht - überprüfen, wenn Ihr Server läuft tatsächlich (abhängig von den OS und Verteilung, aber überprüfen ps aux zuerst ausgegeben) und überprüfen Sie Ihre Serverprotokolle (wahrscheinlich in /var/log), wenn Sie irgendwelche Probleme dort sehen.

Dann stellen Sie sicher, dass Sie nicht versehentlich psql auf Ihrem Server ausführen (wenn Sie SSH, öffnet es auch die Shell-Sitzung, wenn Sie das -N Flag angeben). Sie müssen es auf dem lokalen Computer laufen;)

Dann können Sie auch -v Erwägung ziehen, (oder sogar -vvv) an Ihren ssh Befehl - es wird eine Menge nützlicher Debug-Informationen speien, z.B. ein normaler Betrieb sieht wie folgt aus:

debug1: Connection to port 5433 forwarding to localhost port 5432 requested. 
debug1: channel 3: new [direct-tcpip] 
debug1: channel 3: free: direct-tcpip: listening port 5433 for localhost port 5432, connect from ::1 port 60039 to ::1 port 5433, nchannels 4 

Wenn Sie so etwas wie channel 3: open failed: connect failed: Connection refused stattdessen sehen, bedeutet dies, PostgreSQL die Verbindung abgelehnt hatte - und Sie müssen seine Protokolle für die Begründung überprüfen - eventuell nach log_connections und log_disconnections in der Freigabe config (Vergessen Sie nicht, die Konfiguration neu zu laden).

+1

Oh, und vergessen Sie nicht, 'listen_addresses' zu konfigurieren, damit Ihre PostgreSQL-Instanz nicht der Welt ausgesetzt ist. Sie müssen nicht auf '0.0.0.0' und/oder' [::] 'hören, wenn Sie SSH-Tunneling verwenden. Es muss nur auf "127.0.0.1" und/oder ":: 1" hören. – drdaeman

+0

Vielen Dank. Ausgezeichneter Rat. Ich habe oben die Debug-Ausgabe hinzugefügt. – KellyMarchewa

+1

@KellyMarchewa Zwei Fragen, um dies weiter zu diagnostizieren: 1) Haben Sie überprüft, ob der Server korrekt hört? Und 2) die ssh-Ausgabe, die Sie gezeigt haben, ist normal (und ja, es wird so hängen bleiben - Sie können es mit Strg + C beenden, wenn Sie es nicht mehr brauchen), aber passiert etwas mit dem 'ssh' Ausgabe, wenn Sie 'psql' ausführen? Es sollte z.B. 'debug1: Verbindung zu Port 5433 Weiterleitung an localhost Port 5432 angefordert. wenn Sie dies tun. Weitergeleitete Port-Verbindungen werden nur hergestellt, wenn sie angefordert werden, nicht wenn Sie 'ssh' ausführen und verbinden. – drdaeman