+# ---------------------------------------------------------------------------\r
+# OpenSSH Server (sshd)\r
+#\r
+# Used to reach the test VMs (VirtualBox) from the host: remote shell plus the\r
+# transport rsync rides on when seeding test data in. Ships with Windows 10\r
+# 1809+ / Windows 11 as an on-demand capability, so no third-party install.\r
+#\r
+# The capability normally adds the "OpenSSH Server (sshd)" inbound firewall\r
+# rule; we verify and create it if missing (it is absent on some images).\r
+#\r
+# Non-fatal: a box that can't run sshd should still finish provisioning.\r
+# ---------------------------------------------------------------------------\r
+Write-Step 'OpenSSH Server (sshd)'\r
+try {\r
+ $sshd = Get-WindowsCapability -Online -Name 'OpenSSH.Server*' |\r
+ Select-Object -First 1\r
+ if (-not $sshd) {\r
+ Write-Warning 'OpenSSH.Server capability not offered by this Windows image - skipping.'\r
+ } else {\r
+ if ($sshd.State -ne 'Installed') {\r
+ Write-Host " Installing $($sshd.Name) ..."\r
+ $r = Add-WindowsCapability -Online -Name $sshd.Name\r
+ if ($r.RestartNeeded) { Write-Host ' [reboot required after OpenSSH Server]' -ForegroundColor Yellow }\r
+ } else {\r
+ Write-Host " OK: $($sshd.Name) already installed"\r
+ }\r
+\r
+ Set-Service -Name sshd -StartupType Automatic\r
+ if ((Get-Service sshd).Status -ne 'Running') { Start-Service sshd }\r
+ Write-Host ' sshd: Automatic + running'\r
+\r
+ # Firewall: allow inbound 22 on all profiles. VirtualBox host-only and\r
+ # bridged adapters are frequently classified Public, and the capability's\r
+ # own rule is Private-only on some images, which is what leaves a plainly\r
+ # running sshd plainly unreachable.\r
+ #\r
+ # OpenSSH-Server-In-TCP is the name the capability itself uses, so this\r
+ # WIDENS that rule rather than adding a second one next to it. Creating\r
+ # our own under a different name would leave the narrow rule in place and\r
+ # the box still unreachable on a Public-classified adapter; creating one\r
+ # under the same name would collide. Adopt it if present, create it if not.\r
+ $ruleName = 'OpenSSH-Server-In-TCP'\r
+ if (Get-NetFirewallRule -Name $ruleName -ErrorAction SilentlyContinue) {\r
+ Set-NetFirewallRule -Name $ruleName -Enabled True -Profile Any\r
+ Write-Host " Widened firewall rule $ruleName to all profiles"\r
+ } else {\r
+ New-NetFirewallRule -Name $ruleName -DisplayName 'OpenSSH SSH Server (sshd)' `\r
+ -Enabled True -Direction Inbound -Protocol TCP -Action Allow `\r
+ -LocalPort 22 -Profile Any | Out-Null\r
+ Write-Host " Added firewall rule $ruleName (TCP 22, all profiles)"\r
+ }\r
+ }\r
+} catch {\r
+ Write-Warning "OpenSSH Server setup failed: $($_.Exception.Message)"\r
+}\r
+\r
+# ---------------------------------------------------------------------------\r
+# rsync for Windows (github.com/nuket/rsync-windows)\r
+#\r
+# Windows' OpenSSH ships the transport only - no rsync - so pushing test data\r
+# from a Linux box needs an rsync.exe on the Windows side.\r
+#\r
+# The release is one zip per architecture - rsync-windows-x64.zip and\r
+# rsync-windows-x86.zip - each holding rsync.exe, the ssh.exe it runs, and the\r
+# licence texts under exactly those names. Both exes are installed, together:\r
+# rsync.exe prefers an ssh.exe in its own directory, and the release's build is\r
+# what makes a push FROM this box run at line rate. The ssh.exe Windows ships\r
+# reads its stdin 3KB at a time, which holds a send at ~17MB/s however fast the\r
+# link is. Nothing else about it differs - same ~/.ssh, same ssh-agent, same\r
+# known_hosts - and a bare `ssh` still resolves to the in-box client, which sits\r
+# ahead of C:\Tools\rsync on the machine PATH.\r
+#\r
+# That ssh.exe links against the libcrypto.dll the OpenSSH Client capability\r
+# above puts in System32: Windows' own LibreSSL, and the fast one, since it uses\r
+# AES-NI. No copy of it ships in the zip, so where the capability is missing we\r
+# unpack rsync alone rather than an ssh.exe that will not start.\r
+#\r
+# Installed to C:\Tools\rsync (NOT under "Program Files"): the remote end is\r
+# invoked as `rsync --server ...` through cmd.exe, and a path with spaces makes\r
+# the client-side --rsync-path escape hatch painful to quote. Added to the\r
+# MACHINE PATH so it resolves for every account, including the non-interactive\r
+# sshd session, which builds its environment from the machine + user registry\r
+# PATH rather than from a login shell.\r
+#\r
+# Non-fatal: a download failure only warns.\r
+# ---------------------------------------------------------------------------\r
+Write-Step 'rsync for Windows'\r
+$RsyncRepo = 'nuket/rsync-windows'\r
+# The release publishes exactly two assets - x64 and x86 - and no ARM64 one, so\r
+# on ARM64 the x64 build is the right pick: it runs under Prism, and an emulated\r
+# x64 rsync still moves data far faster than the ~17MB/s stdin cap that the whole\r
+# reason for using this build is to avoid. (The transfer is I/O-bound on the\r
+# socket, not on emulated CPU.) Selected off $HostArch rather than\r
+# Is64BitOperatingSystem, which answers "true" on ARM64 and so cannot tell the\r
+# two 64-bit cases apart.\r
+$RsyncAsset = switch ($HostArch) {\r
+ 'X64' { 'rsync-windows-x64.zip' }\r
+ 'Arm64' { 'rsync-windows-x64.zip' }\r
+ default { 'rsync-windows-x86.zip' }\r
+}\r
+if ($IsArm64) {\r
+ Write-Host ' ARM64: no native asset is published, using the x64 build under emulation.' -ForegroundColor Yellow\r
+}\r
+# The /releases/latest/download/ redirect rather than the API: unauthenticated\r
+# API calls are rate-limited to 60/hour per IP, which a provisioning run behind a\r
+# shared NAT can genuinely exhaust, and the redirect costs none of that budget.\r
+# To hold a box on a known build, pin the tag instead:\r
+# .../releases/download/v3.5.0-gABCDEF0/$RsyncAsset\r
+$RsyncUrl = "https://github.com/$RsyncRepo/releases/latest/download/$RsyncAsset"\r
+$RsyncDir = 'C:\Tools\rsync'\r
+try {\r
+ New-Item -ItemType Directory -Force -Path $RsyncDir | Out-Null\r
+ $RsyncExe = Join-Path $RsyncDir 'rsync.exe'\r
+\r
+ # Does the release's ssh.exe have the libcrypto it needs? Decided before the\r
+ # download so the answer can also gate what comes out of the zip. This is a\r
+ # cheap pre-filter only - the authoritative check is running the thing, which\r
+ # happens after the unpack below.\r
+ $SysCrypto = Join-Path $env:WINDIR 'System32\libcrypto.dll'\r
+ $WantSsh = Test-Path $SysCrypto\r
+ if (-not $WantSsh) {\r
+ Write-Warning "$SysCrypto is missing - the OpenSSH Client capability is not installed - and the release's ssh.exe needs it. Installing rsync.exe only; rsync will use the ssh on the PATH."\r
+ } else {\r
+ $v = (Get-Item $SysCrypto).VersionInfo.FileVersion\r
+ if ($v -and ([version]($v -replace '[^0-9.]', '')) -lt [version]'3.8.2') {\r
+ Write-Warning "$SysCrypto is LibreSSL $v; the release's ssh.exe is built against 3.8.2 (Windows OpenSSH Client 9.5). Update Windows, or expect ssh.exe not to start."\r
+ }\r
+ if ($IsArm64) {\r
+ # On ARM64 the presence of libcrypto.dll proves less than it does on\r
+ # x64: System32 holds the ARM64 build of it, and the ssh.exe in the\r
+ # zip is x64. Whether an emulated x64 process can load that DLL comes\r
+ # down to whether it is a plain ARM64 binary or an ARM64X one - not\r
+ # something worth deciding by parsing the PE header, when running the\r
+ # binary answers it outright. Unpack it, then run it (below).\r
+ Write-Host ' ARM64: the x64 ssh.exe will be verified by running it, not by assuming.' -ForegroundColor Yellow\r
+ }\r
+ }\r
+\r
+ # Download and unpack beside the targets, not over them, so an interrupted\r
+ # transfer can't leave a truncated rsync.exe sitting on the PATH. The scratch\r
+ # name still has to END in .zip: Windows PowerShell 5.1's Expand-Archive\r
+ # refuses any other extension outright ("*.download is not a supported\r
+ # archive file format"), where PowerShell 7 just reads the file.\r
+ [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12\r
+ $tmpZip = Join-Path $RsyncDir "download-$RsyncAsset"\r
+ Invoke-WebRequest -Uri $RsyncUrl -OutFile $tmpZip -UseBasicParsing\r
+ Write-Host " Downloaded $RsyncAsset ($([math]::Round((Get-Item $tmpZip).Length / 1MB, 2)) MB)"\r
+\r
+ # Verify against the .sha256 published beside it. Same origin, so this is an\r
+ # integrity check on the transfer rather than a defence against a hostile\r
+ # release - but a truncated or proxy-mangled download is the failure that\r
+ # actually happens, and it fails here instead of mid-transfer later.\r
+ #\r
+ # -OutFile, not .Content: GitHub serves the .sha256 as\r
+ # application/octet-stream, and Invoke-WebRequest hands back a byte[] rather\r
+ # than a string for any non-text content type, so .Content would compare the\r
+ # first BYTE against the hash and fail on every correct download.\r
+ $tmpSha = "$tmpZip.sha256"\r
+ Invoke-WebRequest -Uri "$RsyncUrl.sha256" -OutFile $tmpSha -UseBasicParsing\r
+ $want = (((Get-Content $tmpSha -Raw) -split '\s+')[0]).Trim().ToLower()\r
+ Remove-Item $tmpSha -Force -ErrorAction SilentlyContinue\r
+ $got = (Get-FileHash $tmpZip -Algorithm SHA256).Hash.ToLower()\r
+ if ($want -and $want -ne $got) {\r
+ Remove-Item $tmpZip -Force\r
+ throw "SHA-256 mismatch for ${RsyncAsset}: expected $want, got $got"\r
+ }\r
+ Write-Host " SHA-256 verified: $got"\r
+\r
+ # Unpack to a scratch directory and move out the files we asked for, rather\r
+ # than expanding straight over the install directory: the zip is the unit\r
+ # that was checksummed, and this way a future release adding something to it\r
+ # cannot quietly drop that something onto the machine PATH.\r
+ $unpack = Join-Path $RsyncDir '.unpack'\r
+ if (Test-Path $unpack) { Remove-Item -Recurse -Force $unpack }\r
+ Expand-Archive -Path $tmpZip -DestinationPath $unpack -Force\r
+ Remove-Item $tmpZip -Force\r
+ foreach ($f in 'rsync.exe', 'ssh.exe', 'COPYING.txt', 'NOTICE-ssh.txt') {\r
+ $src = Join-Path $unpack $f\r
+ if (-not (Test-Path $src)) { continue }\r
+ if ($f -eq 'ssh.exe' -and -not $WantSsh) { continue }\r
+ Move-Item -Path $src -Destination (Join-Path $RsyncDir $f) -Force\r
+ }\r
+ Remove-Item -Recurse -Force $unpack\r
+\r
+ # Prove the unpacked ssh.exe actually starts, and DELETE it if it does not.\r
+ #\r
+ # This matters more than it looks. rsync.exe prefers an ssh.exe sitting in its\r
+ # own directory, so a present-but-unstartable one does not degrade to the\r
+ # in-box client - it breaks rsync outright, and the error you get is a remote\r
+ # shell that died rather than anything naming ssh.exe. The two ways to land\r
+ # there are a missing/old System32 libcrypto.dll (x64 boxes) and an ARM64 box\r
+ # whose ARM64 libcrypto cannot be loaded by this x64 binary. Removing it is\r
+ # the repair in both cases: rsync then falls back to the ssh on the PATH,\r
+ # which on ARM64 is the native in-box client.\r
+ #\r
+ # EAP back to Continue for the call: ssh -V writes its version to STDERR, and\r
+ # under $ErrorActionPreference = 'Stop' a native command's stderr becomes a\r
+ # terminating error, so a WORKING client would look like a broken one.\r
+ # $global:LASTEXITCODE is cleared first because an exe that cannot start at\r
+ # all throws without setting one, and the stale 0 from the previous native\r
+ # command would otherwise read as success.\r
+ $SshExe = Join-Path $RsyncDir 'ssh.exe'\r
+ if ($WantSsh -and (Test-Path $SshExe)) {\r
+ $prevEap = $ErrorActionPreference\r
+ $ErrorActionPreference = 'Continue'\r
+ $global:LASTEXITCODE = $null\r
+ $sshVer = $null\r
+ try { $sshVer = (& $SshExe -V 2>&1 | Select-Object -First 1) } catch { }\r
+ finally { $ErrorActionPreference = $prevEap }\r
+ if ($LASTEXITCODE -eq 0) {\r
+ Write-Host " ssh.exe runs: $sshVer"\r
+ } else {\r
+ $why = if ($null -eq $LASTEXITCODE) { 'it would not start' } else { "exit $LASTEXITCODE" }\r
+ Write-Warning "The release's ssh.exe does not run here ($why)$(if ($sshVer) { ": $sshVer" }). Removing it so rsync.exe falls back to the ssh on the PATH instead of failing on it."\r
+ Remove-Item $SshExe -Force -ErrorAction SilentlyContinue\r
+ $WantSsh = $false\r
+ }\r
+ }\r
+ Write-Host " Installed $RsyncExe$(if ($WantSsh) { ' and the ssh.exe it runs' })"\r
+\r
+ # Machine PATH (HKLM environment). Idempotent: only appends if absent.\r
+ $m = [Environment]::GetEnvironmentVariable('Path', 'Machine')\r
+ if (-not $m) { $m = '' }\r
+ if (($m -split ';') -notcontains $RsyncDir) {\r
+ $new = if ($m.Trim()) { $m.TrimEnd(';') + ';' + $RsyncDir } else { $RsyncDir }\r
+ [Environment]::SetEnvironmentVariable('Path', $new, 'Machine')\r
+ Write-Host " Added $RsyncDir to the machine PATH (restart shells / sshd to pick it up)."\r
+ # sshd caches the environment it was started with, so an already-running\r
+ # service would not see the new PATH until restarted.\r
+ if ((Get-Service sshd -ErrorAction SilentlyContinue).Status -eq 'Running') {\r
+ Restart-Service sshd\r
+ Write-Host ' Restarted sshd so it inherits the updated machine PATH.'\r
+ }\r
+ } else {\r
+ Write-Host " OK: $RsyncDir already in the machine PATH"\r
+ }\r
+\r
+ & $RsyncExe --version | Select-Object -First 1\r
+} catch {\r
+ Write-Warning "rsync install failed: $($_.Exception.Message)"\r
+ Write-Warning "Download $RsyncAsset from https://github.com/$RsyncRepo/releases manually"\r
+ Write-Warning "and unpack it into $RsyncDir, keeping rsync.exe and ssh.exe together."\r
+}\r
+\r
vilimpoc.org / repos / dotfiles / blobdiff