I’m as confused as you, but it’s documented black on white (or white on black in dark mode) to be a built-in optional feature from Windows 10 onwards, as well as some Windows Server versions. It doesn’t seem like another attempt at Microslop’s [evaluate-embrace-extinguish strategy](TODO link wikipedia), so maybe it’s a concession that remote desktop isn’t great for automating remote access.
You just need to check a box in the advanced OS features menu, restart, and start the background service (optionally enable start on boot). Installing an ssh client is possible to.
It seems to be the OpenSSH implementation based on the labeling. Considering [Microsoft’s questionable track record at respecting licenses](Windows Download Tool), I want to check if they follow the rules this time:
mrc in ~ λ ssh mrc@win10.internal 'type C:\WINDOWS\System32\OpenSSH\LICENSE.txt' | head
** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded. See https://openssh.com/pq.html
This file is part of the OpenSSH software.
The licences which components of this software fall under are as
follows. First, we will summarize and say that all components
are under a BSD licence, or a licence more free than that.
OpenSSH contains no GPL code.
1)
* Copyright (c) 1995 Tatu Ylonen <ylo@cs.hut.fi>, Espoo, Finland
...What a strange timeline in which Microsoft ships OpenSSH with its OS and even bothers to include licenses. If it was a somewhat recent version with quantum-resistant key exchange, it would even be ready for production.
Setup gotcha: authorized keys🔗
Like any good citizen, I prefer key-based SSH authentication. The logical place to put public keys authorized to connect would be .ssh\authorized_keys within the user’s home. That works for non-admin users.
Admin users, however, need to store their authorized keys in the central location of C:\ProgramData\ssh\authorized_keys.
What can you do with it?🔗
You get dropped into a cmd.exe shell if you do plain ssh user@host (or ssh workgroup\user@host if you’re into ActiveDirectory). I’m actually a little surprised that OpenSSH and cmd.exe play nice, because they come from such different worlds, but in the end, cmd.exe faces the world with an input stream and an output stream, like a typical Unix process, so as long as OpenSSH understands the Windows versions of stdin and stdout, it’s the same shape built differently.
On the other hand, it’s not surprising that control flow management like one is accustomed to from a Unix shell - such as Ctrl+D to send end-of-file (EOF) - don’t work with cmd.exe, because those are a shell feature.
If WSL is installed, you can run wsl to switch into a more useful environment.
Impersonation?🔗
Considering that all admin users’ keys are stored in a single file without pointing out which user a key is for, I wonder if the user name even matters, and/or if an admin can use their key to impersonate any other admin.
TODO: Try out if I can change users
Not that it matters much, considering that an admin can already do anything anyway, so their identity barely matters.
Real use cases🔗
For now, I only need it to put some files into place and manage processes for running things that were created on a separate machine and only need the beefy Windows machine for execution.
A specific use case is testing a mod I’m generating agentically to add mopeds to the game Sengoku Dynasty for getting around more quickly. Walking all over the map is so tedious, and hiring a proper game developer is outside my budget for leisure improvements, just like doing it myself would occupy precious gaming time. I’m aware that mopeds didn’t exist in feudal Japan yet, which makes the idea hilarious to me. Also, mopeds don’t require much animation to look believable, while something more period-appropriate like horses do.
Will I keep it running?🔗
Running an old version of OpenSSH is a security hazard, as the post-quantum login warning helpfully pointed out, but so is running Windows in any capacity. I don’t plan on exposing the port to the world, so I can live well with the small risk. If it outlives its usefulness, disabling the service only takes a few clicks in the Windows service management tool, and the disk space it occupies is laughable, so it doesn’t bother anyone.