OpenSSH 3.4p1 port forwarding problem
Steve M. Fabac, Jr.
tunnel to
allow Carbon Copy on the local Windows machine to connect to CC on a
Windows
host at the client's office.
When I proposed this 2 years ago, I had set up a test at another
client's office
and I got it to work with very little trouble. (SCO 5.0.5 Enterprise
with
either ssh_3.0.p1_os5.tar or ssh-504.tar. I don't have access to the
machine as
the company went out of business)
Finally, the client using CC to connect from home to the office using
dial-up has
installed DSL at both end and I have been unable to get CC working over
ssh3.1p1.
I downloaded openssh3.4p1 in VOLS from SKUNKWARE and still no luck.
I'm using TerraTermPro with SSH extensions to make the connection. I
configured
TTPRO to forward 1680 on the local Windows pc to 192.168.10.34:1680 at
the
client site.
When I try to connect with CC to "localhost" I get the following
message:
"A program on the local machine attempted to connect to a forwarded
port.
The forwarding request was denied by the server. The connection has been
closed."
When I model the connection on my office LAN, I connect to server
192.168.111.231
and set TTPRO to forward 1680:192.168.111.10:1680 (the local machine
with CC)
and use CC to connect to "localhost" I then get the message:
"Host with IP number 192.168.111.231 tried to connect to
forwarded local port 1680. This could be some kind of hostile attack."
Indicating that forwarding is attempted. When I change the forwarding
request to
point to a nonexistent host (local 1680:remote 192.168.111.34):1680, the
following
appears when running netstat -a:
tcp 0 0 pentium.1301 192.168.111.34.1680
SYN_SENT
tcp 0 0 localhost.2022 *.*
LISTEN
tcp 0 0 pentium.22 smf4861.1054
ESTABLISHED
tcp 0 4 pentium.telnet smf4861.1022
ESTABLISHED
tcp 0 0 pentium.telnet smf4861.1023
ESTABLISHED
tcp 0 0 pentium.nb-ssn smf4861.nterm
ESTABLISHED
tcp 0 0 *.1266 *.*
LISTEN
tcp 0 0 *.1265 *.*
LISTEN
tcp 0 0 *.nb-ssn *.*
LISTEN
:q
Again, indicating that port forwarding is configured and should be
working.
Yesterday, I was on-site at the client and set up CC on another Win98
system on the
local network. I was able to use CC to connect to the target machine
directly
192.168.10.39 -> 192.168.10.34. But when I installed TTPRO on the .39
machine
and used it to connect to 192.168.10.33 (SCO 5.0.5) and setup forwarding
as local 1680:remote 192.168.10.34:1680.
I got the same failed connection:
"A program on the local machine attempted to connect to a forwarded
port.
The forwarding request was denied by the server. The connection has been
closed."
Changing the forwarding to local 1680:remote 192.168.10.101:1680,
results in a timed
out connection attempt and netstat -a showing:
tcp 0 0 wwcpa.1301 192.168.10.101.1680
SYN_SENT
tcp 0 0 localhost.2022 *.*
LISTEN
tcp 0 0 wwcpa.22 randy.1054
ESTABLISHED
Again, appearing to show that forwarding is being attempted. What I have
not been
able to determine is why CC is failing to connect to the target machine
over the
forwarded port.
These tests were conducted after adding: "AllowTcpForwarding yes" to the
default /usr/local/etc/sshd_config file. Adding "GatewayPorts yes" does
not
correct the failure.
Does anyone have any information on how to change the sshd_config file
to
complete port forwarding to allow CC to communicate over the ssh tunnel?
All suggestions are welcome.
--
Steve Fabac
S.M. Fabac & Associates
816/765-1670
Steve Fabac
:1680), the following appears when running netstat -a:
tcp 0 0 pentium.1301 192.168.111.34.1680 SYN_SENT
tcp 0 0 localhost.2022 *.* LISTEN
tcp 0 0 pentium.22 smf4861.1054 ESTABLISHED
tcp 0 4 pentium.telnet smf4861.1022 ESTABLISHED
tcp 0 0 pentium.telnet smf4861.1023 ESTABLISHED
tcp 0 0 pentium.nb-ssn smf4861.nterm ESTABLISHED
tcp 0 0 *.1266 *.* LISTEN
tcp 0 0 *.1265 *.* LISTEN
tcp 0 0 *.nb-ssn *.* LISTEN
:q
Again, indicating that port forwarding is configured and should be
working.
Yesterday, I was on-site at the client and set up CC on another Win98
system on the local network. I was able to use CC to connect to the
target machine directly 192.168.10.39 -> 192.168.10.34.
But when I installed TTPRO on the .39 machine and used it to connect
to 192.168.10.33 (SCO 5.0.5) and set up forwarding as
Steve Fabac
>
> > Reposted after cleaning text wrap problem
>
> I am attempting to setup port forwarding of port 1680 over the SSH
> tunnel to allow Carbon Copy on the local Windows machine to connect
> to CC on a Windows host at the client's office.
>
> When I proposed this 2 years ago, I had set up a test at another
> client's office and I got it to work with very little trouble.
> (SCO 5.0.5 Enterprise with either ssh_3.0.p1_os5.tar or ssh-504.tar.
> I don't have access to the machine as the company went out of business)
> But when I installed TTPRO on the .39 machine and used it to connect
> to 192.168.10.33 (SCO 5.0.5) and set up forwarding as
> local 1680:remote 192.168.10.34:1680.
>
> I got the same failed connection: "A program on the local machine
> attempted to connect to a forwarded port. The forwarding request
> was denied by the server. The connection has been closed."
As Bela suggested, I removed openssh3.4p1 and reverted to installing
ssh from ssh-504.tar (sshd version OpenSSH_2.2.0p1) and tested it.
The problem still remained but the sshd -ddd output was different:
> debug: Attempting authentication for smf.
> Accepted password for smf from 192.168.10.40 port 1616
> debug: session_new: init
> debug: session_new: session 0
> debug: Received TCP/IP port forwarding request.
> debug: Local forwarding listening on 127.0.0.1 port 2022.
> debug: fd 5 setting O_NONBLOCK
> debug: channel 0: new [port listener]
> debug: Allocating pty.
> debug: Entering interactive session.
> debug: no set_nonblock for tty fd 9
> debug: no set_nonblock for tty fd 10
> debug: server_init_dispatch_13
> debug: server_init_dispatch_15
> debug: tvp!=NULL kid 0 mili 10
repeated 4 times.
> debug: Window change received.
> debug: tvp!=NULL kid 0 mili 10
repeated 5 more times
> error: connect 192.168.10.34 port 1680: Connection refused
> error: connect 192.168.10.34 port 1680: failed.
> debug: tvp!=NULL kid 0 mili 10
repeated 4 more times
> debug: Received SIGCHLD.
> debug: tvp!=NULL kid 1 mili 10
> debug: tvp!=NULL kid 1 mili 100
> debug: End of interactive session; stdin 6, stdout (read 461, sent 461), stderr 0 bytes.
> debug: channel_free: channel 0: status: The following connections are open:
>
> debug: Command exited with status 0.
> debug: Received exit confirmation.
> debug: session_pty_cleanup: session 0 release /dev/ttyp4
> Closing connection to 192.168.10.40
> debug: writing PRNG seed to file //.ssh/prng_seed
Where openssh3.4p1 sshd -ddd resulted in:
> Accepted password for smf from 192.168.10.40 port 1609
> debug1: monitor_child_preauth: smf has been authenticated by privileged process
> debug3: mm_get_keystate: Waiting for new keys
> debug3: mm_request_receive_expect entering: type 24
> debug3: mm_request_receive entering
> debug3: mm_get_keystate: Getting compression state
> debug3: mm_get_keystate: Getting Network I/O buffers
> debug1: cipher_init: set keylen (16 -> 32)
> debug1: cipher_init: set keylen (16 -> 32)
> debug3: cipher_set_keyiv: Installed 3DES IV
> debug3: cipher_set_keyiv: Installed 3DES IV
> debug1: session_new: init
> debug1: session_new: session 0
> debug1: Installing crc compensation attack detector.
> debug2: SSH_PROTOFLAG_SCREEN_NUMBER: 1
> debug1: X11 forwarding disabled in server configuration file.
> debug1: Received TCP/IP port forwarding request.
> debug1: Local forwarding listening on 0.0.0.0 port 2022.
> debug1: fd 7 setting O_NONBLOCK
> debug2: fd 7 is O_NONBLOCK
> debug1: channel 0: new [port listener]
> debug1: Allocating pty.
> debug1: session_pty_req: session 0 alloc /dev/ttyp2
> debug3: tty_parse_modes: 1 3
> debug3: tty_parse_modes: 2 28
> debug3: tty_parse_modes: 3 8
> debug3: tty_parse_modes: 4 21
> debug3: tty_parse_modes: 5 4
> debug1: fd 4 setting TCP_NODELAY
> debug1: Entering interactive session.
> debug1: fd 10 setting O_NONBLOCK
> debug2: fd 11 is O_NONBLOCK
> debug1: fd 13 setting O_NONBLOCK
> debug1: fd 14 setting O_NONBLOCK
> debug1: server_init_dispatch_13
> debug1: server_init_dispatch_15
> debug1: Window change received.
> debug1: fd 15 setting TCP_NODELAY
> debug2: fd 15 is O_NONBLOCK
> debug2: fd 15 is O_NONBLOCK
> debug1: channel 1: new [127.0.0.1]
> debug3: channel 1: waiting for connection
> debug1: channel 1: not connected: Connection refused
> debug1: channel 1: zombie
> debug1: channel 1: garbage collecting
> debug1: channel_free: channel 1: 127.0.0.1, nchannels 2
> debug3: channel_free: status: The following connections are open:
>
> debug3: channel_close_fds: channel 1: r 15 w 15 e -1
> debug1: Received SIGCHLD.
> debug2: notify_done: reading
> debug1: End of interactive session; stdin 6, stdout (read 596, sent 596), stderr 0 bytes.
> debug1: channel_free: channel 0: port listener, nchannels 1
> debug3: channel_free: status: The following connections are open:
>
> debug3: channel_close_fds: channel 0: r 7 w 7 e -1
> debug1: Command exited with status 0.
> debug1: Received exit confirmation.
> debug1: session_close: session 0 pid 4023
> debug1: session_pty_cleanup: session 0 release /dev/ttyp2
> Closing connection to 192.168.10.40
Note the more descriptive debug output of ssh2.2p1 for the forwarded
port failure:
> error: connect 192.168.10.34 port 1680: Connection refused
> error: connect 192.168.10.34 port 1680: failed.
vs ssh3.4p1:
> debug1: channel 1: new [127.0.0.1]
> debug3: channel 1: waiting for connection
> debug1: channel 1: not connected: Connection refused
> debug1: channel 1: zombie
> debug1: channel 1: garbage collecting
With 2.2.0p1 debug information clearly indicating that the connection on
port 1680 was being refused by 192.168.10.34 and is not a problem with
ssh port forwarding, I reviewed the "wait for connection" configuration
tab for CC and noted that "use internet" was not checked.
I checked "use internet" and un-checked "use network broadcasts."
Then deleted the default "Internet Locator Servers" leaving the
configuration field blank.(This is the recommended configuration
when connecting through a firewall on port 1680 when not using
Internet Locator Server to connect by name.)
When I tested the forwarded connection on port 1680 by pointing CC to
localhost on the Win98 client machine, I was able to successfully
connect to CC waiting for a TCP connection on 192.168.10.34.
I un-installed SSH2.2.0p1 and reinstalled openssh3.4p1 and with the
default sshd_config file was able to use CC over the forwarded
connection.
So, by not being familiar with the debug output of 3.4p1 I was unable to
identify the source of the connection problem. Only when I re-installed
ssh2.2.0p1, and obtained an indication that clearly showed that CC on
the target machine was rejecting the connection, I was chasing problems
with ssh when the problem was an improper configuration choice in CC.
Thanks for the utility of openssh3.4p1, but "Bronx Cheer" for adopting
the cryptic debug messages.