ssh tunnel - bind: Невозможно назначить запрошенный адрес


26

Попытка создать ssh-туннель socks (-D) - от Linux к Linux (оба centos):

SSHD работает на удаленной стороне хорошо.

С локальной машины мы делаем / видим это:

ssh -D 1080 user@8.8.8.8.
user@8.8.8.8's password: 
bind: Cannot assign requested address

(где 8.8.8.8 - это действительно IP-адрес моего сервера, а 'user' - мое настоящее имя пользователя)

Я вошел в удаленную сторону в этом окне терминала. Я могу проверить, что локальный порт не использовался до этой команды, а затем использовался процессом ssh, после команды, с помощью:

netstat -lnp | grep 1080

Таким образом, в отличие от большинства ответов googled с этой ошибкой, проблема, похоже, не связана с назначением интерфейса обратной связи. Если я пытаюсь использовать этот туннель с почтовым клиентом, локальная сторона разрешает попытку (без ошибки «proxy-failed»), но данные / ответ не возвращаются.

На удаленной стороне у меня есть «PermitTunnel yes» в моем sshd_config (хотя в любом случае «yes» должно быть по умолчанию).

Идеи или подсказки?

Вот соответствующий отладочный вывод

OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *

....

debug1: Authentication succeeded (password).
debug1: Local connections to LOCALHOST:1080 forwarded to remote address socks:0
debug1: Local forwarding listening on 127.0.0.1 port 1080.
debug1: channel 0: new [port listener]
debug1: Local forwarding listening on ::1 port 1080.
bind: Cannot assign requested address
debug1: channel 1: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.utf8

Другая подсказка: если я запускаю Virtual Box на клиенте под управлением Windows, откройте туннель с замазкой в ​​этом ящике, и этот туннель к тому же удаленному серверу будет работать.

Еще страннее: «Если я использую Putty (для linux), работающий непосредственно на Linux-клиенте, он НЕ работает, даже если настройки точно дублируют настройки putty, которые РАБОТАЮТ в Putty, работающем в Windows в виртуальной коробке на том же самом компьютере. Клиентская машина ?? Есть что-то подозрительное ... все еще пытаюсь эксперименты, чтобы выяснить, что это такое.


Что если вы попытаетесь заставить его использовать ipv4? (так же, как первоначальный тест для устранения неполадок). Например ssh -4 -D 1080 user@8.8.8.8
Фред Клаузен

Можете ли вы попробовать более высокий номер порта, 4000?
Jwbensley

Спасибо за вклад. Я получил его для работы с: ssh -4 -D 8081 user@8.8.8.8
JosephK

Ответы:


41

Закрыть цикл здесь. В этом случае ответом было заставить ssh-клиент использовать ipv4. Например

ssh -4 -D 8081 user@8.8.8.8

Так что я бы подумал, за исключением того, что я могу выбрать 'force ip4' в putty (работает на Linux) без успеха. Также IPV6 отключен на этой машине, поэтому теоретически не должно было быть в игре. Совершенно противоречивые результаты, которые я все еще испытываю, пытаясь использовать различные варианты этой вещи, заставляют меня чесать голову. В любом случае, ваш ответ помог мне заставить его работать, и, возможно, обнаружил что-то странное в том, как работает эта версия CentOS или ядра Linux или что-то в этом роде - спасибо.
JosephK

Длинный выстрел, но, возможно, отключение разрешения SSH DNS на сервере «UseDNS no» в sshd_config, может решить эту проблему. Возможно, какое-то странное разрешение DNS происходит на сервере, вызывая проблемы с привязкой.
Фред Клаузен

1
Большое спасибо, -4 был также решением для Ubuntu 11.04.
Сандер

У меня появилась эта проблема после обновления до Ubuntu 13.04, и это было исправлением.
Ник

1
Вместо того, чтобы каждый раз указывать -4, предполагая, что все ssh-соединения должны выполняться только с IPv4, добавьте «AddressFamily inet» в ваш файл ssh_config - для каждого пользователя в $ {HOME} /. Ssh / ssh_config или для всей системы для все пользователи в / etc / ssh / ssh_config
JG Miller
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.