Home / server / Questions / 489192
Accepted
lorenzog
Asked: 2013-03-20 01:32:37 +0800 CST

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

  • 772

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..?

networking

15 Answers

  1. Best Answer

    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 :)

    • 68

  2. 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 [email protected] -L 51005:127.0.0.1:51005 -N
ssh -f [email protected] -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 [email protected] -L 51005:[::1]:51005 -N

    IPv6 address must be in square brackets.

    • 25

  3. 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").

    • 15

  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.

    • 4

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

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

  6. 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 [email protected]

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

  7. 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).

    • 3

  8. ???

    channel 2: open failed: connect failed: Connection refused

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

    • 2

  9. 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.

    • 2

  10. 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.

    • 1