1. Это разрешено. Мне просто нужно выяснить, как это сделать.

  2. Я хочу перенаправить веб-трафик с целевой машины на мою локальную машину так, чтобы когда что-то на удаленной машине пыталось установить связь через порт 443 (https), это было из моей локальной коробки.

Проблема, которую я пытаюсь решить, заключается в следующем:

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

Имея то, что я думаю, вероятно, просто много проблем с синтаксисом.

С моего настольного компьютера, попробовал: 

ssh -vnNT -R 443:[ my ip addr from remote's perspective ]:443 [ remote host name ]

Что я вижу в выводе отладки: 

debug1: Authentication succeeded (publickey).
Authenticated to remoteHostName ([remoteIpAddr]:22).
debug1: Remote connections from LOCALHOST:443 forwarded to local address [ my ip ]:443
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Remote: Server has disabled port forwarding.
debug1: remote forward failure for: listen 443, connect [my ip]:443
Warning: remote port forwarding failed for listen port 443
debug1: All remote forwarding requests processed

Теперь вы можете подумать, что вышеприведенное будет означать, что переадресация портов не настроена на сервере или не установлена на «нет». Я установил:

AllowTcpForwarding yes
GatewayPorts yes

... и я перезапустил его дважды. :-/

|источник

1 ответ1

0

1) sshd_config - не единственный источник параметров пересылки.

Даже если сервер разрешает глобальную переадресацию, отдельные соединения (определенные открытые ключи) могут быть ограничены с помощью параметров, указанных в удаленном файле ~/.ssh/authorized_keys .

Если вы используете OpenSSH "сертификаты", то ограничения могут быть закодированы в самом сертификате. Используйте ssh-keygen -L для проверки.

2) Для этого вам нужны права суперпользователя на удаленной системе.

Переадресация SSH-портов включает в себя обычные сокеты, которые прослушивают TCP-соединения на одном конце, а соединения - на другом. (Так что это больше похоже на проксирование, чем на порт перенаправления на уровне пакетов, наблюдаемый на маршрутизаторах.)

С -R сокеты прослушивания устанавливаются рабочим процессом sshd, который обрабатывает ваше соединение. Этот процесс выполняется под вашим собственным (удаленным) идентификатором пользователя, поэтому он подчиняется тем же ограничениям, что и ваши собственные программы. В частности, нельзя связывать сокеты с портом ниже 1024 (диапазон "привилегированных портов"), если у него нет привилегий root или чего-то подобного, что напрямую означает, что вы должны войти в систему как root @ для удаленной системы.

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .