ssh tunnel refusing connections with "channel 2: open failed"

Question

All of a sudden (read: without changing any parameters) my netbsd virtualmachine started acting oddly. The symptoms concern ssh tunneling.

From my laptop I launch:

$ ssh -L 7000:localhost:7000 user@host -N -v

Then, in another shell:

$ irssi -c localhost -p 7000

The ssh debug says:

debug1: Connection to port 7000 forwarding to localhost port 7000 requested.
debug1: channel 2: new [direct-tcpip]
channel 2: open failed: connect failed: Connection refused
debug1: channel 2: free: direct-tcpip: listening port 7000 for localhost port 7000, connect from 127.0.0.1 port 53954, nchannels 3

I tried also with localhost:80 to connect to the (remote) web server, with identical results.

The remote host runs NetBSD:

bash-4.2# uname -a
NetBSD host 5.1_STABLE NetBSD 5.1_STABLE (XEN3PAE_DOMU) #6: Fri Nov  4 16:56:31 MET 2011  root@youll-thank-me-later:/m/obj/m/src/sys/arch/i386/compile/XEN3PAE_DOMU i386

I am a bit lost. I tried running tcpdump on the remote host, and I spotted these 'bad chksum':

09:25:55.823849 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 67, bad cksum 0 (->3cb3)!) 127.0.0.1.54381 > 127.0.0.1.7000: P, cksum 0xfe37 (incorrect (-> 0xa801), 1622402406:1622402421(15) ack 1635127887 win 4096 <nop,nop,timestamp 5002727 5002603>

I tried restarting the ssh daemon to no avail. I haven't rebooted yet - perhaps somebody here can suggest other diagnostics. I think it might either be the virtual network card driver, or somebody rooted our ssh.

Ideas..?

For troubleshooting, try `$ ssh -L 7000:127.0.0.1:7000 user@host -N -v -v`. (You can use "-v" up to 3 times to increase verbosity.) Also, is it possible that ssh was recently updated? — Mike Sherrill 'Cat Recall', Mar 30 '13 at 23:18
You can use -v up to three times to increase verbosity. So you might look at the output of `ssh -L 7000... -N -v -v` (two v's) or `ssh -L 7000... -N -v -v -v`. — Mike Sherrill 'Cat Recall', Apr 01 '13 at 00:39
@MikeSherrill'CatRecall' A shorthand can be used as well: -vvv — jnns, Feb 08 '18 at 10:44

score 68 · Accepted Answer · answered Mar 31 '13 at 20:48

68

Problem solved:

$ ssh -L 7000:127.0.0.1:7000 user@host -N -v -v

...apparently, 'localhost' was not liked by the remote host. Yet, remote /etc/hosts contains:

::1                     localhost localhost.
127.0.0.1               localhost localhost.

while the local network interface is

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33184
        inet 127.0.0.1 netmask 0xff000000
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2

Sigh. so much for the bounty of 100rp I put on :)

answered Mar 31 '13 at 20:48

lorenzog

2,719
1
18
24

1

Ah. Well then, I won't bother to write up my comment as an answer. (Look into whether ssh prefers ipv6 addresses on your system.) – Mike Sherrill 'Cat Recall' Apr 01 '13 at 00:45
Well you suggested doubling the -v option, but that did not show anything new.. however, by making me look at the output again after a few days helped to pinpoint the problem. If you want to write up the answer, I'm more than happy to give you the bounty. – lorenzog Apr 01 '13 at 08:26
2

Actually, the important point was replacing "localhost" with "127.0.0.1". The additional "-v" arguments might have been helpful, but they weren't what I was aiming at. Thanks. – Mike Sherrill 'Cat Recall' Apr 01 '13 at 11:51
according to that post on superuser: http://superuser.com/questions/346971/ssh-tunnel-connection-refused a program configured to listen on a specific address will listen to that specific address – jopasserat Jan 01 '14 at 03:09
1

For me adding leading ":" works so command in your case would look like this: ssh -L :7000:127.0.0.1:7000 user@host -N -v -v – valentt Apr 12 '17 at 23:55
spent hours on this (1234:hostname:1234 user@hostname) as the target machine's hostname was mapped primary to IPv6 and the service was listening on IPv4. 1234:127.0.0.1:1234 user@hostname is the safest bet. – andrej May 17 '21 at 15:57

rzymek · Answer 2 · 2018-02-06T08:13:57.943

25

Although OP's problem has already been solved, I decided to share the solution for my problem, because I got the same error message from ssh and I didn't find any solution on other sites.

In my case I had to connect to the service which listens only on IPv6. I tried:

ssh -f root@192.168.0.18 -L 51005:127.0.0.1:51005 -N
ssh -f root@192.168.0.18 -L 51005:localhost:51005 -N

and a few other ways but it didn't work. Any try of connection to http://localhost:51005 causes errors like this: channel 2: open failed: connect failed: Connection refused

The solution is:

ssh -f root@192.168.0.18 -L 51005:[::1]:51005 -N

IPv6 address must be in square brackets.

edited Feb 06 '18 at 08:13

answered Sep 26 '13 at 08:23

rzymek

351
3
6

1

What if your using a ssh config file? example: "LocalForward localhost:64160 192.168.1.56:3389" – Northstrider Nov 13 '15 at 00:33
1

For me adding leading ":" works so command in your case would look like this: ssh -f root@192.168.0.18 -L :51005:127.0.0.1:51005 -N – valentt Apr 12 '17 at 23:54

score 15 · Answer 3 · answered Apr 01 '13 at 11:47

I would first try this.

$ ssh -L 7000:127.0.0.1:7000 user@host -N -v -v

You can use "-v" up to 3 times to increase verbosity.

I think this error message can arise if a firewall blocks port 7000, but you had already ruled that out. (If later readers haven't ruled that out, look at the output of netstat --numeric-ports.)

I think I might have seen this error message a long time ago, when ssh first became aware of IPV6 addresses following an update. I could be wrong about that. If you feel like experimenting, you can try the IPV6 loopback address "0:0:0:0:0:0:0:1" (or "::1").

Not a firewall on my side but a bit similar. The opened port was used by a webbrowser and there was an ad-blocker activated in the browser. The ad-blocker apparently managed to cause the above-mentioned error message ("chanel 2 ..."). After switching the ad-blocker off, everything worked. — rwoo, May 29 '20 at 11:34

score 4 · Answer 4 · answered Apr 01 '13 at 14:42

4

"...apparently, 'localhost' was not liked by the remote host. Yet, remote /etc/hosts contains:"

Except you were running ssh on the client, so 'localhost' was not liked by your client. The remote /etc/hosts file is for the remote connecting out not incoming connections.

answered Apr 01 '13 at 14:42

bilbo baggins

41
1

1

that was also confusing to me. When you type localhost in your localmachine, it gets resolved locally – Ahmadov Jan 31 '18 at 13:11

score 4 · Answer 5 · answered Apr 12 '17 at 23:53

4

For me adding leading ":" works so command in your case would look like this:

ssh -L :7000:localhost:7000 user@host -N -v

answered Apr 12 '17 at 23:53

valentt

295
3
10

Too much time has passed and I can't go back and check, but this looks great. – lorenzog Apr 13 '17 at 15:44
This was the solution for me! – michael_teter Apr 19 '21 at 07:32

score 3 · Answer 6 · answered Apr 03 '14 at 23:55

I encountered this same error while trying to connect to mysql on another server via an ssh tunnel. I found that the bind-address parameter in /etc/my.cnf on the target server was bound to my external ip (dual NIC server) rather than internal, which I had no use for.

When I set bind-address=127.0.0.1, I could successfully use my ssh tunnel as follows:

ssh -N -f -L 3307:127.0.0.1:3306 user@server.name

mysql -h 127.0.0.1 --port=3307 --protocol=TCP -uusername -ppassword

That worked for me as well. You can only bind MySQL to one address. — leeand00, Nov 23 '15 at 21:38

score 3 · Answer 7 · answered Dec 11 '14 at 19:47

I encountered this error when I was forwarding ports with a full domain name instead of localhost:

ssh -L 5900:host.name.com:5900 x11vnc

The port was being opened only for localhost, so to accept connections with a fully qualified name, I had to add a binding port description:

ssh -L *:5900:host.name.com:5900 x11vnc

which would allow connections from anywhere (so it's not that secure, use it sparingly).

score 2 · Answer 8 · answered Mar 31 '13 at 04:06

2

???

channel 2: open failed: connect failed: Connection refused

At user@host there's nothing listening port 7000, that's simple and that's all.

answered Mar 31 '13 at 04:06

poige

9,171
2
24
50

1

That's not true. There is a service running at host:7000. I also tried with other services. – lorenzog Mar 31 '13 at 20:43
2

No, then it would just hangs connecting. – RickyA Oct 10 '13 at 09:39
4

@RickyA: Actually, that's not true. If the port isn't bound the connection will be refused. I got this error from using the wrong internal port (where no service was running), the error went away when I corrected the mistake. poige is right in that if nothing is listening on the port, it will cause the error. – erb Oct 09 '15 at 09:42
so I was right (; – poige Jan 31 '21 at 03:54
For some reason the server is stopped. start it. – Hamlet Kraskian Jun 11 '21 at 21:56

score 2 · Answer 9 · answered Jul 08 '19 at 09:28

Alternative interpretation is, in my case, your typing it wrong.

user@host ~ $ ssh -vvvNL 4444:127.0.0.0.1:4444
...
channel 2: open failed: connect failed: Name or service not known

What happens here is the IP address has one too many zeroes, thus not being a valid address. So ssh treats it as a domain name instead which it can't resolve. Oops!

PS: I supplement this so we have comprehensive list of possible problems when troubleshooting same symptoms.

score 1 · Answer 10 · answered Sep 07 '21 at 02:31

For the benefit of others who made a silly mistake like I did (one that isn't mentioned in other answers): Make sure your remote machine actually has a process listening on the port that you're trying to tunnel to!

As @Kenster says here:

When you connect to port 8783 on your local system, that connection is tunneled through your ssh link to the ssh server on server.com. From there, the ssh server makes TCP connection to localhost port 8783 and relays data between the tunneled connection and the connection to target of the tunnel. The "connection refused" error is coming from the ssh server on server.com when it tries to make the TCP connection to the target of the tunnel. "Connection refused" means that a connection attempt was rejected. The simplest explanation for the rejection is that, on server.com, there's nothing listening for connections on localhost port 8783. In other words, the server software that you were trying to tunnel to isn't running, or else it is running but it's not listening on that port.

So first check that your remote process is running, and then check that it's actually listening on the port that you're trying to connect to.

On your remote machine you can run any one of these (depending on the packages available on your distribution) to check which ports are being listened to:

sudo lsof -i -P -n | grep LISTEN
sudo netstat -tulpn | grep LISTEN
sudo ss -tulpn | grep LISTEN

If your command is ssh -L -N 7000:127.0.0.1:6000 user@host and you can't see anything listening on 6000, then that's your problem - you need to work out why the process isn't listening on a port, or on the port that you expect.

score 1 · Answer 11 · answered Apr 27 '17 at 07:48

1

I received the same error message:

channel 3: open failed: connect failed: Connection refused

And the cause was human error - me trying to access a different port on the remote host than the one I specified.

Just thought I'll share that, although this is probably not the reason why most of you are experiencing this error.

answered Apr 27 '17 at 07:48

Roei Bahumi

111
2

In my case: this is exactly what I was doing. Such a stupid mistake but it took this answer to make me check the port. Doh. – Ken Sharp Apr 19 '18 at 12:55

score 1 · Answer 12 · answered Sep 17 '17 at 03:11

1

For me, I was trying ssh -L <port>:<remote server IP>:<port> <login>@<remote server IP> when I should have been doing ssh -L <port>:127.0.0.1:<port> <login>@<remote server IP>.

I hope this helps someone!

answered Sep 17 '17 at 03:11

ryanwc

11
1

score 0 · Answer 13 · answered Aug 03 '22 at 13:49

0

For whatever reason, my issue was fixed by restarting the AWS EC2 where the mongo instance was. Almost as if it was caused by me trying to connect to it too early and the ports got messed up or something..

answered Aug 03 '22 at 13:49

Akaisteph7

101
1

score 0 · Answer 14 · edited Nov 30 '19 at 15:54

0

It lacks the IP address --ip=n.n.n.n at the end of the line. You should specify exactly which IP to connect.

edited Nov 30 '19 at 15:54

kenlukas

2,886
2
14
25

answered Nov 30 '19 at 13:30

Nurlybek Amangeldiuly

1
1

score 0 · Answer 15 · answered Dec 01 '19 at 03:29

0

What worked for me was switching the order of the commands.

So basically -

$ ssh user@host -L 7000:localhost:7000 -N

Strange

answered Dec 01 '19 at 03:29

Bugsy

1
1

ssh tunnel refusing connections with "channel 2: open failed"

15 Answers15