Comments 33
Чем winexe из openvas лучше этого: sourceforge.net/projects/winexe/?
А вообще у описанного метода есть ещё одна проблема: если запустить cmd удалённо командой
winexe -U domain/user%password //server 'cmd'

не работают клавиши управления курсором, backspace и delete (по крайней мере у меня из Konsole не работают) — придётся набрать команды без ошибок.
Не нажал ответить, когда отвечал на ваш комментарий. Ещё раз спасибо. Однако не смог собрать winexe из тех исходников слёту. Будем «посмотреть». :)
Спасибо, кстати :) Почему-то пропустил winexe на sourceforge. Он, судя по номеру версии, всем должен быть лучше :) Пропустил видимо из-за того, что искал в основном wmic. Проблема с клавишами актуальна, но я планирую встраивать winexe в скрипты, дабы автоматизировать разные рутинные действия.
На всякий случай сразу предупрежу — при использовании winexe в скриптах я наблюдал некоторые проблемы с обработкой данных из его вывода. Насколько помню проблема проявлялась при запуске winexe внутри исполняемых кавычек, когда результат пытался присвоить переменной (больше подробностей, к сожалению, за давностью вспомнить не могу).
Опять таки спасибо :) Буду знать, на что натолкнусь в будущем.
UFO landed and left these words here
Цитирую — «В целом руководствовался тем, что конкретная рабочая машина, настроенная один раз будет управлять любой дефолтной Windows-машиной, на которой запущен RPC и есть права». В разы меньше трата времени.
это, кстати, моё личное мнение :)
Между прочим, ssh через cygwin вполне себе работает, если его настроить (с этим, конечно, есть определенный гемморой :))
настроить! :) в этом и кроется причина, не хочу настраивать. тем более на пользовательской рабочей станции, расположенной в 200км от меня. :)
А все-таки? Один скрипт в групповых политиках, прописывающий telnet-сервер (возможно на нестандартном порту) с заданными исключениями брандмауэра(если надо)? Не? И управляемость в разы выше, и выделенную машину настраивать не надо, и все стандартными средствами.
Не все машины в домене пока, в моём случае, к сожалению. Кроме того, выделенной машины нет, это просто моя рабочая машина, так сложилось :) но в целом — вы совершенно правы, так было бы даже ещё проще. У вас схема с телнетом работает? Или это теория? Это я к вопросу групповых политик, которые не всегда работают, как хочется, особенно учитывая windows-зоопарк на большинстве АРМ. (Это конечно проблема, которую надо решать кардинально, сами виноваты :) но не всё зависит от меня)
Насчёт управляемости, если честно, не понял — разница какая, по большому счёту? консоль и консоль.
В любом случае, telnet — тоже прекрасный вариант. :)
У меня работает многое другое, и скрипты доменных политик сбоев никогда не давали. Ради интереса могу попробовать развернуть и описать, как будет работать, но лично у меня особой необходимости никогда не возникало — Windows удобнее админить через GUI.
UFO landed and left these words here
UFO landed and left these words here
Значит так! Было дело — убил две недели. Было необходимо через ssh выполнять exe на компе. Какие проги я только не перепробывал! Проблема была в том, что при вызове кой либо программы из процесса SSHD, она выполнялась не от ID текущего залогиненого юзера, а следовательно, не показывалась у меня на экране и у необходимого приложения не находилась лицензия.

Ад был:
Между cygwin. (все остальное тоже самое ток в профиль)
Между запуском cygwin через планировщик заданий от имени администратора-себя (обязательно он дожен был быть не кириллическим)
Это был какой то ад между использованием technet.microsoft.com/en-us/sysinternals/bb897553
Между раздачей прав через cygwin на какую то папку.

Было проще поднять вебсервер и какой нить скрипт прифигачить.
Есди нужен ftp, то filezilla server на ура.
Задача должна решаться от простого к сложному, а не наоборот. Windows предоставляет достаточно большой набор средств для администрирования, включая и командную строку, и WMI, и WSH, и Powershell. ИМХО, Ваша ошибка заключается в том, что Вы реализуете подход для Linux в среде Windows.
Абсолютно согласен. Я думал вижу дно колодца, а потом надо было добить паскуду, просто добить)
Мы пытались малыми жертвами именно от простого к сложному. Оказалось сделать сложное было быстрее раза в 2.
Оно было не оконное ( но ругалось на отсутсвие лицензии при инициализации(.
Вообще да, cygwin и sshd лучше всего подходят для запуска unix-like команд или просто cygwin'овских, с обычными приложениями может быть много проблем.
Вот примерно VBScript для развертывания telnet в домене (опробовал на Win8, если не совсем так работать будет, извините, надо пилить):

Dim WshShell, OsVer
Set WshShell = CreateObject(«WScript.Shell»)
OsVer = Left(WshShell.RegRead(«HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\CurrentVersion»),1)
If OsVer=6 Then WshShell.Run «pkgmgr /iu:»&Chr(34)&«TelnetServer»&Chr(34),0,True
WshShell.Run «sc config TlntSvr start= auto»,0,True
WshShell.Run «net start Telnet»,0,True
Автор описал прекрасный, универсальный метод управления Windows ПК с Linux машины, без установки Windows ПК дополнительного ПО! Управлению любым Windows ПК (по крайней мере начиная с 2000-ной рабочей станции!)
Единообразному управлению вне зависимости от версии ОС на Windows ПК.
Варианты же с установкой на Windows ssh+cygwin или telnet — «велосипеды» имеющие кучу недостатков.
Главный недостаток:
Установка ПО на одном ПК всегда вызывает больше проблем, чем установка ПО на большом парке машин (особенно если этот парк машин наращивался много лет).
Спасибо за отзыв! К сожалению, у метода, как вы ранее подметили, есть недостаток с управляющими клавишами, но я надеюсь это решить :)
Во-первых, способ неплох, не спорю, но и telnet-сервер входит в базовую поставку системы. Во-вторых, в случае разветвленной сети можно каскадно подключаться с машины на машину (попробуйте описанным способом воткнуться в шелл машины, сидящей за NAT без проброса портов). В-третьих, доступ появляется с любой железки, имеющий встроенный telnet-клиент. Заведомо отказываться от преимуществ, видя недостатки — это не есть хорошее решение.
попробуйте описанным способом воткнуться в шелл машины, сидящей за NAT без проброса портов

Я правильно понимаю, что Вы собрались использовать telnet для соединения через общественные сети??? (Я пока сталкивался только с одним сценарием использования NAT внутри «серых» сетей и то — это было просто недоразумение)
Тут telnet и в своей, подконтрольной сети стараешься не использовать…
Давайте предположим хотя бы такой сценарий — есть закрытая распределенная корпоративная сеть с адресацией 10.0.0.0/8. Вам выделена определенная подсеть, вы администрируете в рамках своего участка. Вы организуете свою дополнительную сеть 172.16.100.0/24, которая должна иметь доступ к хостам из сети 10.0.0.0/8. Поскольку прописать маршрут к сети 172.16.100.0/24 на сетевых устройствах Вы не можете, единственный выход — использовать NAT. Далее, чем плох telnet — трафик идет без шифрования. А в статье трафик защищен?
Вы организуете свою дополнительную сеть 172.16.100.0/24

Извините, но если это в пределах одно организации… ИМХО. за такое по рукам надо бить…
Далее, чем плох telnet — трафик идет без шифрования. А в статье трафик защищен?

Тем, что его слушать сможет любой пионер, насмотревшийся youtube
Для того, чтобы просмотреть содержимое rpc сессии потребуется немного больше усилий.
Честно скажу, не знаю как реализован RPC в winexe, но насколько я понимаю, в самом протоколе есть возможность шифрования.
И в указанной вами схеме — участки распределённой корпоративной сети разве идут по общественным сетям нешифрованные?
Нет, конечно. Вопрос был задан по сценариям использования NAT в одной сети.
Автору спасибо за статью! Очень удобный способ удалённого запуска, и програм никаких на Windows®(tm) ставить не надо.
Всегда пожалуйста, очень надеюсь, что пригодится не только мне.
Only those users with full accounts are able to leave comments. Log in, please.