{"id":6190,"date":"2026-09-05T21:42:16","date_gmt":"2026-09-05T12:42:16","guid":{"rendered":"https:\/\/eternalsphere.net\/echoes\/?p=6190"},"modified":"2026-09-12T17:17:56","modified_gmt":"2026-09-12T08:17:56","slug":"bb6teownzlphy4e","status":"publish","type":"post","link":"https:\/\/blog.eternalsphere.net\/index.php\/2026\/09\/05\/bb6teownzlphy4e\/","title":{"rendered":"Building a Secure Windows OpenSSH Endpoint Behind FRP: From Feature-on-Demand Failure to Hardened Remote Access"},"content":{"rendered":"\n

Deploying SSH on Windows is usually straightforward: enable the built-in OpenSSH Server capability, start sshd<\/code>, and configure authentication. In practice, Windows servicing failures, Feature-on-Demand dependencies, network restrictions, and remote-access constraints can turn the process into a much more involved systems-engineering exercise.<\/p>\n\n\n\n

This article describes a robust approach for deploying Microsoft OpenSSH on Windows when the built-in optional feature cannot be installed, then hardening it for public-key-only access and placing it behind an isolated FRP tunnel.<\/p>\n\n\n\n

All hostnames, usernames, domains, ports, paths, keys, and other environment-specific values below are anonymized.<\/p>\n\n\n\n

1. Intended Architecture<\/h2>\n\n\n\n

The final architecture is deliberately layered:<\/p>\n\n\n\n

<ADMIN_HOST>\n    |\n    | SSH public-key authentication\n    v\n<FRPS_PUBLIC_ENDPOINT>:<REMOTE_SSH_PORT>\n    |\n    v\n<FRPS_INSTANCE>\n    |\n    v\n<FRPC_INSTANCE>\n    |\n    v\n<WINDOWS_LOOPBACK>:<LOCAL_SSH_PORT>\n    |\n    v\nWindows OpenSSH Server\n<\/code><\/pre>\n\n\n\n
The important property is that the Windows SSH daemon is not directly exposed to the LAN or Internet.<\/p>\n\n\n\n
FRPC forwards traffic internally to:<\/p>\n\n\n\n
<WINDOWS_LOOPBACK>:<LOCAL_SSH_PORT>\n<\/code><\/pre>\n\n\n\n
while FRPS exposes a separate external port.<\/p>\n\n\n\n
This separates three concerns:<\/p>\n\n\n\n
    \n
  • Windows SSH authentication;<\/li>\n\n\n\n
  • FRP transport and remote publishing;<\/li>\n\n\n\n
  • Internet-facing exposure.<\/li>\n<\/ul>\n\n\n\n
    2. When the Built-In OpenSSH Capability Fails<\/h2>\n\n\n\n
    Windows normally provides OpenSSH Server as a Feature on Demand.<\/p>\n\n\n\n
    A typical installation attempt is:<\/p>\n\n\n\n
    Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0\n<\/code><\/pre>\n\n\n\n
    A servicing failure may return an error such as:<\/p>\n\n\n\n
    0x800f0950\n<\/code><\/pre>\n\n\n\n
    The important point is that this does not necessarily indicate a broken OpenSSH package. It usually means that Windows servicing could not obtain or install the requested capability.<\/p>\n\n\n\n
    Possible causes include:<\/p>\n\n\n\n
      \n
    • damaged component-store metadata;<\/li>\n\n\n\n
    • unavailable Feature-on-Demand source files;<\/li>\n\n\n\n
    • Windows Update source problems;<\/li>\n\n\n\n
    • servicing-stack inconsistencies;<\/li>\n\n\n\n
    • policy restrictions;<\/li>\n\n\n\n
    • mismatched optional-feature media.<\/li>\n<\/ul>\n\n\n\n
      3. Diagnosing the Windows Component Store<\/h2>\n\n\n\n
      The component store can be checked without modifying the system:<\/p>\n\n\n\n
      DISM \/Online \/Cleanup-Image \/ScanHealth\n<\/code><\/pre>\n\n\n\n
      If Windows reports that the component store is repairable, the next step is:<\/p>\n\n\n\n
      DISM \/Online \/Cleanup-Image \/RestoreHealth\n<\/code><\/pre>\n\n\n\n
      When unrestricted network access is available, DISM may retrieve missing repair material from Windows Update.<\/p>\n\n\n\n
      For systems on metered or constrained networks, a local-only repair can be tested first:<\/p>\n\n\n\n
      DISM \/Online \/Cleanup-Image \/RestoreHealth \/LimitAccess\n<\/code><\/pre>\n\n\n\n
      If this fails because no repair source exists locally, that result is still useful: it confirms that an external or offline repair source is required.<\/p>\n\n\n\n
      A successful component-store repair does not guarantee that every Feature-on-Demand package will subsequently install. If OpenSSH still returns the same servicing error after DISM succeeds, continuing to retry the same capability may provide little value.<\/p>\n\n\n\n
      4. Switching to Microsoft Win32-OpenSSH<\/h2>\n\n\n\n
      A practical alternative is Microsoft’s separately packaged Win32-OpenSSH distribution.<\/p>\n\n\n\n
      For an x86-64 system, the package can be obtained from the official Microsoft-maintained release repository and transferred to the target host.<\/p>\n\n\n\n
      A server-only MSI installation may use:<\/p>\n\n\n\n
      msiexec.exe \/i \"<OPENSSH_MSI_PATH>\" ADDLOCAL=Server\n<\/code><\/pre>\n\n\n\n
      After installation:<\/p>\n\n\n\n
      Get-Service sshd\n<\/code><\/pre>\n\n\n\n
      should show the service.<\/p>\n\n\n\n
      Set it to start automatically:<\/p>\n\n\n\n
      Set-Service sshd -StartupType Automatic\n<\/code><\/pre>\n\n\n\n
      The MSI deployment commonly places binaries under a path such as:<\/p>\n\n\n\n
      <OPENSSH_INSTALL_DIRECTORY>\n<\/code><\/pre>\n\n\n\n
      while server configuration remains under:<\/p>\n\n\n\n
      <PROGRAMDATA_SSH_DIRECTORY>\n<\/code><\/pre>\n\n\n\n
      5. Verifying the Listener<\/h2>\n\n\n\n
      The SSH service should initially be verified before any hardening changes:<\/p>\n\n\n\n
      Get-NetTCPConnection -State Listen -LocalPort <LOCAL_SSH_PORT>\n<\/code><\/pre>\n\n\n\n
      A fresh installation may listen on all interfaces:<\/p>\n\n\n\n
      <ALL_IPV4_INTERFACES>:<LOCAL_SSH_PORT>\n<ALL_IPV6_INTERFACES>:<LOCAL_SSH_PORT>\n<\/code><\/pre>\n\n\n\n
      This is functional, but it is broader exposure than necessary when FRPC only needs a loopback endpoint.<\/p>\n\n\n\n
      6. Administrator Public-Key Authentication on Windows<\/h2>\n\n\n\n
      Windows OpenSSH handles administrator accounts differently from ordinary users.<\/p>\n\n\n\n
      For a non-administrator account, the usual file is:<\/p>\n\n\n\n
      C:\\Users\\<WINDOWS_USER>\\.ssh\\authorized_keys\n<\/code><\/pre>\n\n\n\n
      For accounts in the local Administrators group, the default OpenSSH configuration commonly contains:<\/p>\n\n\n\n
      Match Group administrators\n    AuthorizedKeysFile <ADMINISTRATOR_AUTHORIZED_KEYS_PATH>\n<\/code><\/pre>\n\n\n\n
      Therefore the administrator public key belongs in:<\/p>\n\n\n\n
      <ADMINISTRATOR_AUTHORIZED_KEYS_PATH>\n<\/code><\/pre>\n\n\n\n
      A public key from the administrative source host may look conceptually like:<\/p>\n\n\n\n
      ssh-ed25519 <PUBLIC_KEY_DATA> <KEY_COMMENT>\n<\/code><\/pre>\n\n\n\n
      or:<\/p>\n\n\n\n
      ssh-rsa <PUBLIC_KEY_DATA> <KEY_COMMENT>\n<\/code><\/pre>\n\n\n\n
      Only the public key is copied.<\/p>\n\n\n\n
      The private key must remain on the administrative host.<\/p>\n\n\n\n
      7. Correct ACLs Matter<\/h2>\n\n\n\n
      Windows OpenSSH is strict about permissions on administrator key files.<\/p>\n\n\n\n
      A safe pattern is to remove inherited ACLs and grant access only to the system and local administrators.<\/p>\n\n\n\n
      For example:<\/p>\n\n\n\n
      icacls \"<ADMINISTRATOR_AUTHORIZED_KEYS_PATH>\" \/inheritance:r\n<\/code><\/pre>\n\n\n\n
      Then grant access to the relevant well-known security principals.<\/p>\n\n\n\n
      Using SIDs instead of localized group names is useful because the same command works across different Windows display languages.<\/p>\n\n\n\n
      The final ACL should effectively be limited to:<\/p>\n\n\n\n
      SYSTEM\nAdministrators\n<\/code><\/pre>\n\n\n\n
      8. Test the Key Before Disabling Passwords<\/h2>\n\n\n\n
      The first remote test should explicitly require public-key authentication.<\/p>\n\n\n\n
      From the administrative host:<\/p>\n\n\n\n
      ssh \\\n  -o PreferredAuthentications=publickey \\\n  -o PasswordAuthentication=no \\\n  -p <REMOTE_SSH_PORT> \\\n  <WINDOWS_USER>@<FRPS_PUBLIC_ENDPOINT>\n<\/code><\/pre>\n\n\n\n
      If this succeeds, it proves that:<\/p>\n\n\n\n
        \n
      • FRPS is reachable;<\/li>\n\n\n\n
      • FRPC is connected;<\/li>\n\n\n\n
      • FRPC reaches the local Windows SSH port;<\/li>\n\n\n\n
      • sshd<\/code> is running;<\/li>\n\n\n\n
      • the public key is accepted;<\/li>\n\n\n\n
      • the administrator key file and ACLs are correct.<\/li>\n<\/ul>\n\n\n\n
        Only after this test should password authentication be disabled.<\/p>\n\n\n\n
        9. Harden sshd_config<\/code><\/h2>\n\n\n\n
        A hardened SSH configuration can contain:<\/p>\n\n\n\n
        PubkeyAuthentication yes\nPasswordAuthentication no\nKbdInteractiveAuthentication no\nPermitEmptyPasswords no\n<\/code><\/pre>\n\n\n\n
        For an FRPC-only design, the SSH listener can also be restricted:<\/p>\n\n\n\n
        ListenAddress <WINDOWS_LOOPBACK>\n<\/code><\/pre>\n\n\n\n
        Before restarting the service:<\/p>\n\n\n\n
        & \"<OPENSSH_INSTALL_DIRECTORY>\\sshd.exe\" -t\n<\/code><\/pre>\n\n\n\n
        No output normally indicates valid syntax.<\/p>\n\n\n\n
        Then:<\/p>\n\n\n\n
        Restart-Service sshd\n<\/code><\/pre>\n\n\n\n
        10. Prove Password Authentication Is Actually Disabled<\/h2>\n\n\n\n
        Do not rely only on configuration-file inspection.<\/p>\n\n\n\n
        Perform a negative test:<\/p>\n\n\n\n
        ssh \\\n  -o PubkeyAuthentication=no \\\n  -o PreferredAuthentications=password,keyboard-interactive \\\n  -p <REMOTE_SSH_PORT> \\\n  <WINDOWS_USER>@<FRPS_PUBLIC_ENDPOINT>\n<\/code><\/pre>\n\n\n\n
        A hardened server should reject the request without offering a password prompt.<\/p>\n\n\n\n
        This proves that public-key-only authentication is effective in practice.<\/p>\n\n\n\n
        11. Restrict SSH to Loopback<\/h2>\n\n\n\n
        If FRPC connects to:<\/p>\n\n\n\n
        <WINDOWS_LOOPBACK>:<LOCAL_SSH_PORT>\n<\/code><\/pre>\n\n\n\n
        there is usually no need for Windows SSH to listen on every physical interface.<\/p>\n\n\n\n
        After setting:<\/p>\n\n\n\n
        ListenAddress <WINDOWS_LOOPBACK>\n<\/code><\/pre>\n\n\n\n
        verify:<\/p>\n\n\n\n
        Get-NetTCPConnection -State Listen -LocalPort <LOCAL_SSH_PORT>\n<\/code><\/pre>\n\n\n\n
        The result should show only the loopback listener.<\/p>\n\n\n\n
        The security effect is:<\/p>\n\n\n\n
        LAN -> Windows SSH                blocked\nDirect Internet -> Windows SSH    blocked\nFRPC -> Windows loopback SSH      allowed\n<\/code><\/pre>\n\n\n\n
        This significantly narrows the attack surface.<\/p>\n\n\n\n
        12. Making PowerShell the Default SSH Shell<\/h2>\n\n\n\n
        Windows OpenSSH can be configured to launch PowerShell instead of cmd.exe<\/code>.<\/p>\n\n\n\n
        A registry value under the OpenSSH configuration key can set:<\/p>\n\n\n\n
        DefaultShell = <POWERSHELL_EXECUTABLE>\n<\/code><\/pre>\n\n\n\n
        After restarting sshd<\/code>, new SSH sessions can land directly at:<\/p>\n\n\n\n
        PS C:\\Users\\<WINDOWS_USER>>\n<\/code><\/pre>\n\n\n\n
        This is much more convenient for remote Windows administration.<\/p>\n\n\n\n
        13. Fixing SFTP with an MSI OpenSSH Installation<\/h2>\n\n\n\n
        An interesting failure mode is:<\/p>\n\n\n\n
        SSH shell works\nSFTP immediately closes\n<\/code><\/pre>\n\n\n\n
        If:<\/p>\n\n\n\n
        Subsystem sftp sftp-server.exe\n<\/code><\/pre>\n\n\n\n
        is configured but the MSI installation places sftp-server.exe<\/code> outside the directory expected by sshd<\/code>, SFTP may fail even though normal SSH works.<\/p>\n\n\n\n
        The subsystem can be made explicit:<\/p>\n\n\n\n
        Subsystem sftp \"<OPENSSH_SFTP_SERVER_FULL_PATH>\"\n<\/code><\/pre>\n\n\n\n
        After validating the configuration and restarting sshd<\/code>, SFTP can be tested again:<\/p>\n\n\n\n
        sftp -P <REMOTE_SSH_PORT> <WINDOWS_USER>@<FRPS_PUBLIC_ENDPOINT>\n<\/code><\/pre>\n\n\n\n
        This distinction is useful because successful SSH authentication does not automatically prove that every SSH subsystem is functional.<\/p>\n\n\n\n
        14. Temporary FRPC Autostart for Maintenance Reboots<\/h2>\n\n\n\n
        During maintenance, a remote reboot may be necessary before the normal FRPC operator is available.<\/p>\n\n\n\n
        A temporary Scheduled Task can start FRPC at Windows boot:<\/p>\n\n\n\n
        Trigger: At startup\nRun as: SYSTEM\nRun level: Highest\nExecutable: <FRPC_EXECUTABLE>\nArguments: -c \"<FRPC_CONFIG>\"\n<\/code><\/pre>\n\n\n\n
        This provides a one-time recovery path after reboot.<\/p>\n\n\n\n
        Once remote access is confirmed again, the task can be removed.<\/p>\n\n\n\n
        This is preferable to permanently changing the client’s operational model merely to survive one maintenance reboot.<\/p>\n\n\n\n
        15. Final Security Model<\/h2>\n\n\n\n
        The completed design is:<\/p>\n\n\n\n
        Public Internet\n     |\n     v\n<FRPS_PUBLIC_ENDPOINT>:<REMOTE_SSH_PORT>\n     |\n     v\nDedicated FRPS instance\n     |\n     v\nFRPC\n     |\n     v\n<WINDOWS_LOOPBACK>:<LOCAL_SSH_PORT>\n     |\n     v\nWindows OpenSSH\n     |\n     +-- Public key only\n     +-- Password disabled\n     +-- Keyboard-interactive disabled\n     +-- Administrator key ACL restricted\n     +-- Loopback listener only\n<\/code><\/pre>\n\n\n\n
        The most important lesson is that a failed Windows Feature-on-Demand installation does not have to block the deployment.<\/p>\n\n\n\n
        A controlled fallback to Microsoft’s standalone Win32-OpenSSH package, combined with strict authentication, loopback-only listening, precise key permissions, and an isolated FRP tunnel, can produce a clean and defensible remote-management architecture.<\/p>\n","protected":false},"excerpt":{"rendered":"
        Deploying SSH on Windows is usually straightforward: enable the built-in OpenSSH Server capability, start sshd, and configure authentication. In practice, Windows servicing failures, Feature-on-Demand dependencies, network restrictions, and remote-access constraints can turn the process into a much more involved systems-engineering exercise. This article describes a robust approach for deploying Microsoft …<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[218],"tags":[265,242,335],"class_list":["post-6190","post","type-post","status-publish","format-standard","hentry","category-windows","tag-security","tag-ssh","tag-tunneling"],"_links":{"self":[{"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/posts\/6190","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/comments?post=6190"}],"version-history":[{"count":1,"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/posts\/6190\/revisions"}],"predecessor-version":[{"id":6191,"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/posts\/6190\/revisions\/6191"}],"wp:attachment":[{"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/media?parent=6190"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/categories?post=6190"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/tags?post=6190"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}