EDIT (para esclarecimentos)
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
A configuração acima funcionou perfeitamente bem até o nosso ISP mudar o servidor para um novo. Por "perfeitamente bem" quero dizer que eu poderia navegar em toda a Internet, incluindo sites normalmente bloqueados na China. Ele ainda funciona perfeitamente quando eu logro em outra sessão SSH em outro servidor como um teste (um servidor web de produção, nenhum que eu possa usar para isso). Em todos os casos, o login SSH manual funciona normalmente.
Eu preciso descobrir por que ele não funciona com o novo servidor, já que o único propósito desse servidor é fornecer essa função para nossa empresa.
POSTURA ANTERIOR
Nosso provedor de servidor mudou recentemente nosso servidor e endereço IP. O disco rígido do servidor antigo foi movido para o novo, e a configuração deveria ser idêntica à alteração do endereço IP.
Antes da mudança eu estava usando PuTTY em uma caixa do Windows para encapsular o tráfego da web como um proxy SOCKS através do servidor usando uma porta dinâmica definida como 9870. Após a mudança, eu reconfigurei o PuTTY para apontar para o novo IP. Mas o túnel não funciona mais (expira ao solicitar páginas no Firefox).Eu não tenho acesso ao servidor antigo. Mas o sshd_config no novo servidor é:
# $OpenBSD: sshd_config,v 1.73 2005/12/06 22:38:28 reyk Exp $
# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.
# This sshd was compiled with PATH=/usr/local/bin:/bin:/usr/bin
# 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 0.0.0.0
#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
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes
# To disable tunneled clear text passwords, change to no here!
#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
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# 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
# session checks to run without PAM authentication, then enable this but set
# ChallengeResponseAuthentication=no
#UsePAM no
UsePAM yes
# Accept locale-related environment variables
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL
#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
EDITAR: -
Até agora tentei todas as sugestões nas respostas. Ainda não funciona. É possível que o firewall no datacenter em que o servidor está hospedado esteja impedindo o ssh-tunnel? Eu tentei D80 como minha porta dinâmica no PuTTY, mas isso também não funciona (deveria?). O servidor é basicamente um servidor web, mas atualmente não estamos executando nenhum site nele, embora o Apache esteja em execução.
Eu olhei no putty.log e, embora eu não possa fazer muito sentido, há a seguinte seção:
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 ............
O que me parece parece que o encaminhamento de porta foi aceito pelo servidor remoto.
EDITAR: -
Eu tentei conectar a outro servidor que eu regularmente SSH para com exatamente a mesma configuração de túneis SSH no PuTTY (D9870)
Isso funcionou instantaneamente (com o Firefox vendo o PuTTY como um proxy SOCKS) e eu pude imediatamente acessar sites sendo bloqueados em minha localização [China].
O que foi mais interessante sobre este teste foi que o teste netstat -an --inet prescrito pelos entrevistados abaixo no servidor também não mostra 127.0.0.1:9870 .
Acho que devo salientar claramente que estou usando uma máquina Windows para o cliente PuTTY / Firefox. E estou tentando usar o servidor Linux remoto para encapsular o tráfego da web, para que eu possa acessar com segurança sites bloqueados na China. Parece-me que o teste netstat sugerido deveria ser executado na minha caixa do Windows (caso em que ele está usando a sintaxe errada do netstat).
A pedido do rwired, estou repostando meu comentário anterior como resposta, que foi:
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?
A implicação pretendida era que algo está bloqueando a conexão de saída, o que foi descoberto na verdade.
Definir
GatewayPorts yes
no seu sshd_config . O padrão é "não", o que impede que você use o encaminhamento de porta remota ( ssh -R ) para qualquer endereço diferente do próprio servidor SSH remoto.
IMHO seu sshd_config parece ok. Talvez o sshd seja iniciado com parâmetros de linha de comando adicionais que definem AllowTcpForwarding como no? Se você fizer um "netstat -an --inet" no servidor, ele mostrará a porta encaminhada? Você tem certeza que seu proxy de meias está funcionando corretamente?
EDITAR:
A saída do netstat deve ser algo como isto:
tcp 0 0 127.0.0.1:9870 0.0.0.0:* LISTEN
Você verificou se o arquivo de chave pública está realmente no servidor instalado em ~ / .ssh / authorized_keys
É possível que não esteja lá e esteja permitindo que você volte a usar um login de texto simples, portanto, parece que deve estar funcionando.
Primeiro, tente fazer manualmente uma conexão ssh usando putty no servidor, assegurando assim que não haja incompatibilidade de IP do servidor, prevenção de anexação do MITM e assim por diante, que o ssh esteja colocando em ação e que não seja mostrado em um arquivo. sessão ssh interativa através de putty.
Se isto funcionar bem, então você realmente tem que ver o túnel escutando conexões na porta localhost através do netstat, se não estiver, suspeito que o problema não seja limitado por ssh
Como depuração adicional, você pode ativar o registro de Putty para ver onde o problema realmente é.
EDITAR: No log putty você postou a única informação que me deixa curioso é o terminal ... Minha hipótese é que o novo servidor não suportaria tal "terminal evoluído", tente rebaixar o terminal para o antigo vt100. Existe uma possibilidade bastante fraca, esta pode ser a questão ...
Quando o servidor for alterado, você deve ter recebido um aviso sobre uma nova chave de host. Você deveria ter aceitado a nova chave, possivelmente limpando a chave antiga primeiro. Você fez isso? Acredito que se você tiver a chave errada do host, o ssh às vezes permitirá que você abra uma sessão interativa, mas não encaminhará as portas
PuTTY armazena suas chaves no registro em HKEY_CURRENT_USER \ Software \ SimonTatham \ PuTTY (é como os arquivos known_hosts no OpenSSH). Você pode tentar excluir as chaves manualmente de lá. Ou se você quiser redefinir totalmente as configurações do PuTTY e começar de novo, tente putty -cleanup .
Se esse não for o seu problema, você também pode depurar mais com um login detalhado. Tente executar "plink -v hostname" e observe o erro. Você também pode criar um túnel manualmente via plink ; você pode precisar tentar essas opções para obter o erro para aparecer no plink. Como último recurso, postar os logs do plink -v e podemos depurar ainda mais.