channel 3: open failed: connect failed: Connection refused

channel 3: open failed: connect failed: Connection refused

Post by bluema » Sun, 25 Nov 2007 06:22:35


I have done a lot of googling and have not been able to figure out
what the above error message means.

My specific situation is as follows:
Case 1: ssh from linux box to linux box
Screen1: Client> ssh Server -L 9546:127.0.0.1:9546

Screen2: Client> telnet 127.0.0.1 9546

Then on Screen1 (which is now ssh'd into the Server, I see the
following message:
channel 3: open failed: connect failed: Connection refused

There is nothing actually running on port 9546 of the
Server. I just use telnet as a means of sending packets to the
port. The same thing happens no matter what program I use to
tickle that port.

Case 2: Same as case 1 but using cygwin from a Windoze machine.
Here I don't get any problems.


So, any idea why I get the error in Case 1 and what does it mean?
Also, why does it work in Case 2?

Let me know if you need any more details.

Thanks
 
 
 

channel 3: open failed: connect failed: Connection refused

Post by per » Sun, 25 Nov 2007 22:19:09

In article < XXXX@XXXXX.COM > blueman
< XXXX@XXXXX.COM > writes:

Which is exactly what the message is telling you. Your instructions to
ssh/sshd are: When I connect to the local port 9546, forward that
connection to the server and connect to port 9546 there. When you
actually do the connect, you are duly informed that the remote
connection failed because nothing was listening on that port on the
server. You can try e.g. 'telnet localhost 12345', i.e. connect to a
*local* port where nothing is listening - it will give the same
"Connection refused".


Meaning what? You actually get connected to something at port 9546 on
the server even though there's nothing there (that would be quite a
feature)? Or you just don't get an appropriate error message (a bug)?

--Per Hedeland
XXXX@XXXXX.COM

 
 
 

channel 3: open failed: connect failed: Connection refused

Post by bluema » Mon, 26 Nov 2007 07:58:57


XXXX@XXXXX.COM (Per Hedeland) writes:


OK. I assume then the problem is that for some reason the cygwin ssh
client doesn't generate the right error message. I had assumed that
the error message was generated on the server side and therefore
didn't understand the different behavior.

So, presumably there is a problem with the cygwin implementation of
the ssh client???
 
 
 

channel 3: open failed: connect failed: Connection refused

Post by per » Mon, 26 Nov 2007 10:48:16

In article < XXXX@XXXXX.COM > blueman
< XXXX@XXXXX.COM > writes:

Well, at least some information about the error has to be generated on
the server since it is the server that detects the problem - I don't how
much of the actual text is generated by server vs client, but it would
have to be the client that actually prints the final message I believe
(based on the error info being passed from the server in the "control
channel where the client requested the connection).


If you don't get any error message from it, it would seem that it
doesn't properly show such error message, but I won't pass such a
judgement based on someone else's observations - maybe there's something
in your environment or setup that prevents it from showing the messages,
maybe it's supposed to show them somewhere else - I have no idea, I have
never used it. And if it works to make forwarded connections to ports
where there's actually something listening, maybe it's not a big deal.

--Per Hedeland
XXXX@XXXXX.COM
 
 
 

channel 3: open failed: connect failed: Connection refused

Post by bluema » Wed, 28 Nov 2007 04:52:12


XXXX@XXXXX.COM (Per Hedeland) writes:

OK. Well, let me explain what I am doing in more detail and maybe
someone can explain what is going wrong.

I am trying to tunnel smb (cifs) over ssh by redireting port 445 over
a non-priveleged port on both ends. On the client end, the command
mount.cifs allows you to specify an arbitrary port and on the server
end I am using iptables to route from the ssh-forwarded non-privileged
port back to port 445 where smbd (the samba server) listens.

Specifically,
1. On the ssh and smb server I am using the "PREROUTING" iptable to
re-route incoming traffice from a non-privileged port (say 1445) to
445, using the following rule:

-A PREROUTING -p tcp --dport 1445 -j DNAT --to 127.0.0.1:445

(My intention is that this should effectively "trick" the smbd
server that it is listening in also on port 1445)

2. On the ssh client, I do the following 2 things:
a] First, tunnel port 1445, using:
ssh servermachine -L 1445:127.0.0.1:1445

b] Use mount.cifs over port 1445 to route the smb mount command to
localhost on port 1445

mount.cifs //127.0.0.1/myshare /mnt/mymount -o username=myname,ip=127.0.0.1,port=1445


I would think that I would have implemented this tunnel:

SMB mount command
-> Client machine 127.0.0.1:1445
-> Server machine 127.0.0.1:1445
-> Server machine 127.0.0.1:445

When I try to mount the share remotely as above, I get the response:
channel 3: open failed: connect failed: Connection refused
which you explained as meaning that nothing is presumably listening in
on 127.0.0.1:1445

However, it does work if I run the mount command locally on the server
which would seem to indicate that the iptables redirect is working and
that smbd is indeed effectively listening in on 127.0.0.1:1445

So, I guess I'm stuck and not sure why things aren't working here...
 
 
 

channel 3: open failed: connect failed: Connection refused

Post by per » Sat, 01 Dec 2007 08:04:55

In article < XXXX@XXXXX.COM > blueman
< XXXX@XXXXX.COM > writes:

Well, this is straying from the subject of this group, but try the
OUTPUT table instead. PREROUTING is for packets arriving from the
"outside" to the host, and while your packets sort-of are, iptables
knows nothing about that - as far as it can determine (and technically
correct), they are locally originated by the sshd process.

However, there's no point to this iptables thing - just do the ssh
forwarding as -L1445:127.0.0.1:445 instead. You don't need privileges to
connect to a "privileged" port, only to listen on it.

--Per Hedeland
XXXX@XXXXX.COM