Как стать автором
Обновить

Комментарии 26

Было бы неплохо рассказать про плюсы и минусы относительно winexec.
Я не пробовал winexec, поэтому сравнить не смогу. К тому времени, когда вышла статья на хабре про winexec, у меня уже давно работала система на freeSSHd. Работала (и работает) почти без проблем, а написать собрался только 5 лет спустя, может кому-нибудь пригодится.
Некоторые проблемы появились только на последних версиях Windows — потребовалась настройка Брандмауэра.
Один момент, который в некоторых случаях имеет значение — winexec, как я понял использует RPC. Это либо авторизация в домене, либо локальные пользователи (с админ правами). В принципе все правильно, если все в одном домене.
Но иной раз появляются в сети ноутбуки с Home версией Windows — в домен его уже не введешь. В случае с freeSSHd все инвариантно к домену, системе и т.д. — решается на уровне ssh протокола, который вполне надежный, защищенный, нужен только публичный ключ, который и защищать не нужно.
А нет ли чего-то подобного для PowerShell разве?
В смысле скрипт на PowerShell слушает на сокете команды, которые ему посылает клиент (в данном случае из Линукса)? Мне пока такие решения не попадались.
sharpcodenotes.blogspot.ru/2014/01/running-powershell-commands-from-linux.html
Да, интересная вещь, этот WSMAN, спасибо за подсказку. Только когда я делал свою систему, он еще не был на слуху. Да и сам PowerShell тогда только появился
Зачем telnet в конфиге?
Под каким пользователем windows работает ssh-сервис и от чьёго имени будут выполняться команды?
Зачем везде вызовы cmd, если 1) она и так указана в SSHCMD и 2) большинство команд не нуждаются в консоли?
Поясните, пожалуйста, ключи при подключении по ssh, особенно обнуление knownHosts.

> Демо-програмка на Python, которая опрашивает компы в диапазоне
Поздравляю, вы изобрели Ansible.
В конфиге описывается даже то, что не живет:
TelnetRun=0
— он не стартует (поскольку дыра)

-2 — версия протокола (оказалось существенно)
-q — без лишних предупреждений
-i <my_key_files_path>/id_dsa -ladmin — тут все понятно
-oStrictHostKeyChecking=no — иначе будет ждать подтверждения о принятии нового хоста
-oUserKnownHostsFile=/dev/null — если на том же IP адресе/имени оказался другой хост (редко, но случается), защита ssh отвергнет коннект. Здесь у нас всегда все хосты новые (каждый новый — плевок в пустоту). В купе с опцией -q лишних вопросов не будет.
Понимаю, что где-то нарушил секюрность, но несильно.
Наверное, стоит тогда убрать из конфига всё остальное про telnet, чтобы не вводить в заблужедение.

> Понимаю, что где-то нарушил секюрность, но несильно.
Как-то вообще не секурно. SSH предупреждает и не даёт подключаться к хосту, если внезапно изменился его ключ. И это правильно, т.к. позволяет заметить mitm (подмену ключа).
Конфиг стандартный, его генерит сама программа в момент установки. Поэтому придется оставить все пункты, а ненужное отключить явно.
Защита SSH немного нарушена, но атака подменой ключа в данном случае бессмысленна — атакующий не подключается к серверу, это сервер подключается к нему и выполняет на нем команду (может быть даже команду заливки другого образа).
Ну и почему так было сделано — на компах установлено несколько ОС, а загрузка выбирается по сети (PXE). Поэтому на одном IP может оказаться другой хост и в стандартном варианте SSH отвергнет соединение.
>Поздравляю, вы изобрели Ansible.
Нас уже 6 миллиардов (даже больше) — велосипедов, в пределе, можем изобрести где-то столько.
> Под каким пользователем windows работает ssh-сервис
SYSTEM
Т.е. как-то образом авторизовавшись в ssh, не важно, под каким именно пользователем, я получу неограниченные привилегии в Windows?
Да. Только надо иметь закрытый ключик. Это считается надежнее, чем аутентификация по паролю.
> Зачем везде вызовы cmd
так оказалось универсальнее. Практически всегда работает. Без этого — только отдельные команды. Умом винду не понять, аршином общим не измерить…
Нужно не мерить своим аршином и своим умом (изобретателя своего велосипеда), а использовать стандартные для данной OS методы :)
> большинство команд не нуждаются в консоли
немного не понял, но есть программы, который выводят в форточки, а есть — в консоль. В Винде первых больше. Ну и не нашел я этой фразы в тексте??
Из ваших примеров: зачем консоль (cmd /c) для shutdown, для установки 1С, тем более, когда в конфиге уже есть SSHCMD=C:\Windows\system32\cmd.exe?
Это фича сугубо FreeSSHD, которому нужна консоль и для авторизации пользователей и для запуска любой команды, или просто для пущей уверенности?
Да, shutdown работает и без cmd /c. Но многие команды без этого не работают. Нужно универсальное решение. Например, запустить командный файл, расположенный на сетевом ресурсе.
Если компьютеров много, нужно сразу взять Ansible (раз уж вы начали про sshd).

Мы для себя выбрали SaltStack, у него родной клиент для windows, умеет в том числе и запускать что-то. Прелесть варианта «с клиентом», что компьютеру, которым нужно управлять из центра, достаточно иметь выход наружу, то есть он легко может находиться за кучей NAT.
Ansible не дружит с Windows.
SaltStack, судя по отзывам, еще недостаточно стабилен.
У меня задача собственно была простая — все компьютеры в локалке (учебные классы), нужно иметь возможность их удаленно перезагрузить/выключить, запустить копирование данных с сервера, запустить установку обновлений.
Все это через freeSSHd получилось просто и стабильно.
Ну и кстати, управление успешно работает не только из Linux, но и из Windows (используя пакет Putty)
Судя по docs.ansible.com/intro_windows.html
Starting in version 1.7, Ansible also contains support for managing Windows machines. This uses native PowerShell remoting, rather than SSH.

Ansible will still be run from a Linux control machine, and uses the “winrm” Python module to talk to remote hosts.

No additional software needs to be installed on the remote machines for Ansible to manage them, it still maintains the agentless properties that make it popular on Linux/Unix.
и списку модулей на docs.ansible.com/list_of_windows_modules.html должен уметь. Но утверждать не буду, т.к. сам работаю с ним только для Linux.
Если руки дойдут — могу проверить базовую поддержку для Windows.
Это уже интересно.
Жалко, правда, что не удастся авторизоваться через ssh public key — просто и надежно, а здесь — uses native PowerShell. Если все в одном домене/лесе, то нормально, а если есть Home Edition, то сложнее.
И вот еще один момент —
PowerShell 3.0 or higher is needed for most provided Ansible modules for Windows, and is also required to run the above setup script. Note that PowerShell 3.0 is only supported on Windows 7 SP1, Windows Server 2008 SP1, and later releases of Windows.

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