» NAT и публикация сервисов с учётом virtual hosts

Вопрос к опытным админам, знакомым на практике с комплексом взаимосвязанных проблем, вызванных:

1) NAT,
2) необходимостью публиковать сервисы из локалки для внешнего мира
3) необходимостью для некоторых веб-сервисов поддерживать требуемые для них virtual hosts в запросах.
4) желанием упростить администрирование клиентов (в идеале добиться того, чтобы клиенты коннектились к единственному ресурсу без различия того, с какой стороны шлюза находятся).

Есть мелкософт-way решения этого комплекса проблем: UAG. "Тяжёлый чОрный ящик с магическими рычажками".
Из области unix-вея мне известны только частичные решения:

- Split DNS
- портфорвардинг на роутере или "Hairpin NAT".
- веб-прокси разной степени навороченности
- шаманство с DNS на роутере (простой маскарадинг некоторых запросов или инспекция трафика)


Ищу ЗАКРЫВАЮЩЕЕ решение для целого комплекса вышеупомянутых проблем.

Среди бесчисленных юниксоидных статей в интернетах ничего подобного мне не попалось до сих пор: решения или частичные, или представляют собой рекламу какого-то софта, пускай и бесплатного (в духе "iptables всемогущ, читайте маны"). Плохо искал?



Добавлено:

Если не найдётся исчерпывающей статьи с рецептом, предлагаю обсудить тему в таком порядке:

сперва ЧТО надо сделать,
затем выбрать подходящий инструмент,
наконец детализировать, КАК именно добиться желаемого эффекта.

Ну если не очень вдаваться в подробности и рассмотреть ситуацию в целом, то я считаю что выглядеть это должно так:
Ну исходить я буду всё-таки из GNU/Linux дистрибутивов.
NAT и firewall настраивать понятное дело через iptables, с его настройки и стоит начать. Собственно никаких DNAT'ов тут не надо городить.
Что бы сервисы откликались по именам и снутри и снаружи, тут как вы справедливо заметили, самый нормальный подход это Split DNS.
Сервисы, я так понял это web-ресурсы какие-то? Ну в таком случае я считают, что они как жили в локалке так пускай там и живут, и пускать к ним стоит через nginx, например, установленный на шлюзе и настроенный в качестве обратного прокси.
ну послений пункт выполняется сам собой, после настройки Split DNS.

p.s. готовых таких решений я не видел. Хотя если считать некие сборки и их web-интерфейсы, готовыми решениями, то я считаю что Zentyal уже дорос до весьма неплохо продукта. Однако я люблю настройки сервисов выполнять ручками в текстовых файлах...

Сервисы - не обязательно веб-ресурсы. Например, ещё почтовик (но не только).

без iptables понятное дело никуда (даже если оно упаковано в микротик или тот же Zentyal), а вот nginx например в микротик не вштыришь. Какой-то прокси там есть, но скорее сквид.

Смоделировать мне кажется лучше на микротике - именно чтобы разобраться с тем для начала, ЧТО надо делать.
А потом уже можно воспроизводить ручками.


Добавлено:

Хорошо бы рассмотреть оба варианта:

1) когда нужно всё упихнуть в единственный роутер
2) когда есть возможность разные функции разнести по разным роутерам ради "loose coupling" и "tight cohesion", для простоты каждого по отдельности и красоты общей картины.
(У меня например два пограничных роутера занимаются натом к разным провам, а третий - дефолтный шлюз в локалке и заодно занят policy routing)

LevT
Ну по поводу почтовых серверов внутри локалки, тут ИМХО, надо юзать DNAT, только, разумеется, без SNAT'а в сторону локалки.

А что простите вы называете всем? Эти 4 пункта? Тут имхо их надо вешать на одну машину. Разве что, reverse proxy для web-сервисов можно поднять отдельно, если количество внешних адресов позволяет.


Цитата:

(У меня например два пограничных роутера занимаются натом к разным провам, а третий - дефолтный шлюз в локалке и заодно занят policy routing)

если эти 2 роутера у вас только нятят а за ними стоит 3-ий который балансирует между ними нагрузку, то ИМХО бред - вы создали 2 лишних точки отказа.

Alukardd

Цитата:

Тут имхо их надо вешать на одну машину. Разве что, reverse proxy для web-сервисов можно поднять отдельно, если количество внешних адресов позволяет.

Хорошо бы рассмотреть оба варианта. У меня лично количество адресов позволяет, но мне интересны общие решения.



Цитата:

если эти 2 роутера у вас только нятят а за ними стоит 3-ий который балансирует между ними нагрузку, то ИМХО бред - вы создали 2 лишних точки отказа.

Ничего я такого не создал, поскольку они все виртуальные. )
Можно ещё штук тридцать таких рядом завести ) ) Можно и под соседним хостом, благодаря вмварным виртуальным свичам.

А можно их функции объединить (и настроить VRRP под разными хостами) - но не раньше, чем отлажу их по отдельности. Именно сборку-разборку, а не просто "сконфигурировать и забыть"


Добавлено:

Цитата:

только, разумеется, без SNAT'а в сторону локалки.

Гм, а как тогда они будут отсылать почту в интернет?

Кстати, раз уж кто-то (типа меня) готов выделить айпишник для реверс веба, то почему бы не повесить туда же и почтовый прокси, и прочую application layer фильтрацию?

LevT
Общее моё мнение такого, что если шлюз по своим вычислительным мощностям и ширине канала позволяет повесить на него все службы, которые логически подходят ему, то их надо вешать на него. В случае с фронтендами для web-серверов в виде nginx'а, я считают что если на бэкенд сервера ходит не 3 человека и серверов таких штуки 3 хотя бы есть, то можно и вынести nginx на отдельную машину (виртуальную или нет это ваше дело), если нагрузка почти нулевая, то вешайте всё на одну шлюзовую машину и не парьтесь.
Разумеется, что такую критичную точку надо дублировать (читай создавать HA кластер), причем делать это на физически разных машинах, во избежании казусов.

Я, например, при настройке gateway'ев, настройку веду только на одном, а потом уже готовую и настроенную систему клонирую на вторую машину. После чего обе проверяются и можно настраивать кластер или как-там будет решено (вплоть до тупого ручного передёргивания проводов).
Хотя если падения шлюза не критично, то можно и не заводить копию, а просто всегда иметь свежую копию системы, что бы в случае чего быстро её развернуть.

Alukardd

Цитата:

Общее моё мнение такого, что если шлюз по своим вычислительным мощностям и ширине канала позволяет повесить на него все службы, которые логически подходят ему, то их надо вешать на него.

Да я в принципе согласен: в случае статической продуктивной конфигурации это так. Но если нужна большая динамика (сборка-разборка-перенастройка) и/или недостаёт опыта и хочется большей модульности для изоляции своих ошибок...

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


Так что, прошу помощи с тем, ЧТО надо сделать на прокси и главное чего НЕ НАДО делать (выбор софта оставим на потом, тем более детали конфигов конкретного софта)

Допустим, надо опубликовать виртуальные хосты webservice1.domain.ru:80 и webservice2.domain.ru:80 на ext.ip.from.isp, фактические айпишники int.ip1.from.lan и int.ip2.from.lan

А _https://webservice3.domain.ru:443 ?


Добавлено:

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

LevT
Что касается виртуальных хостов, то в nginx и apache описывается обычный виртуальный хост и вместо указания пути к файлам сайта (читай DocumentRoot) используется директива proxy_pass, можно заворачивать как целый сайт, так и отдельные url (например, проксировать mysite.ru на 192.168.1.2, а mysite.ru/admin на 192.168.5.2).

В случае если надо проксировать https, то сертификаты придётся класть и настраивать для виртуального хоста на фронтенде. Далее если сервису это надо то можно потом эту информацию(о проверенном сертификате) завернуть в собственные заголовки (обычно это может потребовать при использовании клиентских сертификатов, а не просто при использовании https). Соответственно как вы поняли, над заголовками можно издеваться. Тут надо читать доку по конкретному web-серверу который будет выступать как frontend (например, тут по nginx)

Собственно удобство проксирования еще в том, что сзади можно держать сайты (или нечто их заменяющее) на любом порту.
Если на backend сервере, вы так же хотите оперировать виртуальными хостами (virtual hosts), то соответствующий заголовок следует заново установить (пример: proxy_set_header Host $host;). В противном случае стоящий сзади apache, например, просто не сможет отличить site1.ru от site2.ru и отдаст первый попавшийся (не помню как он решит кто из них лучше).

Спасибо! Очень ценно.

А что из перечисленного нельзя сделать сквидом (или можно, но извратно)?
Есть ли ещё какая-то им альтернатива с этим функционалом, максимально легковесная?

Это я перешёл ко второму пункту своей программы. )

Ну как бы вам сказать, squid умеет обратное проксирование, но это не его основное назначение - это всё прокси-сервер в привычном понимании - то через что клиенты ходят в инет.
nginx наоборот я не видел что бы использовали в качестве прямого прокси, он и не разрабатывался для этого (хотя такое извращение имеет место быть - proxy_pass $scheme://$http_host$request_uri; - можете погуглить на тему "nginx forward proxy"). nginx - типичный web-сервер, хорошо зарекомендовавший себя в роли frontend'а, в виду своего огромной пропускной способности при малом потреблении ресурсов.

Добавлено:
Альтернатива мб еще и есть, но зачем? За всем не угонишься... nginx сейчас более чем зрелый продукт с огромным запасом прочности.

Спасибо ещё раз.

Что осталось неясно из затронутого выше - как без SNAT и без полновесного почтового прокси инициировать исходящие соединения с локального почтовика наружу?

В иптаблесах есть для этого какое-то неизвестное мне сильное кунфу?

LevT
А почему без SNAT? Просто Вам ваш домен надо привязать к ip того шлюза через который будет выпущен почтовый сервер и для него прописать зону обратного просмотра и spf запись. Ну и прописать правила для DNAT'а подключений к почтовому серверу.
Я говорил только о том, что SNAT в сторону локалки делать низя ибо тогда вы не будете знать от кого пришёл запрос со всеми вытекающими...

Конфиги обсуждались тут
http://www.opennet.ru/openforum/vsluhforumID10/4881.html

LevT
Вот об этом я и говорю, не надо делать SNAT в сторону локалки без явной на то необходимости.

OMG рулить виртуальными хостами через iptables match string - ужОс. К тому же я не уверен, что такое правило вообще будет корректно работать, в виду того, что запрос может быть разбит на несколько пакетов, и имя сайта окажется только в первом, а правила работают для каждого конкретного пакета, а не их цепочки.
Что-то у меня тупняк... А DNAT кажется ведь тоже не на каждый пакет применяется, а делает это на сессию один раз. Или нет? А-а поможите - у меня что-то заскок... Всё, конечно же применяется правило только к первому пакету а все остальные идут как RELATED, ну или даже как ESTEBLISHED.

Alukardd
Так вышло, что Zentyal у меня уже стоит (в виртуалке ненастроенный, про запас).
Сперва хочу с помощью "коробочки" смоделировать обратный прокси и получить рабочую конфигурацию nginx.
Как думаете, с каким его компонентом он устанавливается? (apt-get -ом воспользуюсь только в крайнем случае, чтобы без нужды коробочку не рушить)

LevT
Цитата:

Так вышло, что Zentyal у меня уже стоит

Э-э, у меня так не вышло... Так что тут я вам не помогу.
Конечно, не хотелось бы вылезать за рамки данной темы, но думаю отдельные вопросы можно задать в конкретной теме - Software Routers&Firewalls (Программные маршрутизаторы). Или подождать пока здесь Ваш вопрос кто-нить найдёт)

С конфигурацией nginx помогу.

LevT А что, получить пул белых адресов совсем не вариант?
У меня, например, есть сетка /28 от одного прова и /28 от другого прова. На все про все хватает, ни в чем себе не отказываю.

vlary
Да есть у меня лично адреса... Правда не /28, а /29, и не от обоих провайдеров, а от одного из двух (второй, билайн, захотел развести меня на какой-то геморрой с бумажным обоснованием необходимости /29, так что я на это забил.)

Всё-таки, адреса ресурс ограниченный извне, не всегда доступный админу. Хочется найти демократичное решение для всех.


Добавлено:
Alukardd

Ещё вариант, если по нему поможете будет отлично

Nginx стоит у меня в коробочке bigbluebutton.org, собственно эта коробка один из вебсервисов зависимых от virtual hosts, именно его мне надо опубликовать в первую очередь.

В нём есть автомагический скрипт, и в FAQ написано как его применить bbb-conf --setip bbb.domain.ru (вкупе с DNAT на шлюзе и модификацией /etc/hosts

Цитата:

bbb.domain.ru int.ip1.from.lan

)


И это даже начинает работать для внешних клиентов - но нгинкс после этого истерит для внутренних, обращающихся к нему по циферькам из локалки. Думаю, что ему-то лично будет достаточно SplitDNS

Как оцените идею использовать именно тот nginx для экспериментальной публикации остального добра? Придётся для этого отказаться от автомагического конфига и выставить коробочку в интернет (добавив ей внешний интерфейс).

LevT
Я не понял что делает bbb-conf... Единственное сто понял, что после этого nginx не отвечает на внутренние запросы по своему внутреннему ip. В любом случае, если вы примитивно своим bbb не нарушили обыкновенную маршрутизацию в сети, то nginx должен вернуть ближайший "сервер" который он слушает по указанному ip.

Короче, я не особо понял что вы сделали и что произошло)

bbb - сервер видеоконференцсвязи, навороченная конструкция с томкатом и фрисвичем внутри (среди прочего)

Мне самому этот их скрипт смены адреса показался хлипким, я в ужасе откатился к снапшоту первоначальной конфигурации (dhcp). Сам ни в жисть туда внутрь виртуальной коробочки не полезу со своим нынешним Elementary уровнем компетенции в никсах.

Но... гложет мысль не ставить отдельный нгинкс, раз он уже есть прямо сейчас в bbb. Но! без мудрого руководства я точно сам не справлюсь.

LevT

Цитата:

второй, билайн, захотел развести меня на какой-то геморрой  с бумажным обоснованием необходимости /29, так что я на это забил.

Так это обычная практика, IANA требует от них, они от клиентов.... Я, помнится, пару раз сетку /24 получал, приходилось всякую липу писать, типа в этом году у нас 130 хостов, через год будет 200, через два - 250.

Ну... я как-то по-старинке привык /29 получать за небольшую безналичную денюжку, без волокиты (тем более за каким-то хреном офлайновой).


Добавлено:

Вообще, билайн это песТня. Они взятку платили 40 тыр в соседний ДЭЗ, циску нам поставили 881...
А денег не берут, никаких. Уже полгода. ))
...Вру!! На прошлой неделе прислали пачку счетов по 150 руб. за /30 И больше ничего.

Добавлено:

Видимо, смысел бузинесса ихнего какой-то иной, с собиранием денех не связанный.


Добавлено:

Подключали тоже без малого полгода... Наобщался с ними вдоволь, больше не хочу. Работает и ладно.

Alukardd

Спасибо! Сделал у себя я почти всё из заявленной программы, но остаются некоторые неясности.

Я решил всё-таки сохранить разграничение отвественности роутеров. За SNAT/маскарадинг отвечает один шлюз snat-gw (с балансировкой двух каналов и файловером между разными провайдерами).

За DNAT на опубликованных в интернет айпишниках каждого прова (в моей ситуации пока только одного из двух) отвечает другой шлюз: dnat1-gw.

Внутренние вебсерверы отдают контент через специально установленный внутри локалки хост с nginx. Выставленные в интернет 80-й и 443 порты DNAT-ятся на тот хост.

Один из работающих через nginx вебсерверов сидит на внутреннем интерфейсе snat-gw



Первый вопрос. Пока что оба моих шлюза прямо прицеплены и к интернету, и и к локалке. В результате получилось, что для возможности захода из интернета по SSH или RDP на внутренние вебсерверы мне пришлось поменять на тех дефолтный шлюз. (Один из вебсерверов по совместительству почтовый прокси, так что туда днатятся заодно ещё и почтовые протоколы.)

Да, в связи с этим еще и перестали роутиться с рядовых хостов и серверов локалки ответные пакеты впн-клиентам (старый впн был терминирован на dnat1-gw).


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

- выстроить нынешние шлюзы и веб-прокси один за другим ("физически"? с помощью адресации, с учетом агрегации маршрутов?)
- соорудить что-то вроде DMZ. Привлекателен вариант терминировать VPN в DMZ
вланы я могу городить в своей нынешней сетке произвольным образом, но интересно и общее решение, когда нет такой возможности
- что-то ещё?


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

Шлюзу snat-gw в скором будущем предстоит стать mx-обменником для нескольких доменов (наверное это нарушение моей схемы, и обменниками надо бы делать dnatN-gw...)

Как порекомендуете обойтись?


Третий вопрос. Помогите потом организовать никсовую админ.станцию. Надо одновременно ходить снаружи на многие внутренние SSH реcурсы многооконным клиентом, сохраняющим настройки. tmux на шлюз snat-gw влепить? (это Zentyal) Использовать SecureCRT на удалённой станции и ходить через ssh-прокси?

Дайте первоначального пинка в верном направлении.


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

LevT
Начнём с того что я понял. На кой чёрт вам взбрело в голову реализовывать SNAT на одном роутере, а DNAT на другом я знать даже не хочу. Могу сказать что это глупость, а дальше Вы сами решайте. Что бы пакеты повзращались к DNAT'ящему роутеру, вместо шлюза по умолчанию (читай snat-gw) надо выполнять на dnat-gw snat в сторону локалки. При такой канители вы правда не увидите адрес клиента на конечном сервисе, увы.

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

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

Цитата:

Что бы пакеты повзращались к DNAT'ящему роутеру, вместо шлюза по умолчанию (читай snat-gw) надо выполнять на dnat-gw snat в сторону локалки.

Ну не обязательно. Роутеры все виртуальные под одной физической машинкой. Например, можно вернуть в схему третий виртуальный роутер - дефолтный шлюз для локалки. Сегменты между ним и граничными роутерами логично считать относящимися к DMZ (у меня туда терминировался только VPN, а вебсервисы предоставлялись из локалки).

Так у меня и работало до недавнего, и неплохо (тот третий роутер занимался еще балансировкой трафика).

Но назрела необходимость осилить наконец nginx, ну и подвернулась возможность разобраться с Zentyal - и вот я заменил им один из граничных микротиков, и балансировщик заюзал тамошний. А раз один из граничных роутеров потяжелел, возникла мысль обойтись без третьего роутера.


Добавлено:

Многооконный клиент - это например SecureCRT под виндой. Но я не хочу больше пробрасывать на роутере отдельный форвардинг для каждого внутреннего сервера, а хочу задействовать что-то типа реверс-прокси для SSH.

В принципе, не прочь и линуксовую какую-нибудь подобную софтинку освоить вместо виндового клиента, но другой админской станции кроме snat-gw (оно сразу с иксами) у меня пока нет



Добавлено:

VPN, к которому подключаются юзеры, использую тоже для админдоступа, но в моих схемах всегда закладывается избыточность - чтобы пока я эксприментирую и перенастраиваю что-то на одном канале, сервисы предоставлялись через другой. Чтобы если понадобится отключить VPN для перенастройки, под рукой был реверс-прокси. Чтобы если случится неведомая херня с одним из сетевых сервисов по причине моей ошибки (давно что-то уже такого не было...) оставались запасные рабочие варианты, а у меня неопределённое время на ПРАВИЛЬНОЕ разруливание, даже если нужно изучить что-то новое. И т.д.


Добавлено:

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

LevT
Цитата:

например SecureCRT

1 - он кроссплатформенен. 2 - ни когда ни чем подобным не пользовался. В Linux у меня есть эмулятор терминала (gnome-terminal + openssh, ну и nautilus with sftp, на крайний случай можно и scp и mc+fish), в винде putty и winscp.

Так а для reverse proxy вы же всё равно описываете правило для каждого хоста, так чем он предпочтительнее для вас?

Цитата:

1 - он кроссплатформенен. 2 - ни когда ни чем подобным не пользовался.

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

"Реверс-прокси" - может, я не тот термин употребил? Знаю, что линуксоиды используют какой-то SSH-форвардинг, собственный опыт здесь нулевой - но я не прочь его приобрести.


Добавлено:

Цитата:

Но я не хочу больше пробрасывать на роутере отдельный форвардинг для каждого внутреннего сервера,

Я имел в виду порт-форвардинг через DNAT


Добавлено:

Я не прочь выработать в этой теме эталонную гибкую и правильную схему SMB-роутинга на все случаи жизни.
Позволить себе иметь физический хост под виртуализацию роутеров и проксей сейчас могут все.

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

LevT
Цитата:

линуксоиды используют какой-то SSH-форвардинг

есть 2 способа попасть во внутрь сети имея ssh доступ к шлюзу.
1 - фича ssh - ForwardAgent. Очень доходчиво тут.
2 - еще есть проброс портов через ssh. В OpenSSH ключ -L. [more=Выдержка из man'а]-L [bind_address:]port:host:hostport
Specifies that the given port on the local (client) host is to be forwarded to the given host and port on the remote side. This works by
allocating a socket to listen to port on the local side, optionally bound to the specified bind_address. Whenever a connection is made to
this port, the connection is forwarded over the secure channel, and a connection is made to host port hostport from the remote machine.
Port forwardings can also be specified in the configuration file. IPv6 addresses can be specified with an alternative syntax:
[bind_address/]port/host/hostport or by enclosing the address in square brackets. Only the superuser can forward privileged ports. By
default, the local port is bound in accordance with the GatewayPorts setting. However, an explicit bind_address may be used to bind the
connection to a specific address. The bind_address of “localhost” indicates that the listening port be bound for local use only, while an
empty address or ‘*’ indicates that the port should be available from all interfaces.
[/more] - не придумал лучшего объяснения, если не понятно спрашивайте. Пример: ssh -L 9765:192.168.1.15:22 admin@snat-gw, это выполняем на своей машине снаружи. После чего остаётся висеть ssh сессия, а мы тем временем в другом окне терминала открываем сессию на внутренний хост - ssh -p 9765 user@localhost Вас закинет на внутреннею машину. Побочный эффект в том, что при это клиент добавит fingerprint 1.15 сервера в known_hosts и потом будет ругаться, если вы на этот же порт (9765) в будущем прокинете другую машину (MITM'ом попахивает), посему надо либо использовать разные порты, либо чистить иногда known_hosts. Кстати если изменится fingerprint у машины через которую Вы прокидываете (шлюз), то ключ -L будет проигнорирован как небезопасный для сомнительного соединения.

Спасибо!
Вот Вы сами и подтвердили, что манов (описывающих КАК делать что-то), недостаточно, если не знаешь ЧТО ещё можно сделать.

О двух альтернативах я узнал только что от Вас.


Добавлено:

И за дополнительное разъяснение спасибо тоже.

Разъяснение для таких как я (только сейчас допёрло!):

SSH форвардинг создает локальный прокси (сервис на машине где запущен SSH-клиент). Именно к нему и надо подключаться.

Я правильно понял?

Много лет назад я уже так делал по случайному гайду - но конструкция настолько противоестественная для благонамеренного виндузоида, что было отвергнуто разумом и не осело в мозгах.


Добавлено:
Alukardd

Цитата:

Побочный эффект в том, что при это клиент добавит fingerprint 1.15 сервера в known_hosts и потом будет ругаться

Я пока вовсе не осилил авторизацию в SSH по сертификатам (это обстоятельство меня дополнительно придерживает на многооконных клиентах, автоматизирую ввод пароля VB-скриптами).

Как к ней лучше подступиться? Пошагово.

Certification Authority моя инфраструктурa позволяет использовать Zential-овскую.