Concordo com @slm que isso é algo de uma questão limítrofe. A verdade é que o Windows incorpora seus próprios protocolos de acesso remoto à medida que seu sistema Unix incorpora os seus próprios protocolos de acesso remoto. O Microsoft Powershell amadureceu bastante desde que foi introduzido no Vista, e pode fazer a maioria, se não todas as coisas que você espera que um script de shell faça por você no seu sistema Windows. Por exemplo, de acordo com technet :
The Windows PowerShell remoting features are supported by the WS-Management protocol and the Windows Remote Management (WinRM) service that implements WS-Management in Windows. Computers running Windows 7 and later include WinRM 2.0 or later. On computers running earlier versions of Windows, you need to install WinRM 2.0 or later as appropriate and if supported. Currently, remoting is supported on Windows Vista with Service Pack 1 or later, Windows 7, Windows Server 2008, and Windows Server 2008 Release 2.
É claro que fazer uso disso de um cliente Linux apresenta alguns problemas, mas espero que uma máquina virtual resolva a maioria deles, ou até mesmo apenas um netcat ou ssh proxy. Contribuindo 5 minutos e o uso de um mecanismo de busca para minha leve curiosidade e agora sei do projeto Pash , embora eu faça não há alegações sobre sua utilidade.
ATUALIZAÇÃO:
No decorrer de mais uma vez entreter essa curiosidade leve, revisitei o Pash sourceforge page e navegou um pouco mais. Ao fazer isso, percebi que os PROJETOS RECOMENDADOS incluídos incluíam não apenas o winexe que @slm recomenda, mas outro que eu nunca tinha ouvido falar chamado win-bash . A partir da descrição:
Unlike other bash ports for Windows (e.g. the cygwin bash ), the win-bash needs no special environment or DLLs. There is just one binary and that's it.
The goal of the win-bash project is to finish the port to Windows and provide a fully-functional bash.exe binary for Windows NT and derived systems. win-bash can be used as an input shell, as well as an interpreter to run UN*X shell scripts.
O que eu acho significativo sobre o que foi dito em relação a essa pergunta é sua natureza autônoma. Se não houver dependências de biblioteca ou registro, um executável do Windows poderá ser executado remotamente - por exemplo, a partir de um compartilhamento de arquivos - sem a instalação. Portanto, é possível que você possa se conectar remotamente a uma máquina usando protocolos nativos do Windows (possivelmente também com ou incluindo winexe ), executar um powershell ou net use comando para mapear um compartilhamento de arquivo, executar seu script de shell via win-bash, , então desmapear o compartilhamento e encerrar a conexão sem ter que copiar nem mesmo um único arquivo para o host remoto.
Eu digo que é concebível, mas funciona? Eu não sei, embora eu possa descobrir.
Eu gosto de manter uma imagem atual win pe na partição EFI do meu sistema para que ela esteja disponível para rEFInd (e inicializável, obrigado para um iPXE hack ou dois). Até agora eu o personalizei apenas para bloquear o início da instalação padrão do Windows e configurá-lo para abrir um prompt cmd intermediado por netcat, porque cygwin pareceu-me ser uma grande tarefa para pouco retorno, mas agora a minha curiosidade anteriormente branda está crescendo ... Eu provavelmente voltarei com um relatório sobre minha experiência depois de adicioná-la ao meu pe imagem.
END UPDATE
@slm menciona winexe , que eu nunca tinha ouvido antes, embora eu esteja interessado agora. Ele também menciona wmic como uma ferramenta que você pode usar, e é uma ferramenta que eu mesmo usei com frequência - ela concede um acesso bastante poderoso ao backend do Registro usando a sintaxe semelhante a SQL.
Eu sei que se você deseja executar .cmd scripts baseados em regras específicas, há o Gerenciador de Tarefas do Windows e a Política de Grupo do Windows, os quais, como eu acredito, você pode influenciar pelo menos até certo ponto via wmic.
Por fim, direi que o código de portabilidade de um sistema operacional para outro não é feito com a frequência que gostaríamos por uma razão: é problemático por sua própria natureza. Diferentes sistemas operacionais se comportam de maneira diferente, pelo menos porque são diferentes. ssh por exemplo, pelo menos na minha experiência, era incapaz de lidar com as permissões graduais do Windows e exigia acesso em nível de sistema ou simplesmente não funcionava, embora netcat pareceu aceitar o nível de permissões da conta de usuário sob a qual eu o executei. Powershell, como eu mencionei acima, pode ser uma ferramenta extremamente tediosa se usada para analisar strings, como você pode estar acostumado a fazer em um ambiente Unix, porque trata tudo como um objeto em si mesmo. Então boa sorte.