Я пытаюсь сделать возможным управление оболочкой на Linux-сервере за маршрутизатором, который не находится под моим контролем.
Моя первая идея заключалась в том, чтобы заставить клиента (ящик за маршрутизатором) использовать ssh на сервере под моим контролем и перенаправлять локальный порт ssh периодически из cron, например:
client$ ssh -L 40000:localhost:22 root@server
Он работает с моим частным, менее безопасным сервером, но не работает с клиентским сервером, который представляет собой защищенную от grsecurity CentOS, 2.6.24.5-grsec-xxxx-grs-ipv4-32 (root@kernel-32.ovh.net). Я ничего не знаю о grsecurity и особенно о том, как она настроена на этом сервере. Параметр AllowTCPForwarding - sshd_config по умолчанию, который предположительно (с RTFM) имеет значение «да», а ssh -v сообщает мне
debug1: Local connections to LOCALHOST:40000 forwarded to remote address localhost:22
debug1: Local forwarding listening on 127.0.0.1 port 40000.
но все, что я получаю при попытке вернуться к клиенту по ssh с этого сервера, - это «В соединении отказано».
Следующая идея:
На клиенте:
client$ bash -i <in >out 2>err &
client$ ssh root@server 'cat <client.in' >in &
client$ ssh root@server 'cat >client.out' <out &
client$ ssh root@server 'cat >client.err' <err &
На сервере:
server# cat client.out &
server# cat client.err &
server# cat >client.in
ls
Все они, {client.,} {In, out, err}, являются именованными каналами, созданными с помощью mkfifo. Но почему-то у меня так не работает ssh, через сеть ничего не передается. Это частично работает с обычными файлами (не именованными каналами) и tail -f. Но я чувствую, что это не то, как вы этого добиваетесь. И опасения по поводу того, что простые файлы станут слишком большими и будут перезаписаны ... это просто не кажется приятным.
Любые идеи? У меня есть root на сервере клиентов, но я бы предпочел не устанавливать ядра и не наносить ущерба.
ОБНОВИТЬ
Уточнение: клиентский блок будет установлен клиентом в каком-то удаленном месте за маршрутизатором, над которым ни я, ни заказчик не контролируем. Итак, на маршрутизаторе нет перенаправления портов или динамического DNS. Просто обычный Linux-сервер с частным IP где-нибудь в сети. Первая идея, которую я представил, будет работать с сервером менее безопасным, чем сервер клиента. Я должен использовать grsecured. Я могу передавать ssh с сервера grsecured в другие места, поэтому это не проблема iptables. Я также могу открывать порты прослушивания (с помощью nc -l) и подключаться к ним.
Я подключаюсь от клиента за маршрутизатором к серверу, перенаправляя некоторый высокий порт сервера (например, 40000) на порт ssh на клиенте, поэтому я могу сначала ssh из дома на сервер, а затем ssh с сервера на клиент. Как я уже сказал, клиент не находится в моей сети и находится за маршрутизатором, который не находится под моим контролем.
Я не возвращаюсь домой, клиент - это не машина, с которой я начинаю это чудесное путешествие. Дом, сервер и клиент находятся в трех разных сетях.
Я думаю, что вы неправильно используете SSH-туннель, поэтому вы эффективно туннелируете от клиента, к которому пытаетесь получить доступ, к открытому серверу, а не наоборот. Вы не сможете использовать -L, так как вы не можете подключиться к клиенту, чтобы установить туннель.
Дальнейший путь, если GatewayPorts включен в sshd_config на сервере под вашим контролем, заключается в использовании обратного туннеля, например: ssh -N -R 40000:localhost:22 user@server_under_your_control
Возможно, вам понадобится переадресация порта ssh в другом направлении. А именно:
client# ssh -R 40000:localhost:22 clientLogin@yourServer
С некоторыми ключами SSH и еще много чего, а также с оболочкой для перезапуска, если она упадет. Это позволит вам использовать SSH yourServer:40000 и получить оболочку на client.
То, что сказал Джеймс, отлично работает с Статический IP. если у него его нет, он должен воспользоваться услугой (скажем, dyndns), который будет указывать его ip каждый раз.
Например, ssh -R blahblah user@thisIsMyIp Затем вы должны создать сценарий, который будет проверять, установлено ли соединение, и если это не так, вы должны выполнить команду выше
Вы также можете попробовать Hamachi. Я использую это для тех же целей. Версия для Windows является основным направлением разработки, но есть и версия для Linux. Я найду ссылку, когда у меня будет больше времени, и отредактирую. Приведенное ниже руководство может действительно связать вас с ним.
http://en.wikipedia.org/wiki/Hamachi http://www.hackitlinux.com/50226711/using_hamachi_on_linux.php https://secure.logmein.com/US/products/hamachi2/download.aspx
Просто подумайте о своем первом решении: вы проверили, что IPTABLES не блокирует ваши соединения? Возможно, вам просто нужно разрешить такой трафик в межсетевом экране системы.