Надо тут было одному клиенту установить сайт на тестирование. Причем сайт такой, что на свой хостинг положить было нельзя по некоторым причинам, надо было ставить в офисе. Кроме того, надо было не только поставить, но еще и периодически обновлять там код.
По ходу дела начались всякие сетевые трудности (файрволы там, и все такое), и в процессе их обхода родилась совершенно мозголомная конфигурация, которая меня очень забавляет.
Изначальная идея была очень простая. Поскольку весь код проекта лежит в Subversion у меня на softwaremaniacs.org, достаточно заходить на клиентский сервер ssh'ем и обновлять из этого репозитория код.
Но этот вариант не прошел, потому что сервер у клиента стоит за файрволом и просто так зайти на него не получится. После недолгих совещаний с тамошним админом мне сделали ssh'ный вход на машину gateway'я, видную из сети, с которой я уже должен был попадать внутрь. Но не тут-то было! Гейт этот видимо как-то умно настроен, что не принимает ssh'ных коннектов от машин без своего публичного имени хоста. А это как раз мой случай, потому что сижу я на диалапном соединении (в силу причин историко-политического характера).
Но эта проблема разрешилась просто, двойной вход превратился в тройной: я сначала захожу на свой сервер в сети, с него на гейт, а с него -- на машину с проектом.
Все было замечательно до тех пор, пока у клиента не поменялась политика в сети, и с проектовой машины перестал видится интернет. То есть не только на нее не попасть, но и с нее теперь тоже. Причем, произошло это как-то тихо, без всяких предупреждений, поэтому это открытие я сделал тогда, когда админ, который мог бы это как-то снова открыть, был недоступен, а мне зачем-то (сейчас уже не помню) надо было обновить код прямо сейчас!
После обязательно в таких стрессовых ситуациях стаканчика чая я вспомнил, что протокол ssh, которым я через хм... тернии захожу на проектную машину, умеет такую замечательную вещь, как туннель.
Туннель -- это способность ssh соединять две машины, которые друг-друга напрямую не видят, через третью, причем по любому протоколу. Происходит это так, что клиент соединяется с промежуточной машиной по ssh и передает ей адрес нужного удаленного сервера и номер порта на нем, после чего ssh-сервер на промежуточной машине начинает передавать через себя данные, приходящие от клиента на указанный порт сервера, и возвращать клиенту то, что ответил сервер. А природа этих данных его не интересует.
Фактически человек, знающий пароль на промежуточный сервер, может создать себе эдакую временную обходную дырку на сервер за файрволом.
А это как раз то, что мне надо: проектная машина не видит softwaremaniacs.org, но видит гейт в своей внутренней сети. А гейт видит softwaremaniacs.org. А на гейт у меня есть ssh-вход.
Итак, зайдя через свое тройное соединение на проектную машину, я делаю еще одно ssh-соединение на гейт, но теперь уже снабжаю его туннелем, который позволит видеть проектной машине softwaremaniacs.org по протоколу subversion'а.
Но тут возникает загвоздка. После всех этих соединений у меня открытый shell оказывается на машине гейта, а мне там совершенно нечего делать. Мне надо быть на проектной машине, где я буду писать всякие командочки для апдейта кода и перезапуска апача. Поэтому прямо с гейта я делаю еще один вход обратно на проектную машину.
Честно скажу, когда я пытаюсь представить по какому маршруту до моего ноутбука доходят буковки, которые печатает subversion на softwaremaniacs.org, у меня начинает слегка кружиться голова :-). Но самый ураган, это когда я на проектной машине обновляю не свой код, а Django. Из-за того, что на их сервере репозиторий доступен только по HTTP на 80 порту, мне приходится еще там в середине процесса sudo делать, потому что туннели на маленьких портах только root'у разрешается делать :-).
Из всего этого я сделал пару примечательных выводов:
- любому специалисту неплохо обладать навыками в смежных областях: программисту быть чуть-чуть админом, чуть-чуть дизайнером, чуть-чуть хакером, архитектором, менеджером...
- древние текстовые юниксовые протоколы придумывали не дураки, и по чистой функциональности они еще очень долго будут впереди удаленных графических клиентов
И есть у меня один небольшой вопрос: не знает ли кто, как автоматизировать ввод паролей на всех этих шеллных подключениях? А то там в разных местах и логины разные, и пароли, жутко муторно ради одного апдейта все это руками вбивать.
Комментарии: 7 (особо ценных: 1)
Alex Zhukov
20.07.06 04:13
действително твистер %)
Автоматизировать ввод паролей - можно на каждой машине сгенерировать по паре public/private rsa ключей и скормить их ssh. Если ключ генерировать без passphrase то пароль она спрашивать не будет.
А вообще наверное надо не не в твистер с серверами играть а попросить админа настроить нат и файервол нормально. Даже с точки зрения политики безопасности это будет правильнее, чем прокладывать тунели.
mahoro
20.07.06 10:26
Забавно :)
Я бы сделал это все немного по другому. Если гейт - машина, с которой видно все остальное, то я бы запустил ssh к ней с ключиком -D 8989 и поигрался таким образом, чтобы соединения к какому-либо локальному порту перебрасывались на порт 8989 гейта - это будет socks proxy, а ssh на локальной машине запускать из-под sockscap в винде или socksify в unix (с последним придется повозиться)
ssh-keygen -t rsa
cat ~/.ssh/id_rsa.pub | ssh user@host "mkdir .ssh; cat >> ~/.ssh/authorized_keys"
или как-то так.
А вообще, man ssh - очень увлекательное чтение )
kropp
20.07.06 10:59
Особо ценный комментарий
Вместо этого достаточно сказать
ssh-copy-id user@host
Ну и для полноты картины: под виндой к putty прилагаются pageant (он ключи держит в памяти и подставляет их во время авторизации) и puttygen (он генерирует эти самые ключи).
Nab
20.07.06 12:42
Вот именно, надоть с ключами это все делать, благо это не сложно.... Я очень недавно разбирал похожее, и вот мои результаты, там конкретные рекомендации есть по разного типа коннектам.
http://freesco.linux.kiev.ua/docs/articles/ssh_tunneling.shtml
А вот это достаточно давняя заметка как деалать ключи авторизации Автоматический вход на роутер FreeSCO используя SSH и authorized_keys
click here
24.07.06 01:07
Ключ обязательно генерить с паролем, но использовать ssh-agent
Julik
28.07.06 00:03
Я в такой ситуации после обязательного стаканчика чаю звоню клиенту и обьясняю, что пока админу не оторвут какую-нибудь нужную и выступающую часть тела за паранойю работа над проектом останавливается.
Бред имеет смысл только если ты пишешь ПО для банка (или что-то подобное). Capistrano кстати поддерживает работу через gateway-сервер.
Владислав
28.07.06 11:46
Пару месяцев назад у меня на работе (уже я там не работаю) стоял роутер, который перехвачивал весь трафик, а директор лично потом смотрел куда мы ходим, что качаем. Следующим этапом было ограничение скорости на всё, кроме одного сервера (нашего проекта). А так как скорость на сервер была не ограничена (порядка 80 Мбит), то мы сначала подняли на сервере CGI-прокси, а затем, когда его обнаружили, подняли SSH-прокси. Вот там было по-типу этого :)
Веселые были времена :)