Last year I published an interesting finding about SSH remoting in Windows Server which, while not being sensational, did stir up several quite productive discussions. Back then, Server 2025 and its one-click activation of the SSH daemon was still in Insider preview, and apparently Microsoft gave it some urgently needed love before release. Not all is rainbows and unicorns though.

One-Click becomes Two-Click

Or, rather, a click and an [ENTER]. The PowerShell script that is triggered by the „Enable OpenSSH remoting“ hyperlink in Server Manager now includes a confirmation, making a completely accidental activation of the OpenSSH remoting slightly less likely. This mimicks the flow of WinRM and RDP activation where a confirmation has always been required. Now we have an accidental activation protection for SSH, too, which is definitely a good thing.

The SSH activation script, by the way, is not stored as a .ps1 file but passed to powershell.exe as -Command by Server Manager when you click on the link.

„Anyone with a user account“ becomes „OpenSSH Users“

An even more valuable addition to the state of affairs created by last year’s Insider builds is the new default configuration in sshd_config that restricts SSH access to certain groups: Administrators and a new group called OpenSSH Users, continuing the naming convention of „Remote Desktop Users“ and „Remote Management Users“. This group is even a „well-known“ one, having a SID of S-1-5-32-585.

This group also gets created in an Active Directory domain once you promote your first Server 2025 DC in that domain. Despite granting SSH access to domain controllers, this group is not considered privileged enough to receive SDPROP treatment. Nor, as we will see later, does its well-known SID play a role in granting said access – only the sAMAccountName of the group matters because the SSH daemon only checks the names of the groups, not their SIDs, against the configuration file.

Yes, but…

While the default SSH setup did get better, it’s still far from ideal. Let’s take a closer look.

Downlevel OS versions

The One-Click activation for SSH remoting has not been backported to any previous Windows Server version, not even as recent as 2022. For 2019 and 2022, OpenSSH server can be added as a Windows capability:

For Server 2016, you’re out of luck. You might be able to find an early build of installable „OpenSSH for Windows“ but no one will support you if you decide to use it in production.

Needless to say, adding the OpenSSH.Server capability does not create the OpenSSH Users group or add it to the sshd configuration. On downlevel OSes, any user will be able to connect to an SSH-enabled server using their name and password, even if the local security policy explicitly denies local, remote-interactive, service and batch logon for that user. The added capability does, however, create the firewall rule allowing Port 22/tcp on all Firewall profiles. Remember Abel Wang? „Don’t accept the defaults!“

Firewall profiles and One-Click activation

The new One-Click activation  in Server 2025 also creates an inbound firewall rule. Look at the screenshot above though: it says

By default, SSH access is only available on a private network.

And, true to the word, the rule, albeit targeting the sshd executable rather than just opening port 22, is only created in the Private profile. If the server in question is a domain member (or even a domain controller) SSH will not be available after activation. Although, of course, NLASvc is a bitch, and your domain members or even DCs may fall into the Private profile and accidentally grant SSH access, even you haven’t intended them to…

---

But wait, it gets better when you leave the realm of the English language 🙂

Ja, aber…

Now, being German and having worked in the public sector and in finance in this country, I know from experience that there are organisations out there still installing and running their server systems in German. It’s probably the same for other non-English-speaking countries. Let’s take a quick look at what happens with SSH activation on a de-DE Server 2025.

Anyone who ever worked with localized Microsoft technology has probably already guessed where this is going. The group names in the activation message are German, or at least the second one is. And indeed, the group by that name has been created as a part of the Windows installation:
However, if we look at the automatically created sshd_config file on a German server, we will see that it is identical to the English version:

Obviously, neither of the default AllowGroups exists on a German installation. Administrators do have some built-in magic to them so that an account that is a local admin will be able to connect, firewall permitting. Membership  in OpenSSH-Benutzer, on the other hand, does not grant SSH access, but a custom group OpenSSH Users, despite not having a well-known SID, does!

Shit happens, even if you’re German!

Things will get even messier should you make a mistake of promoting your first Server 2025 DC from an OS installed in a different language:
Since this is a well-known system-generated object, you cannot rename the object itself. However, you can change the group’s sAMAccountName to OpenSSH Users, and, unsurprisingly, NOW this group does grant SSH access to domain controllers!

Even automated translation would not do that

If you are a German speaker or at least reader, this is for you:

Truly, you cannot make this shit up.

Conclusion

If you want to take advantage of SSH in your AD-based Windows network and avoid pitfalls at the same time, create a group policy that

• Activates or deactivates the SSH daemon
• Creates a firewall rule for Domain and Private profile
• Deploys an sshd_config file to %ProgramData%\ssh that contains your environment-specific configuration for SSH, including groups you have created for the purpose.

But whatever you do, treat the OpenSSH Users group as Tier 0 and secure its memberships accordingly!

Image by Gerd Altmann from Pixabay