Take the 2-minute tour ×

EDIT (for clarification)

              Windows Client                  Remote Linux Server
 ____________            ____________            ____________  
|            |          |            |          |            | 
| Firefox    | -------> | PuTTY      | -------> | sshd       | ---> (The Internet)
|____________|          |____________|          |____________| 
Network settings:    Interactive SSH Session     sshd_config
Manual Proxy:        (manual login)              posted below 
SOCKS Host:          Configuration Settings:
localhost:9870       Connection|SSH|Tunnels
                     set to D9870

The above configuration worked perfectly fine until our ISP changed the server to a new one. By "perfectly fine" I mean I could browse the entire internet, including websites normally blocked in China. It still works perfectly fine when I login to another SSH session on another server as a test (a production web-server, not one I can purpose for this). In all cases the manual SSH login works as normal.

I need to figure out why it doesn't work with the new server since the sole purpose of that server is to provide this function to our company.


Our server provider recently changed our server and IP address. The hard-disk from the old server was moved to the new one, and the configuration was supposed to be identical other than the IP address change.

Prior to the move I was using PuTTY on a Windows box to tunnel web-traffic as a SOCKS proxy through the server using a Dynamic port set as 9870. After the move, I reconfigured the PuTTY to point to the new IP. But the tunnel no longer works (times out when requesting pages in Firefox).

I don't have access to the old server. But the sshd_config on the new server is:

#       $OpenBSD: sshd_config,v 1.73 2005/12/06 22:38:28 reyk Exp $

# sshd_config(5) for more information.


# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options change a
# default value.

#Port 22
#Protocol 2,1
Protocol 2
#AddressFamily any
#ListenAddress ::

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 768

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
SyslogFacility AUTHPRIV
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile     .ssh/authorized_keys

#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
#IgnoreRhosts yes

#PasswordAuthentication yes
#PermitEmptyPasswords no
PasswordAuthentication yes

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
GSSAPIAuthentication yes
#GSSAPICleanupCredentials yes
GSSAPICleanupCredentials yes

# be allowed through the ChallengeResponseAuthentication mechanism.
# Depending on your PAM configuration, this may bypass the setting of
# PasswordAuthentication, PermitEmptyPasswords, and
# "PermitRootLogin without-password". If you just want the PAM account and
# ChallengeResponseAuthentication=no
#UsePAM no
UsePAM yes

# Accept locale-related environment variables
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#ShowPatchLevel no
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
#PermitTunnel no

# no default banner path
#Banner /some/path

# override default of no subsystems
Subsystem       sftp    /usr/libexec/openssh/sftp-server


So far I have tried all the suggestions in the responses. Still not working. Is it possible the firewall at the datacenter where the server is hosted is preventing the ssh-tunnel? I have tried D80 as my dynamic port in PuTTY, but this also doesn't work (should it?). The server is primarily a web-server, but currently we are not running any websites on it, although Apache is running.

I have looked in the putty.log and although I can't make much sense of it, there is the following section:

Event Log: Opened channel for session
Event Log: Local port 9870 SOCKS dynamic forwarding
Outgoing packet type 98 / 0x62 (SSH2_MSG_CHANNEL_REQUEST)
  00000000  00 00 00 00 00 00 00 07 70 74 79 2d 72 65 71 01  ........pty-req.
  00000010  00 00 00 05 78 74 65 72 6d 00 00 00 50 00 00 00  ....xterm...P...
  00000020  18 00 00 00 00 00 00 00 00 00 00 00 10 03 00 00  ................
  00000030  00 7f 80 00 00 96 00 81 00 00 96 00 00           .............
Outgoing raw data
  00000000  ed 9b 4d c5 0c 7f c4 67 e7 ad 96 3f 5a fd 26 fb  ..M....g...?Z.&.
  00000010  48 27 cd e9 b9 bd 4f 52 2c e0 d3 4e de 62 5d ab  H'....OR,..N.b].
  00000020  c0 10 51 a9 80 8e 68 9c 6d 4c bf ab 75 e9 e1 7a  ..Q...h.mL..u..z
  00000030  bf 66 e3 ff 6f 94 fe f9 9e 78 3d b5 e0 a6 8c fd  .f..o....x=.....
  00000040  61 5b 69 b4 ec 7c 30 a0 29 87 9c 2c d2 94 57 bd  a[i..|0.)..,..W.
  00000050  6e 4b 9c 6c d0 39 cc 46 66 3c 5d 7d dc 37 76 cf  nK.l.9.Ff<]}.7v.
  00000060  9b c7 24 46                                      ..$F
Incoming raw data
  00000000  30 ae 0c b2 25 a9 c1 73 47 1f 2d 6a 5e 5b 7f 88  0...%..sG.-j^[..
  00000010  99 99 0c 28 ff 87 5b 0e 82 61 f5 33 81 3d 8a 7d  ...(..[..a.3.=.}
  00000020  d6 b7 3d 6f                                      ..=o
Incoming packet type 99 / 0x63 (SSH2_MSG_CHANNEL_SUCCESS)
  00000000  00 00 01 00      ............

Which to me seems to look like the port-forwarding was accepted by the remote server.


I have tried connecting to another server that I regularly SSH to with exactly the same SSH tunnels setting in PuTTY (D9870)

This worked instantly (with Firefox seeing PuTTY it as a SOCKS proxy) and I was immediately able to access sites being blocked in my location [China].

What was most interesting about this test was that the netstat -an --inet test prescribed by respondents below on the server also did not show

I think I need to point out clearly that I'm using a Windows machine for the PuTTY/Firefox client. And I'm trying to use the remote Linux server to tunnel web-traffic through so I can securely get access to websites being blocked in China. It seems to me that the netstat test suggested was supposed to be run on my Windows box (in which case it's using the wrong netstat syntax).

share|improve this question
Can the remote Linux server establish outbound connections to TCP port 80? For instance, if you "telnet www.google.com 80" from the server, do you get "Connection established"? Or does it just hang? –  James Sneeringer Aug 21 '09 at 4:39
What happens to FF when you try to access a page: It shows the page of connection refused or shows a blank page? Which version of the sshd? Have you tried to remove the server key from putty? –  Leonel Martins Aug 21 '09 at 22:05
Firefox times out while trying to connect the server. Seems to me the SOCKS proxy (PuTTY) is accepting the requests, sending them through the ssh-tunnel, and then nothing comes back. –  rwired Aug 23 '09 at 5:29
James Sneeringer was correct. The new server was behind a firewall which was blocking outgoing web requests. James, could you submit your solution as a separate answer and I will select it as the accepted one. –  rwired Aug 24 '09 at 8:26
add comment

6 Answers

up vote 4 down vote accepted

At rwired's request, I'm reposting my previous comment as an answer, which was:


The intended implication was that something is blocking the outbound connection, which rwired discovered was indeed the case.

share|improve this answer
add comment


GatewayPorts yes

in your sshd_config. It defaults to "no", which prevents you from using remote port forwarding (ssh -R) to any address other than the remote SSH server itself.

share|improve this answer
Remember to restart ssh after the change –  Dave Rickman Aug 12 '09 at 4:28
"GatewayPorts no" will prevent other remote hosts to use the forwarding. This won't help. –  innaM Aug 12 '09 at 5:27
James, I want to give you the bounty, see my comment to your comment to the main question. Also see here meta.stackoverflow.com/questions/17146/… –  rwired Aug 25 '09 at 8:36
add comment

IMHO your sshd_config looks ok. Maybe sshd is started with additional command line parameters that set AllowTcpForwarding to no? If you do a "netstat -an --inet" on the server, does it show the forwarded port? Have you make sure your socks proxy is working correctly?


The output of netstat should look something like this:

tcp        0      0*               LISTEN
share|improve this answer
netstat is not showing my forwarded port. What would the line from netstat look like if it was working? Also I checked /etc/init.d/sshd and there are no additional options being used to start sshd. I'm restarting it using /etc/init.d/sshd restart. The GatewayPorts setting had no effect. I also tried changing PermitTunnel to ethernet and point-to-point, but these didn't help either. The SOCKS proxy was working fine with the old server. I didn't change anything else in PuTTY except for the IP. –  rwired Aug 12 '09 at 6:34
Is the proxy running on the server that does the tunneling? Or is it ruunig on a third machine? Maybe you should try to explicitly set AllowTcpForwarding to no in your sshd_config. And you should make sure that the config file you posted is really the one being used. –  innaM Aug 12 '09 at 6:37
add comment

Have you checked to see if you public key file is actually on the server installed under ~/.ssh/authorized_keys

It's possible that it's not there at all and is allowing you to fall back to using a plain text login so therefore looking like it should be working.

share|improve this answer
I wasn't using a key on the old (working) server, and I'm not on the new (broken) server. I was using a manual login and leaving PuTTY in an interactive terminal all the time. This is mainly because this server is being setup as part of a broader project under development and testing, and the need for automatic login at this stage isn't necessary. –  rwired Aug 21 '09 at 6:02
add comment

First of all try to manually make an ssh connection using putty to the server, thus assuring there is no server IP mismatch, MITM attach prevention and so on, that ssh is putting in act and that may be not shown in a non interactive ssh session through putty.

If this works ok, then you really have to see the tunnel listening for connections on the localhost port through netstat, if it isn't I suspect the issue would not be ssh bounded

As a further debug you can then enable Putty logging in order to see where the problem really is.

EDIT: In the putty log you posted the only info making me curious is the terminal... My hypothesis is that the new server could not support such an "evoluted terminal", try downgrade the terminal to the ancient vt100. There is a quite weak possibility this can be the issue...

share|improve this answer
If the problem isn't ssh bounded then where could it be? Could it be a firewall issue at the datacenter where the server is hosted? –  rwired Aug 18 '09 at 7:04
Have you already made the debugging stuff I suggested? What results? –  AlberT Aug 18 '09 at 7:39
I can manually ssh to the server no problem. See my EDITS above for the putty.log and other debugging. –  rwired Aug 19 '09 at 8:19
You can manually ssh to your server from what? The Machine that is running the tunnel, using the same user and the same client? –  Kyle Brandt Aug 19 '09 at 16:50
Yes same username, same client (PuTTY) on the same machine. –  rwired Aug 20 '09 at 5:03
add comment

When the server changed you should have gotten a warning about a new host key. You should have accepted the new key, possibly clearing the old key first. Did you do that? I believe if you have the wrong host key ssh will sometimes allow you to open an interactive session but will not forward ports

PuTTY stores its keys in the registry in HKEY_CURRENT_USER\Software\SimonTatham\PuTTY (this is like the known_hosts files in OpenSSH). You can try hand-deleting keys from there. Or if you want to reset PuTTY's settings entirely and start over, try putty -cleanup.

If that's not your problem, you can also debug further with a verbose login. Try running "plink -v hostname" and looking at the error. You can also create a tunnel manually via plink; you may need to try those options to get the error to appear in plink. As a last resort, post the logs from plink -v and we can debug further.

share|improve this answer
add comment

Your Answer


