Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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

share|improve this question
1  
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
    
The output log I pasted was gathered with -v already. –  lorenzog Mar 31 '13 at 20:46
    
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 1 '13 at 0:39

6 Answers 6

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

share|improve this answer

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

share|improve this answer
up vote 0 down vote accepted

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

share|improve this answer
    
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 1 '13 at 0: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 1 '13 at 8:26
    
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 1 '13 at 11:51
    
according to that post on superuser: 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 1 at 3:09

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

share|improve this answer

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
share|improve this answer

???

channel 2: open failed: connect failed: Connection refused

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

share|improve this answer
    
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
1  
No, then it would just hangs connecting. –  RickyA Oct 10 '13 at 9:39

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.