Назад | Перейти на главную страницу

SSH-туннель с использованием PuTTY больше не работает после смены сервера

РЕДАКТИРОВАТЬ (для уточнения)

              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

Вышеупомянутая конфигурация работала отлично, пока наш интернет-провайдер не заменил сервер на новый. Под «совершенно нормально» я имел в виду, что мог просматривать весь Интернет, включая веб-сайты, обычно заблокированные в Китае. Он по-прежнему отлично работает, когда я вхожу в другой Сессия SSH на другой сервер в качестве тестового (производственный веб-сервер, я не могу использовать его для этого). Во всех случаях ручной вход по SSH работает как обычно.

Мне нужно выяснить, почему он не работает с новым сервером, поскольку единственная цель этого сервера - предоставить эту функцию нашей компании.

ПРЕДЫДУЩАЯ РАЗМЕЩЕНИЕ

Наш поставщик серверов недавно изменил наш сервер и IP-адрес. Жесткий диск со старого сервера был перемещен на новый, и конфигурация должна была быть идентичной, за исключением изменения IP-адреса.

До перехода я использовал PuTTY на компьютере с Windows для туннелирования веб-трафика в качестве прокси-сервера SOCKS через сервер, используя динамический порт, установленный как 9870. После перемещения я перенастроил PuTTY, чтобы он указывал на новый IP-адрес. Но туннель больше не работает (время ожидания при запросе страниц в Firefox истекает).

У меня нет доступа к старому серверу. Но sshd_config на новом сервере:

#       $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

РЕДАКТИРОВАТЬ:-

Пока что я испробовал все предложения в ответах. Все еще не работает. Возможно ли, что брандмауэр в центре обработки данных, где размещен сервер, предотвращает ssh-туннель? Я пробовал D80 в качестве динамического порта в PuTTY, но это тоже не работает (должно ли?). Сервер - это в первую очередь веб-сервер, но в настоящее время у нас нет никаких веб-сайтов, хотя Apache работает.

Я просмотрел журнал putty.log, и, хотя я не могу понять его, есть следующий раздел:

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

Мне кажется, что перенаправление портов было принято удаленным сервером.

ДАЛЬНЕЙШЕЕ РЕДАКТИРОВАНИЕ: -

Я попытался подключиться к другому серверу, к которому я регулярно использую SSH, с точно такими же настройками туннелей SSH в PuTTY (D9870).

Это сработало мгновенно (Firefox увидел PuTTY как прокси-сервер SOCKS), и я сразу смог получить доступ к сайтам, заблокированным в моем местоположении [Китай].

Самым интересным в этом тесте было то, что netstat -an --inet тест, прописанный ниже респондентами на сервере также не показать 127.0.0.1:9870.

Я думаю, мне нужно четко указать, что я использую машину Windows для клиента PuTTY / Firefox. И я пытаюсь использовать удаленный сервер Linux для туннелирования веб-трафика, чтобы я мог безопасно получить доступ к веб-сайтам, заблокированным в Китае. Мне кажется, что предложенный тест netstat должен был запускаться на моем компьютере с Windows (в этом случае используется неправильный синтаксис netstat).

По запросу rwired я репостю свой предыдущий комментарий в качестве ответа:

Может ли удаленный сервер Linux устанавливать исходящие подключения к TCP-порту 80? Например, если вы «telnet www.google.com 80» с сервера, получите ли вы «Соединение установлено»? Или просто зависает?

Предполагалось, что что-то блокирует исходящее соединение, что, как обнаружил rwired, действительно имело место.

Устанавливать

GatewayPorts yes

в твоем sshd_config. По умолчанию установлено «нет», что не позволяет использовать удаленную переадресацию портов (ssh -R) на любой адрес, кроме самого удаленного SSH-сервера.

IMHO ваш sshd_config выглядит нормально. Может быть, sshd запускается с дополнительными параметрами командной строки, которые устанавливают для AllowTcpForwarding значение no? Если вы выполните "netstat -an --inet" на сервере, покажет ли он перенаправленный порт? Вы убедились, что ваш прокси-сервер socks работает правильно?

РЕДАКТИРОВАТЬ:

Вывод netstat должен выглядеть примерно так:

tcp        0      0 127.0.0.1:9870          0.0.0.0:*               LISTEN 

Вы проверили, действительно ли ваш файл открытого ключа находится на сервере, установленном в ~ / .ssh / authorized_keys

Возможно, его там вообще нет и он позволяет вам вернуться к использованию обычного текстового входа в систему, поэтому похоже, что он должен работать.

Прежде всего, попробуйте вручную установить ssh-соединение с сервером с помощью шпатлевки, тем самым убедившись, что нет несоответствия IP-адресов сервера, предотвращения присоединения MITM и т. Д., Что ssh начинает действовать и что может не отображаться в неинтерактивном сеансе ssh через замазку.

Если это работает нормально, вам действительно нужно увидеть туннель, который прослушивает соединения на порту localhost через netstat, если это не так, я подозреваю, что проблема не будет связана с ssh

В качестве дальнейшей отладки вы можете включить ведение журнала Putty чтобы увидеть, где на самом деле проблема.

РЕДАКТИРОВАТЬ: В журнале шпатлевки вы разместили единственную информацию, которая меня заинтересовала, - это терминал ... Моя гипотеза состоит в том, что новый сервер не может поддерживать такой "развитый терминал", попробуйте понизить версию терминала до древнего vt100. Есть довольно слабая вероятность, что это может быть проблемой ...

При смене сервера вы должны получить предупреждение о новом ключе хоста. Вы должны были принять новый ключ, возможно, сначала очистив старый ключ. Ты сделал это? Я считаю, что если у вас неправильный ключ хоста, ssh иногда позволяет вам открыть интерактивный сеанс, но не перенаправляет порты

PuTTY хранит свои ключи в реестре в HKEY_CURRENT_USER \ Software \ SimonTatham \ PuTTY (это как файлы known_hosts в OpenSSH). Вы можете попробовать удалить ключи оттуда вручную. Или, если вы хотите полностью сбросить настройки PuTTY и начать все сначала, попробуйте шпатлевка.

Если это не ваша проблема, вы также можете продолжить отладку с помощью подробного входа в систему. Попробуйте запустить "plink -v hostname" и посмотреть на ошибку. Вы также можете создать туннель вручную через plink; вам может потребоваться попробовать эти параметры, чтобы ошибка отображалась в файле plink. В крайнем случае опубликуйте логи из plink -v, и мы сможем отладить дальше.