It was easy for me to connect to my remote mysql server on AWS using a sequelpro, however I'm struggling with doing the same thing with mongodb.
I tried setting up an ssh tunnel via command line like so:
ssh -fN -l root -i path/to/id_rsa -L 9999:host.com:27017 host.com
I also tried it with replacing host with an ip address
the idea is to forward all mongodb connections on port 9999 to the one on the host on port 27101.. however when I run the command:
mongo --host localhost --port 9999
the connection fails, I get this instead:
MongoDB shell version: 2.6.0
connecting to: localhost:9999/test
channel 2: open failed: connect failed: Connection timed out
channel 3: open failed: connect failed: Connection timed out
2014-05-22T14:42:01.372+0300 DBClientCursor::init call() failed
2014-05-22T14:42:01.374+0300 Error: DBClientBase::findN: transport error: localhost:9999 ns: admin.$cmd query: { whatsmyuri: 1 } at src/mongo/shell/mongo.js:148
exception: connect failed
if I run sudo netstat -plnt
I get the following (which seems in order):
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 4242/node
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1342/httpd2-prefork
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 2552/sshd
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 2505/master
tcp 0 0 127.0.0.1:27017 0.0.0.0:* LISTEN 11719/mongod
tcp 0 0 127.0.0.1:6379 0.0.0.0:* LISTEN 16561/redis-server
any idea what i'm doing wrong?
update:
this is how the final functional command looks like (credit goes to kenster):
ssh -fN -i ~/path/to/id_rsa -L 6666:localhost:27017 root@remote.server.com
where the -fN
command make this command run in the background
Best Answer
The "channel 2" and "channel 3" lines are from
ssh
. Thesshd
instance on the remote server is trying to connect to host.com port 27017 in order to service a tunnel connection, and it's getting a "connection timed out" error.In other words,
sshd
on the remote server can't reach the target of the tunnel. Since the remote host is also the host which you're supposedly tunneling to, it's hard to say what the specific problem is. It could be that "host.com" resolves to more than one IP address. You're making an SSH connection to one server in the cluster, and then a different server in the cluster is being chosen as the tunnel target. You could try changing the tunnel target to "localhost" instead of "host.com":Update:
"-L 9999:localhost:27017" means that the
ssh
client on the local server listens for connections on port 9999. When it gets a connection, it tunnels the connection to thesshd
instance on the remote server. The remotesshd
instance connects from there to localhost:27017. So "localhost" here is from the perspective of the remote server.With the netstat output, it's a little clearer why it wasn't working before. The "127.0.0.1:27017 " part means that Mongodb is specifically bound to the localhost (127.0.0.1) interface on the remote host. You can't contact that instance of mongodb directly by trying to connect to the host's regular IP address--you can only contact that instance of mongodb through the localhost address. And of course, since it's localhost, you can only contact if from a client running on the same host.
So, the way you're doing it now--tunnel a connection to the server through ssh and then connect to localhost from there--is the way to do it.