Я пытаюсь настроить контейнер докеров, который я использую для обхода межсетевых экранов / NAT, чтобы разрешить SSH-доступ к компьютерам за этими барьерами маршрутизации. По сути, у меня есть служба SSH, которая прослушивает внутри контейнера докеров, к которому подключаются другие мои компьютеры, открывая обратную переадресацию порта SSH, а затем, если я хочу подключиться к компьютеру за брандмауэром, я вместо этого подключаюсь к своему докеризированному прокси-серверу через обратный порт. Пример:
Компьютер «Боб» с брандмауэром подключается к прокси-серверу:
ssh -R 2024:localhost:22 -N remote.server
Затем я подключаюсь к удаленному серверу через порт 2024
, чтобы вернуться по туннелю вниз и подключиться к localhost : 22
на боб:
ssh -p 2024 remote.server
все это прекрасно работает, когда он не dockerized, однако, когда я пытался переместить это в dockerized службу, я обнаружил, что мой SSHD
сервер внутри контейнера Docker упорно отказывается для открытия удаленного порта вперед. Подключение с помощью ssh -vvv
на первом шаге выше дает:
...
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 4
debug1: Remote: Server has disabled port forwarding.
debug3: receive packet: type 82
debug1: remote forward failure for: listen 2024, connect localhost:22
Warning: remote port forwarding failed for listen port 2024
debug1: All remote forwarding requests processed
Что очень похоже на мой sshd
, не настроен для разрешения переадресации удаленного порта. Однако, мой sshd_config
, кажется, думает, что это так:
# tail /etc/ssh/sshd_config -n 5
GatewayPorts yes
AllowTcpForwarding yes
AllowStreamLocalForwarding yes
PermitTunnel yes
UsePrivilegeSeparation no
Действительно, запуск с ssh -ddd
внутри контейнера докеров, затем соединение со строкой выше показывает сначала:
debug3: /etc/ssh/sshd_config:91 setting GatewayPorts yes
debug3: /etc/ssh/sshd_config:92 setting AllowTcpForwarding yes
debug3: /etc/ssh/sshd_config:93 setting AllowStreamLocalForwarding yes
debug3: /etc/ssh/sshd_config:94 setting PermitTunnel yes
debug3: /etc/ssh/sshd_config:95 setting UsePrivilegeSeparation no
Далее:
debug1: server_input_global_request: rtype tcpip-forward want_reply 1
debug1: server_input_global_request: tcpip-forward listen localhost port 2024
debug1: server_input_global_request: rtype no-more-sessions@openssh.com want_reply 0
Ясно, что моя конфигурация настроена правильно, но кажется, что клиент все еще думает, что сервер не может выполнять переадресацию портов. Как я могу убедить сервер openssh выполнить удаленную пересылку? Что могло вызвать этот сбой?
Клиент работает OpenSSH_7.2p2 Ubuntu-4ubuntu2.4
, сервер работает OpenSSH_6.7p1 Debian-5 + deb8u4
, версия докера 17.09.1-ce
на Amazon Linux 2017.09
.
Спасибо!
Ага! Я понял это. Это произошло потому, что docker
создавал внутреннюю сеть ipv6
для моих контейнеров, а в моем ядре не была включена переадресация ipv6
. Таким образом, при запуске sshd
вне контейнера, он бы работал по ipv4
, но при запуске sshd
внутри контейнера по сети docker bridge, он бы прослушивал ipv6
и не мог бы открыть порт вперед.
Как только я включил переадресацию ipv6
, (добавив net.ipv6.conf.all.forwarding = 1
в /etc/sysctl.conf
и перезагрузившись) все начинало работать просто отлично.
Вы также можете попробовать заставить sshd использовать ipv4. В вашем примере, добавив переключатель "-4" следующим образом:
ssh -4 -R 2024:localhost:22 -N remote.server
следующие шаги помогли мне
ssh
в контейнер/etc/init.d/ssh start
echo 'root:a-strong-password' | chpasswd
установить пароль для rootPermitRootLogin yes
/etc/init.d/ssh restart
ssh -fNTCR localhost:<YOUR-PORT>:localhost:22 remote-host
это переходит в фоновый режим, и вы можете увидеть его через ps aux | grep ssh
ssh -p <YOUR-PORT> localhost
screenhost
Дополнительная информация