development environment: editors and shells, Python, the Visual Studio 2022
toolchain (including the Clang and Windows XP targeting toolsets), the Windows
Driver Kit, and a handful of analysis tools (Sysinternals, OpenCppCoverage,
-BinSkim, the Windows Performance Toolkit).
+BinSkim, the Windows Performance Toolkit). It also sets the box up to be driven
+remotely: OpenSSH Server plus an rsync build for Windows, which is what makes a
+throwaway VM reachable from a Linux host.
## Files
| File | Purpose |
| --- | --- |
| `setup-windows.bat` | Entry point. Runs the non-elevated, per-user half (winget installs, user `PATH` edits, global git config), then launches the elevated half and prints its log. |
-| `setup-windows-with-uac.ps1` | The elevated half, started via UAC by the batch file. Enables `ssh-agent`, installs Visual Studio 2022 Community with the required components, the WDK, and the Windows Performance Toolkit. Can also be run directly from an Administrator prompt. |
+| `setup-windows-with-uac.ps1` | The elevated half, started via UAC by the batch file. Enables `ssh-agent`, installs and starts OpenSSH Server, installs `rsync.exe` to the machine `PATH`, then installs Visual Studio 2022 Community with the required components, the WDK, and the Windows Performance Toolkit. Can also be run directly from an Administrator prompt. |
## Usage
script; the batch file prints it when the elevated window closes. The log is
gitignored, as it contains local paths.
- Both halves are idempotent — re-running skips anything already installed.
+ BinSkim in particular checks NuGet for the newest stable version *before*
+ downloading: the package is a self-contained .NET build well over 100 MB, and
+ re-provisioning an up-to-date box should not pay for it. The installed version
+ is tracked in `nupkg-version.txt` beside the tool.
+- **Remote access.** OpenSSH Server is installed from the Windows on-demand
+ capability (10/1809+), set to start automatically, and given an inbound TCP 22
+ firewall rule on *all* profiles — a VM's host-only or bridged adapter is
+ routinely classified Public, which is the usual reason a running `sshd` is
+ unreachable. Windows ships no `rsync`, so a build of it
+ ([nuket/rsync-windows](https://github.com/nuket/rsync-windows)) is installed to
+ `C:\Tools\rsync` and added to the **machine** `PATH`. That last detail matters:
+ the remote end of an `rsync` runs non-interactively, with no login shell, and
+ Win32-OpenSSH builds that environment from the registry `PATH` rather than from
+ a profile. Key auth needs `~/.ssh/authorized_keys` ACL'd to just you and
+ `SYSTEM`; accounts in the Administrators group use
+ `C:\ProgramData\ssh\administrators_authorized_keys` instead.
- Visual Studio is installed in three labelled passes (base workload, Clang/LLVM,
XP toolset) so a failure identifies which component group is responsible.
- The scripts were extracted from a native Windows project, so the component