Ошибка туннелирования SSH: «канал 1: открытие не удалось: административно запрещено: открытие не удалось»


185

Когда я открываю этот туннель SSH:

ssh -nXNT -p 22 localhost -L 0.0.0.0:8984:remote:8983

Я получаю эту ошибку при попытке получить доступ к HTTP-серверу, работающему на localhost: 8984:

channel 1: open failed: administratively prohibited: open failed

Что означает эта ошибка, и на какой машине вы можете решить проблему?


Может быть, я что-то упустил, но почему вы пытаетесь получить доступ к веб-серверу с помощью клиента ssh?
Фахим Митха

Почему вы пересылаете X11 (опция -X) сюда? Если вы хотите только пересылать HTTP, это не обязательно. И как примечание: IMHO ssh может быть неправильным решением для того, чтобы сделать веб-сервер доступным на нескольких портах.
Марсель Дж

29
Я обнаружил, что это означает «Не удается разрешить имя хоста remote» в моем случае.
RobM

3
Как видно из десятка ответов ниже, сообщение об ошибке, несмотря на то, что оно выглядит очень конкретным, следует понимать как общую ошибку. Как правило, решение состоит в том, чтобы открыть оболочку на удаленном компьютере и попробовать то же самое соединение, чтобы увидеть реальную причину. В ответах вы найдете наиболее распространенные фактические причины.
Стефан Гурихон

Ошибка разрешения DNS может вызвать эту ошибку, плюс соединение может
зависнуть до

Ответы:


122

канал 1: не удалось открыть: административно запрещено: не удалось открыть

Приведенное выше сообщение относится к вашему SSH-серверу, отклонившему запрос вашего SSH-клиента об открытии побочного канала. Это обычно происходит из -D, -Lили -w, как отдельные каналы в потоке SSH требуется , чтобы переправить пересылаемые данные поперек.

Поскольку вы используете -L(также применимо к -D), существует два варианта, по которым ваш SSH-сервер отклоняет этот запрос:

  • AllowTcpForwarding (как упоминал Стив Бузонас)
  • PermitOpen

Эти варианты можно найти в /etc/ssh/sshd_config. Вы должны убедиться, что:

  • AllowTCPForwarding либо отсутствует, либо закомментировано, либо установлено на yes
  • PermitOpenлибо отсутствует, либо закомментировано, либо имеет значение any[1]

Кроме того, если вы используете для подключения ключ SSH, вам следует убедиться, что запись, соответствующая вашему ключу SSH ~/.ssh/authorized_keys, не имеет операторов no-port-forwardingили permitopen[2].

Не относится к вашей конкретной команде, но в некоторой степени относится и к этой теме, это PermitTunnelвариант, если вы пытаетесь использовать опцию -w.

[1] Полный синтаксис на sshd_config(5)странице руководства .

[2] Полный синтаксис на authorized_keys(5)странице руководства .


Вот что я специально добавляю в sshd_config, чтобы заставить его работать: TCPKeepAlive yes AllowTCPForwarding yes PermitOpen any У меня есть несколько «open fail», но это нормально. Все работает очень хорошо.
Пьер Тибо

4
Крайний случай, на который следует обратить внимание: вы можете получить эту ошибку, когда пытаетесь создать устройство tap / tun с SSH, а SSH это позволяет, а ядро ​​- нет. Это может происходить в контейнерах LXC. См. Blog.felixbrucker.com/2015/10/01/… для точных подробностей, но в этом случае вы можете захотеть добавить lxc.cgroup.devices.allow = c 10:200 rwmв конфигурацию вашего контейнера и убедиться, что если /dev/net/tunон не существует, mknod /dev/net/tun c 10 200; chmod 666 /dev/net/tunзапускается при загрузке в контейнере.
Азендейл

@ Азендейл, это интересно, спасибо. Дает ли оно точно такое же сообщение об ошибке или что-то немного другое?
Hyperair

1
@ St.Antario, AllowTcpForwardingпозволяет перенаправлять порты TCP через SSH, что и -L 0.0.0.0:8984:remote:8983запрашивается параметром. Если AllowTcpForwardingустановлено значение no, SSH отклонит запрос на переадресацию портов, в результате чего вы увидите эту ошибку.
Hyperair

2
Пытался редактировать верхний регистр в AllowTCPForwardingto AllowTcpForwarding, но SE хочет изменить как минимум 6 символов. Так что просто отметьте, что правильным вариантом является Tcpверсия, которая используется правильно с первого раза.
dbreaux

51

В очень странном случае я также столкнулся с этой ошибкой при попытке создать локальный туннель. Моя команда была примерно такой:

ssh -L 1234:localhost:1234 user@remote

Проблема заключалась в том, что на удаленном хосте /etc/hostsне было записи для «localhost», поэтому сервер ssh не знал, как настроить туннель. Очень недружелюбное сообщение об ошибке для этого случая; рад, что наконец понял это.

Урок: убедитесь, что имя целевого хоста вашего туннеля разрешено удаленным хостом, либо через DNS, либо /etc/hosts.


2
Спасибо, это была проблема для меня. Я создал имя хоста для IP локально, но не на удаленном ssh-сервере.
dev_feed

2
«Целевое имя хоста вашего туннеля» немного сложно расшифровать. Можете ли вы привести конкретный работоспособный пример, который позволил бы мне взять ваш пример и заменить «целевое имя хоста» в вашем примере моим целевым именем хоста (как только я пойму, что вы подразумеваете под этим) и получите эту работу?
Терренс

1
Я даже не уверен, что ваш комментарий имеет смысл. Вы говорите, что на удаленной машине не было записи для localhost. Но затем скажите, что удаленный хост должен разрешить целевое имя хоста, а не локальное имя хоста. Опять же, будет полезен полный конкретный пример ситуации до и после.
Терренс

1
@TerrenceBrannon в приведенной выше команде, "localhost" является целевым именем хоста туннеля . При создании туннеля SSH команда ssh сначала регистрируется в удаленной системе ( user@remote), затем с удаленного конца устанавливает туннели к указанным целевым хостам (в приведенной выше команде это так localhost). При этом он использует схему разрешения имени хоста на удаленном хосте. Поэтому, если компьютер, на котором вы работаете по SSH, не может разрешить localhost, вы получите это сообщение об ошибке.
cobbzilla

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

25

По крайней мере, один ответ заключается в том, что «удаленный» компьютер по какой-то причине недоступен по ssh. Сообщение об ошибке просто абсурдно.


2
Нет, это не так; Я использую icmp-admin-запрещено, так как флаг отклонения в настройках брандмауэра все время.
Шадур

9
+1, административно запрещенное сообщение заставит человека поверить, что это блокировка брандмауэра, однако вы получаете то же сообщение, когда нет блокировки брандмауэра, но открытие завершается неудачно, потому что нет маршрута к удаленному хосту.
Стив Бузонас

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

Действительно, если «удаленный» недоступен - потому что он отключен, автономен, не существует, имя хоста не разрешается - тогда вы увидите это сообщение об ошибке.
Майкл Мартинес

18

Если «удаленный» не может быть разрешен на сервере, вы получите эту ошибку. Замените на IP-адрес и посмотрите, решит ли это вашу проблему ...

(В основном тот же ответ, что и у Нила, но я определенно обнаружил, что это проблема на моей стороне) [У меня был псевдоним для имени машины в моем ~/.ssh/configфайле - и удаленная машина ничего не знала об этом псевдониме ...


Вы также можете увидеть ту же ошибку при использовании -D(DynamicForward) в качестве SOCKS-прокси в браузере. Т.е. пытается получить доступ к веб-сайту, который не может разрешить хост туннеля.
Timss

10

Эта ошибка окончательно появляется при использовании опций ssh ControlPathи ControlMasterпри совместном использовании одного сокетного соединения для повторного использования между несколькими клиентскими соединениями (от одного клиента до одного и того же пользователя @ сервера). Открытие слишком много (что бы это ни значило, в моем случае ~ 20 соединений) приводит к этому сообщению. Закрытие любых предыдущих подключений позволяет мне открывать новые, снова до предела.


Я пришел сюда в поисках, где установить этот предел мультиплекса ControlMaster. Если кто-то знает, они более чем рады поделиться.
Клак

1
Внимание: в соответствии с bugs.debian.org/cgi-bin/bugreport.cgi?bug=546854 вы можете добавить параметр MaxSession в файл / etc / ssh / sshd_config, чтобы установить это. Согласно man-странице, по умолчанию установлено значение 10.
Оливер

@oliver: подтверждаю, MaxSession работает, спасибо. наткнулся на 64 на моей книге.
Матей Ковач

2
Будьте осторожны, это не MaxSessionно MaxSessions. Хотя есть некоторые средства защиты, не
нарушайте

8

«Административно запрещено» - это специальный флаг сообщения ICMP, который сводится к «Администратор явно хочет, чтобы это соединение было заблокировано».

Проверьте настройки iptables.


5
Не обязательно. Сообщение генерируется, когда хост не может обслуживать запрос. Обычно дело в том, что администратор заблокировал соединение, но также может быть и то, что оно не заблокировано явно, но нет маршрута к нужному хосту. AFAIK sshне имеет логики для определения причины сбоя соединения, он просто предполагает, что если вы пытаетесь установить соединение, значит, оно существует, и если вы не можете получить его, соединение должно быть намеренно заблокировано.
Стив Бузонас

2
Нет Существует четкое различие между типом ответа ICMP, который говорит «нет маршрута к хосту», и тем, который говорит «административно запрещено», и если кто-то намеренно неправильно настроил маршрутизатор, последний означает именно то, что он говорит на жестком диске.
Шадур

1
Я только что получил «административный запрет» при использовании имени хоста, которое не разрешается, так что оно кажется универсальным. Возможно, SSH делает какой-то перевод?
Ганеш Ситтампалам

5

Похожая проблема

Еще одно возможное преимущество

У меня была та же проблема , используя ~/.ssh/authorized_keysс permitopen.

Поскольку я использую autosshдля создания туннеля, мне нужно два порта:

  • один для подключения (10000),
  • один для мониторинга (10001).

На стороне клиента

Это дало мне похожую проблему с портом мониторинга:

autossh -M 10001 -o GatewayPorts=yes -o ServerAliveInterval=60  -o TCPKeepAlive=yes -T -N -R :10000:localhost:22 -i ~/.ssh/id_rsa user@remote

У меня было это сообщение (через 10 минут):

channel 2: open failed: administratively prohibited: open failed

На удаленной стороне

Мой /var/log/auth.logсодержал:

Received request to connect to host 127.0.0.1 port 10001, but the request was denied.

В моей ~/.ssh/authorized_keys(удаленной стороне) у меня было это:

command="/home/user/tunnel",no-X11-forwarding,no-pty,permitopen="localhost:10000",permitopen="localhost:10001" ssh-rsa AAAA...

Как это решить

Я решил это, заменив localhostэкземпляры на 127.0.0.1:

command="/home/user/tunnel",no-X11-forwarding,no-pty,permitopen="127.0.0.1:10000",permitopen="127.0.0.1:10001" ssh-rsa AAAA...

Кажется , что SSH не понимает , что localhostэто ярлык 127.0.0.1, следовательно, сообщение auth.logи запрещен администратором сообщение.

Здесь я понимаю, что административно означает «из-за конкретной конфигурации на стороне сервера».


localhost, вероятно, сопоставлен с :: 1 (ipv6), и вы по какой-то причине не слушали его
Джо Ретт,

4

Это также происходит, когда /etc/sshd_configимеет

AllowTcpForwarding no 

установлен. Включите его, чтобы yesразрешить пересылку TCP.


4

В моем случае, мне пришлось заменить localhostс 127.0.0.1в:

ssh -L 1234:localhost:3389 user@remote

заставить это работать.

Я пытался rdesktop -L localhost:1234следовать инструкциям Amazon по подключению к AWS EC2 через SSH-туннелирование . Я пытался изменить /etc/ssh/sshd_config(как клиент, так и сервер запускают Ubuntu 16.04 LTS) в ответ на самый высокий голос. Я также проверил, что localhostнаходится /etc/hostsс обеих сторон.

Ничего не работало, пока я не изменил sshсаму команду на:

ssh -L 1234:127.0.0.1:3389 user@remote

Спасибо вам большое!
Тибо Баррер

3

Некоторые действия по устранению неполадок необходимы, чтобы найти окончательный ответ:

  • проверьте, включена ли переадресация портов в конфигурации ssh пользователя,
  • включить многословие ssh (-v),
  • проверьте логи ssh на локальном хосте и безопасные логи на удаленном,
  • проверить другой удаленный порт,
  • проверьте настройки iptables (как сказал Шадур).

3

Однажды я получил эту ошибку за то, что отдал пульт в параметре -L, также 0.0.0.0 является избыточным, вы можете опустить его с теми же результатами, и я думаю, что вы должны добавить -g, чтобы он работал.

Это линия, которую я использую для туннелирования: ssh -L 8983:locahost:8984 user@remote -4 -g -N

-4 tells to use only ipv4
-g Allows remote hosts to connect to local forwarded ports.
-N Do not execute a remote command.  This is useful for just forwarding ports (protocol version 2 only). I use this to clog the terminal so I don't forget to close it since generally I need the tunnels temporarily.

3

Это также может быть вызвано невозможностью привязки к порту на локальной стороне.

ssh -Nn -L 1234:remote:5678 user@remote

Эта команда пытается связать прослушивающий порт 1234 на локальном компьютере, который сопоставляется со службой через порт 5678 на удаленном компьютере.

Если порт 1234 на локальной машине уже используется другим процессом (возможно, фоновым сеансом ssh -f), то ssh не сможет прослушивать этот порт, и туннель не будет работать.

Проблема в том, что это сообщение об ошибке может означать любую из нескольких вещей, а «административно запрещено» иногда дает неверное представление. Поэтому, в дополнение к проверке DNS, межсетевых экранов между локальным и удаленным и sshd_config, проверьте, используется ли локальный порт. использование

lsof -ti:1234

чтобы выяснить, какой процесс запущен на 1234. Вам может понадобиться sudo для lsof, чтобы вывести список процессов, принадлежащих другим пользователям. Тогда вы можете использовать

ps aux | grep <pid>

чтобы выяснить, что это за процесс.

Чтобы получить все это в одной команде:

ps aux | grep "$(sudo lsof -ti:1234)"

2

У меня было то же сообщение при попытке туннелирования. Возникла проблема с DNS-сервером на удаленной стороне. Проблема была решена, когда он вернулся на работу.


2

Я очень удивлен, что никто не упомянул, что это может быть проблемой DNS.

journalctl -f
channel 3: open failed: administratively prohibited: open failed
Mar 10 15:24:57 hostname sshd[30303]: error: connect_to user@example.com: unknown host (Name or service not known)

Это может быть представлено, если remoteэто не разрешимо, или вы вводите неизвестный синтаксис, как я сделал здесь, где я добавил user@к логике переадресации порта (которая не будет работать).


2

В моем случае проблема была связана с запросом туннеля без доступа к оболочке, в то время как сервер пытался принудительно изменить пароль для моей учетной записи. Из-за отсутствия оболочки я не смог этого увидеть и получил только ошибку

channel 2: open failed: administratively prohibited: open failed  

Моя конфигурация туннеля была следующей:

ssh -p [ssh-port] -N -f -L [local-port]:127.0.0.1:[remote-port]
[server-address]

Ошибка при входе непосредственно на сервер (без -N -f):

WARNING: Your password has expired. You must change your password now
and login again!

Я решил проблему, выполнив вход с доступом к оболочке и изменив пароль. Тогда я мог бы просто снова использовать туннели без доступа к оболочке.


1

У меня была эта проблема при попытке подключения через SSH с пользователем, который был авторизован для подключения только по SFTP.

Например, это было на сервере /etc/ssh/sshd_config:

Match group sftponly
    ForceCommand internal-sftp
    ChrootDirectory /usr/chroot/%u
    [...]
Match

Таким образом, в этом случае, чтобы использовать SSH, вам придется либо удалить пользователя из эквивалентной sftponlyгруппы, либо подключиться, используя пользователя, который не ограничен SFTP.


1

Проверьте, /etc/resolv.confпусто ли на сервере, на котором вы собираетесь ssh. Несколько раз я обнаружил, что это связано с пустым /etc/resolv.confфайлом

Если не root, вы можете просто проверить на сервере, попробовав несколько pingили telnet(80) для публичного имени хоста, то есть:

root@bananapi ~ # telnet www.google.com 80
telnet: could not resolve www.google.com/80: Name or service not known

После добавления записей сервера имен в /etc/resolv.conf:

root@bananapi ~ # telnet www.google.com 80
Trying 74.125.195.104...
Connected to www.google.com.
Escape character is '^]'.
GET / HTTP/1.0

HTTP/1.0 302 Found
Location: http://www.google.ro/?gws_rd=cr&ei=8fStVZ-hMIv6UvX6iuAK

Однако следует также проверить, почему он /etc/resolv.confбыл пустым (обычно он заполняется записями сервера имен с помощью клиента dhcp на сервере, если это применимо).


1

Я получал то же сообщение во время настройки SSH для Debian. Оказалось, что в удаленной системе не было свободного места. После освобождения дискового пространства и перезагрузки туннель начал работать.


0

Я видел эту ошибку на Cygwin, и это должно быть верно и для Linux и работал для меня. В моем случае я сделал ssh -ND *: 1234 user@127.0.0.1, и когда я подключил браузер к этому серверу comp-socks, он просматривал, но на компе, где я запускал команду ssh, я получил эту ошибку, появляющуюся в консоль с каждым запросом - по крайней мере для одного сайта, хотя браузер извлекал его через прокси или, казалось, по крайней мере в той степени, в которой я видел основной возраст. Но внесение этого изменения избавило от неудачного сообщения

http://linuxindetails.wordpress.com/2010/02/18/channel-3-open-failed-administratively-prohibited-open-failed/

While trying to do some SSH tunneling, here is the error I got :
channel 3: open failed: administratively prohibited: open failed
To avoid this kind of error, have a look at the SSH daemon configuration file :
/etc/ssh/sshd_config
Add possibly the following line :
root@remote-server:~# echo “PermitTunnel yes” >> /etc/ssh/sshd_config
Then, restart your sshd server :
root@remote-server:~# service ssh restart
or

root@remote-server:~# /etc/init.d/ssh restart

Туннелирование AFAIK включено по умолчанию, потому что отключение не добавляет никакого уровня безопасности, в первую очередь просто неудобство добавления стороннего туннеля. У меня похожая проблема при попытке прокси-сервера к внутренним серверам из удаленного расположения, и туннелирование включено + iptables сброшен с действием по умолчанию для ACCEPT.
Стив Бузонас

@SteveBuzonas Я вижу это в / etc / sshd_config, так что а) он не отключает туннелирование б) что касается моего ответа, решение там может быть не очень хорошей идеей. Вот что sshd_config говорит об этой опции # Чтобы отключить туннельные пароли в виде открытого текста, измените здесь на no! #PermitTunnel no
barlop

@SteveBuzonas проверьте ваш, вероятно, он установлен на no, и вы можете туннелировать, так как туннелирование действительно включено по умолчанию.
Барлоп

Я думал о том AllowTCPForwarding, что комментарий, о котором вы говорите, # To disable tunneled clear textкасается PasswordAuthenticationустановки на no, PermitTunnelэто настройка, позволяющая сетевым туннелям уровня 2 или уровня 3 через tun / tap и по умолчанию no. Опции L, R и D используют переадресацию TCP, а не устройство для туннелирования.
Стив Бузонас

0

Еще один сценарий - служба, к которой вы пытаетесь получить доступ, не работает. Я столкнулся с этой проблемой на днях, только чтобы вспомнить, что экземпляр httpd, к которому я пытался подключиться, был остановлен.

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


Полезный общий совет, но не ответ на поставленный вопрос.
Кайл Джонс

0

Проверьте свой маршрутизатор на предмет защиты от перепривязки DNS . Мой маршрутизатор (pfsense) имеет включенную по умолчанию защиту перезаписи DNS. Это приводило к ошибке «канал открыт: ошибка административно запрещена: ошибка открытия» с SSH


0

У меня была та же проблема, и я понял, что это был DNS. Трафик туннелируется, но DNS-запроса нет. Попробуйте вручную отредактировать файл DNS hosts и добавить сервис, к которому вы хотите получить доступ.


0

Мое дело:

$ssh -D 8081 localhost >>log1.txt 2>&1 &

----wait for 3 days

$tail -f log1.txt
channel 963: open failed: connect failed: Connection refused
channel 963: open failed: connect failed: Connection refused
channel 971: open failed: connect failed: Connection reset by peer
channel 982: open failed: connect failed: Connection timed out
channel 979: open failed: connect failed: Connection timed out
channel 1019: open failed: administratively prohibited: open failed
accept: Too many open files
channel 1019: open failed: administratively prohibited: open failed
accept: Too many open files
channel 1019: open failed: administratively prohibited: open failed

$ps  axu | grep 8081
root       404  0.0  0.0   4244   592 pts/1    S+   05:44   0:00 grep --color=auto 8081
root       807  0.3  0.6   8596  6192 ?        S    Mar17  76:44 ssh -D 8081 localhost

$lsof -p 807 | grep TCP
ssh     807 root 1013u  sock     0,8      0t0 2076902 protocol: TCP
ssh     807 root 1014u  sock     0,8      0t0 2078751 protocol: TCP
ssh     807 root 1015u  sock     0,8      0t0 2076894 protocol: TCP
.....

$lsof -p 807 | wc -l
1047

$ cat /etc/hosts
127.0.0.1   localhost
127.0.1.1   malcolm-desktop

$ssh localhost
Welcome to Ubuntu 14.04.2 LTS (GNU/Linux 3.13.0-53-generic i686)

----after restart ssh -D 8081 localhost
$ lsof -p 1184 | grep TCP
ssh     1184 root    3u  IPv4 2332193      0t0   TCP localhost:37742->localhost:ssh (ESTABLISHED)
ssh     1184 root    4u  IPv6 2332197      0t0   TCP ip6-localhost:tproxy (LISTEN)
ssh     1184 root    5u  IPv4 2332198      0t0   TCP localhost:tproxy (LISTEN)
ssh     1184 root    6u  IPv4 2332215      0t0   TCP localhost:tproxy->localhost:60136 (ESTABLISHED)
ssh     1184 root    7u  IPv4 2336142      0t0   TCP localhost:tproxy->localhost:32928 (CLOSE_WAIT)
ssh     1184 root    8u  IPv4 2336062      0t0   TCP localhost:tproxy->localhost:32880 (CLOSE_WAIT)

0

Я получил эту ошибку при записи этой записи в моем блоге :

/etc/ssh/sshd_config было что-то вроде:

Match Group SSHTunnel_RemoteAccessGroup
    AllowTcpForwarding yes
    PermitOpen=sshbeyondremote.server.com:22

Но ~/.ssh/configимел:

Host remote.server.com
  HostName remote.server.com
  Port 10022
  User useronremote
  IdentityFile ~/.ssh/keys/key1/openssh.keyforremote.priv
  LocalForward 2222 SSHBeyondRemote.server.com:22

Обратите внимание на разницу в регистребольшой буквы) между SSHBeyondRemote.server.com:22 и sshbeyondremote.server.com:22 .

Как только я исправил дело, я больше не видел проблему.

Я использовал:

Версия клиента OpenSSH:

  • OpenSSH_7.2p2 Ubuntu-4ubuntu2.4, OpenSSL 1.0.2g 1 марта 2016 г.

Версия сервера OpenSSH:

  • OpenSSH_7.6p1 Debian-4, OpenSSL 1.0.2n 7 декабря 2017 г.

1
Если вы собираетесь ссылаться, рекламировать, цитировать или иным образом ссылаться на то, с чем вы связаны, вы должны явно раскрыть эту принадлежность. Недостаточно просто сказать «при соединении (ссылка)» (потому что я не понимал, что это значит, пока не понял, что вы ссылаетесь на свой блог); URL, совпадающий с вашим именем пользователя в Stack Exchange, недостаточно. Ссылки: Как не быть спамером ,  Избегать явной саморекламы ,… (продолжение)
Скотт

(Продолжение) ... и когда мы должны обеспечивать соблюдение требования о присоединении?    Вы можете свободно упоминать свой блог, своего работодателя, любое известное программное обеспечение, которое вы разработали, любые книги, которые вы написали, любые другие проекты, с которыми вы работаете или были связаны, и т. Д., На странице вашего профиля пользователя. ,
Скотт

0

Другая причина разрешения имен: Мой / etc / hosts имел ошибочный IP-адрес для имени сервера (не для localhost), например так:

127.0.0.1     localhost
192.168.2.45  server.domain.com server

Но настроенный IP-адрес сервера (и DNS-имя, разрешенное с помощью команд host / dig) был 192.168.2.47. Простая опечатка, вызванная предыдущей реконфигурацией IP. После исправления / etc / hosts туннельное соединение работало безупречно:

ssh user@server.domain.com -L 3456:127.0.0.1:5901

Странно, что настоящий IP-адрес вызвал сбой, когда я использовал локальный IP-адрес localhost для туннеля. Дистро: Ubuntu 16.04 LTS.


0

Причина, по которой я получил это сообщение, не самая распространенная, но стоит упомянуть. Я сгенерировал с помощью сценария список туннелей, и для обеспечения представления столбца я напечатал каждый последний байт по два байта. Когда я пытался открыть переадресацию туннеля на 192.168.66.08, это всегда не удавалось, потому что '08' интерпретируется gethostbyaddr как неверное восьмеричное число :)


0

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

-LОпция добавляет неявное SSH прыжок (эффективно используя явный SSH хоста в качестве сервера / скачки бастиона). Это может быть легче отладить, выполнив переход явно и создав оболочку входа в систему на целевой машине с помощью команды proxycommand.

Как только это сработает, вы можете сделать переадресацию порта на основе целевого компьютера localhost(при условии, что он может войти в себя):

-N -L 1234:localhost:1234
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.