Levitate · Ops · Rescue access

SSH into the old Dell, without Tailscale

DESKTOP-VF4217I · 192.168.0.163 · Windows · LAN only

State: synthesis — runbook, not yet run on the Dell

If Tailscale ever breaks, this is the way back in — over the local network only.

Run the setup once on the Dell, as Administrator. Then from this machine (mrneed) run ssh oldpc hostname. Two minutes, start to finish.

Read this first — LAN only, on purpose

This opens SSH on port 22 to the local network only (the Private profile, local subnet). It is never reachable from the internet and the port is never opened at the router. The firewall is not turned off — one narrow inbound rule is added. The key below is unique to this purpose and is useless if it ever leaks onto a public network.

ARun the script — the fast way

First, get the script onto the Dell — it lives on mrneed at C:\Users\King Wise\Documents\Levitate\tools\ssh-rescue\setup-ssh-rescue.ps1. Email it to yourself, put it on a USB stick, or copy it into a shared folder on the Dell.

On the Dell: right-click Start → Terminal (Admin) or Windows PowerShell (Admin), cd to the folder you saved it in, then run:

powershell -ExecutionPolicy Bypass -File .\setup-ssh-rescue.ps1

That is the whole job. It is safe to run twice. If the account you want to rescue on the Dell is not an administrator, add -UserName yourname.

A success line at the end tells you it worked:

SUCCESS: LAN-only SSH rescue access is configured.
  sshd service state : Running / startup Automatic

A2Fastest — paste ONE line, no file to move

The script lives on the other machine (mrneed), so if moving the file is awkward, run this instead. On the Dell: Start → type PowerShell → right-click → Run as administrator → paste this single line and press Enter.

$k='ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIC8DknOXRIYoPDGwrV4olGmUFOq1IsOqEDs7LRSo4nW9 mhofu-rescue@mrneed'; Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0 | Out-Null; Set-Service sshd -StartupType Automatic; Start-Service sshd; try { New-NetFirewallRule -Name sshd-rescue -DisplayName 'OpenSSH LAN rescue' -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22 -Profile Private -RemoteAddress LocalSubnet | Out-Null } catch {}; $f="$env:ProgramData\ssh\administrators_authorized_keys"; New-Item -ItemType Directory -Force -Path (Split-Path $f) | Out-Null; Add-Content -Path $f -Value $k -Encoding ascii; icacls $f /inheritance:r /grant 'Administrators:F' /grant 'SYSTEM:F' | Out-Null; Write-Host 'RESCUE READY' -ForegroundColor Green

See RESCUE READY in green? The Dell is done — tell Mhofu and the connection gets tested from the other side.

BOr do it by hand (GUI)

Same result, no script. Use this if you prefer to see each step.

  1. Install OpenSSH Server. Settings → Apps → Optional features → Add a feature → search OpenSSH Server → tick it → Install. Wait for it to finish.
  2. Start the service. Press Win+R, type services.msc, Enter. Find OpenSSH SSH Server (service name sshd), right-click → Start. Then double-click it, set Startup type to Automatic, click Apply/OK.
  3. Add the key. Open Notepad as Administrator. Paste the public key block from below. Save it as C:\ProgramData\ssh\administrators_authorized_keys (set "Save as type" to All files, no .txt on the end).
  4. Lock that file down — this is the step people miss, and without it key login silently fails. In an admin PowerShell paste the block in step C below.

The one gotcha worth naming

Windows sshd refuses administrators_authorized_keys unless only SYSTEM and Administrators can write to it. If extra users or "Everyone" have access, the key is ignored and the server just asks for a password with no error. The script fixes this; the block below fixes it if you are doing it by hand.

CThe public key + the permission fix

Copy this exact line into the file in step 3 above:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIC8DknOXRIYoPDGwrV4olGmUFOq1IsOqEDs7LRSo4nW9 mhofu-rescue@mrneed

Then, in an Administrator PowerShell, seal the file's permissions:

$f = "$env:ProgramData\ssh\administrators_authorized_keys"
$acl = Get-Acl $f
$acl.SetAccessRuleProtection($true, $false)
$acl.SetAccessRule((New-Object System.Security.AccessControl.FileSystemAccessRule("BUILTIN\Administrators","FullControl","Allow")))
$acl.SetAccessRule((New-Object System.Security.AccessControl.FileSystemAccessRule("SYSTEM","FullControl","Allow")))
$acl | Set-Acl

Not an administrator on the Dell?

Then the key goes elsewhere: save it to C:\Users\Agentic\.ssh\authorized_keys and restrict that file and its .ssh folder to your account plus SYSTEM. Use the script with -UserName Agentic and it does both automatically.

DConnect from this machine (mrneed)

The Dell's Windows username is Agentic. Add this stanza to C:\Users\King Wise\.ssh\config on this machine:

Host oldpc
    HostName 192.168.0.163
    User Agentic
    IdentityFile ~/.ssh/oldpc_ed25519
    IdentitiesOnly yes
    StrictHostKeyChecking accept-new

Then the test — one line, from this machine:

ssh oldpc hostname

What proves it worked

You get back the Dell's hostname and drop straight into a shell:

DESKTOP-VF4217I

That single line is the whole win — no Tailscale, just the LAN.

If it asks for a password instead

The key was rejected, which is almost always the administrators_authorized_keys permissions from step C. Re-run the script (it re-seals the ACL every time). If it times out entirely, check the Dell is switched on at 192.168.0.163 and that its network profile is set to Private — Settings → Network & internet → your connection → Network profile → Private. A Private-profile firewall rule will not apply on a Public network.

Summary — what is LAN-only and what is not

Artefacts: tools/ssh-rescue/setup-ssh-rescue.ps1 · wiki/ops/ssh-rescue-setup.html
Key mhofu-rescue@mrneed → private half at ~/.ssh/oldpc_ed25519 on mrneed.
Not yet run on the Dell. Only Mr Need can do that, at the Dell's keyboard.