{"id":6083,"date":"2026-08-23T20:45:29","date_gmt":"2026-08-23T11:45:29","guid":{"rendered":"https:\/\/eternalsphere.net\/echoes\/?p=6083"},"modified":"2026-09-12T14:54:09","modified_gmt":"2026-09-12T05:54:09","slug":"vrp00p30qy096x9","status":"publish","type":"post","link":"https:\/\/blog.eternalsphere.net\/index.php\/2026\/08\/23\/vrp00p30qy096x9\/","title":{"rendered":"Windows 11 and SSH: Understanding Remote Connections, Keys, and Authentication"},"content":{"rendered":"\n

Windows 11 includes native support for OpenSSH<\/strong>, which means it can work both as an SSH client<\/strong> and as an SSH server<\/strong>. This makes it possible to manage Linux servers directly from Windows, connect remotely to Windows from Linux, transfer files with SCP\/SFTP, and use public-key authentication without installing third-party SSH software.<\/p>\n\n\n\n

The most important concept is that SSH uses different keys for different purposes<\/strong>. The keys used when Windows acts as a server are not the same as the keys used when Windows acts as a client.<\/p>\n\n\n\n

1. Windows 11 as an SSH Client<\/h2>\n\n\n\n

When Windows connects to another machine, it acts as the SSH client.<\/p>\n\n\n\n

For example:<\/p>\n\n\n\n

ssh user@192.168.1.100\n<\/code><\/pre>\n\n\n\n
The SSH client is normally included with Windows 11 and can be checked with:<\/p>\n\n\n\n
ssh -V\n<\/code><\/pre>\n\n\n\n
A typical installation reports something similar to:<\/p>\n\n\n\n
OpenSSH_for_Windows_...\n<\/code><\/pre>\n\n\n\n
Client-side user keys<\/h3>\n\n\n\n
Public-key authentication normally uses a key pair stored under the current Windows user’s profile:<\/p>\n\n\n\n
C:\\Users\\<username>\\.ssh\\\n<\/code><\/pre>\n\n\n\n
For an ED25519 key pair:<\/p>\n\n\n\n
id_ed25519\nid_ed25519.pub\n<\/code><\/pre>\n\n\n\n
Their roles are:<\/p>\n\n\n\n
id_ed25519       Private key\nid_ed25519.pub   Public key\n<\/code><\/pre>\n\n\n\n
The private key must remain on the Windows computer.<\/p>\n\n\n\n
The public key is copied to machines that Windows needs to access.<\/p>\n\n\n\n
For example, when connecting to a Linux account, the contents of:<\/p>\n\n\n\n
C:\\Users\\<username>\\.ssh\\id_ed25519.pub\n<\/code><\/pre>\n\n\n\n
are added to:<\/p>\n\n\n\n
~\/.ssh\/authorized_keys\n<\/code><\/pre>\n\n\n\n
on the Linux server.<\/p>\n\n\n\n
If no key pair exists, one can be generated with:<\/p>\n\n\n\n
ssh-keygen -t ed25519\n<\/code><\/pre>\n\n\n\n
In simple terms:<\/p>\n\n\n\n
Windows client\n    |\n    | owns private key\n    |\n    +-- id_ed25519\n\nPublic key\n    |\n    +---------> remote server\n                 ~\/.ssh\/authorized_keys\n<\/code><\/pre>\n\n\n\n
The private key proves the identity of the user connecting to the server.<\/p>\n\n\n\n
\n\n\n\n
2. Windows 11 as an SSH Server<\/h2>\n\n\n\n
Windows 11 can also run OpenSSH Server<\/strong>, allowing another computer to connect to Windows using SSH.<\/p>\n\n\n\n
The server-side files are mainly stored in:<\/p>\n\n\n\n
C:\\ProgramData\\ssh\\\n<\/code><\/pre>\n\n\n\n
A typical directory may contain:<\/p>\n\n\n\n
administrators_authorized_keys\n\nssh_host_ecdsa_key\nssh_host_ecdsa_key.pub\n\nssh_host_ed25519_key\nssh_host_ed25519_key.pub\n\nssh_host_rsa_key\nssh_host_rsa_key.pub\n\nsshd_config\nsshd.pid\nlogs\\\n<\/code><\/pre>\n\n\n\n
At first glance, the number of key files may seem excessive. In reality, they fall into a few clearly defined categories.<\/p>\n\n\n\n
\n\n\n\n
3. Host Keys: The Identity of the Windows SSH Server<\/h2>\n\n\n\n
Files beginning with:<\/p>\n\n\n\n
ssh_host_\n<\/code><\/pre>\n\n\n\n
are server host keys<\/strong>.<\/p>\n\n\n\n
Examples include:<\/p>\n\n\n\n
ssh_host_ed25519_key\nssh_host_ed25519_key.pub\n<\/code><\/pre>\n\n\n\n
and:<\/p>\n\n\n\n
ssh_host_rsa_key\nssh_host_rsa_key.pub\n<\/code><\/pre>\n\n\n\n
There are usually several sets because OpenSSH supports multiple cryptographic algorithms:<\/p>\n\n\n\n
    \n
  • ED25519<\/li>\n\n\n\n
  • ECDSA<\/li>\n\n\n\n
  • RSA<\/li>\n<\/ul>\n\n\n\n
    Each algorithm has a private key and a public key.<\/p>\n\n\n\n
    For example:<\/p>\n\n\n\n
    ssh_host_ed25519_key       Private host key\nssh_host_ed25519_key.pub   Public host key\n<\/code><\/pre>\n\n\n\n
    These keys answer a specific question:<\/p>\n\n\n\n
    \n
    Which SSH server is the client connecting to?<\/p>\n<\/blockquote>\n\n\n\n
    They identify the Windows machine itself as an SSH server<\/strong>.<\/p>\n\n\n\n
    They do not identify the Windows user who is connecting to another server.<\/p>\n\n\n\n
    This distinction is important.<\/p>\n\n\n\n
    When an SSH client connects to a server for the first time, a message may appear similar to:<\/p>\n\n\n\n
    The authenticity of host ... can't be established.\nED25519 key fingerprint is SHA256:...\n<\/code><\/pre>\n\n\n\n
    That fingerprint is derived from the SSH server’s host key.<\/p>\n\n\n\n
    After accepting it, the client normally records the server identity in:<\/p>\n\n\n\n
    known_hosts\n<\/code><\/pre>\n\n\n\n
    This helps detect unexpected changes to the server’s SSH identity during later connections.<\/p>\n\n\n\n
    \n\n\n\n
    4. User Keys and Host Keys Are Different<\/h2>\n\n\n\n
    The easiest way to understand SSH keys is to separate two identities.<\/p>\n\n\n\n
    Server identity<\/h3>\n\n\n\n
    The server proves:<\/p>\n\n\n\n
    \n
    This is the same server that was connected to previously.<\/p>\n<\/blockquote>\n\n\n\n
    Windows stores its server host keys under:<\/p>\n\n\n\n
    C:\\ProgramData\\ssh\\ssh_host_*\n<\/code><\/pre>\n\n\n\n
    Linux normally stores equivalent keys under:<\/p>\n\n\n\n
    \/etc\/ssh\/ssh_host_*\n<\/code><\/pre>\n\n\n\n
    Client user identity<\/h3>\n\n\n\n
    The client proves:<\/p>\n\n\n\n
    \n
    This user possesses the private key corresponding to an authorized public key.<\/p>\n<\/blockquote>\n\n\n\n
    Windows normally stores user keys under:<\/p>\n\n\n\n
    C:\\Users\\<username>\\.ssh\\\n<\/code><\/pre>\n\n\n\n
    Linux normally stores them under:<\/p>\n\n\n\n
    ~\/.ssh\/\n<\/code><\/pre>\n\n\n\n
    Therefore:<\/p>\n\n\n\n
    Host key = identity of the SSH server\n\nUser key = identity of the user connecting to the SSH server\n<\/code><\/pre>\n\n\n\n
    These are two separate key systems even though both use SSH cryptography.<\/p>\n\n\n\n
    \n\n\n\n
    5. What authorized_keys<\/code> Does<\/h2>\n\n\n\n
    Another important file is:<\/p>\n\n\n\n
    authorized_keys\n<\/code><\/pre>\n\n\n\n
    This file does not contain the server’s own identity.<\/p>\n\n\n\n
    Instead, it contains the public keys of users or devices that are allowed to log in.<\/p>\n\n\n\n
    For example:<\/p>\n\n\n\n
    Client machine\nC:\\Users\\<username>\\.ssh\\id_ed25519.pub\n                     |\n                     |\n                     v\nLinux server\n\/home\/user\/.ssh\/authorized_keys\n<\/code><\/pre>\n\n\n\n
    If the corresponding private key remains on the Windows client, the Windows user can authenticate to that Linux account without sending the private key across the network.<\/p>\n\n\n\n
    Linux usually keeps an authorized_keys<\/code> file for each account:<\/p>\n\n\n\n
    \/home\/alice\/.ssh\/authorized_keys\n\/home\/bob\/.ssh\/authorized_keys\n\/root\/.ssh\/authorized_keys\n<\/code><\/pre>\n\n\n\n
    Windows OpenSSH follows essentially the same design for ordinary users:<\/p>\n\n\n\n
    C:\\Users\\<username>\\.ssh\\authorized_keys\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    6. The Windows Administrator Exception<\/h2>\n\n\n\n
    Windows OpenSSH has an important default behavior for accounts belonging to the Administrators<\/strong> group.<\/p>\n\n\n\n
    Instead of using:<\/p>\n\n\n\n
    C:\\Users\\<administrator>\\.ssh\\authorized_keys\n<\/code><\/pre>\n\n\n\n
    the default configuration commonly uses:<\/p>\n\n\n\n
    C:\\ProgramData\\ssh\\administrators_authorized_keys\n<\/code><\/pre>\n\n\n\n
    This provides a centralized public-key authorization file for administrator accounts.<\/p>\n\n\n\n
    The relevant configuration is typically defined in sshd_config<\/code> with a rule similar to:<\/p>\n\n\n\n
    Match Group administrators\n    AuthorizedKeysFile __PROGRAMDATA__\/ssh\/administrators_authorized_keys\n<\/code><\/pre>\n\n\n\n
    Therefore, for an administrator account:<\/p>\n\n\n\n
    Client public key\n        |\n        v\nC:\\ProgramData\\ssh\\administrators_authorized_keys\n<\/code><\/pre>\n\n\n\n
    This file should not be confused with:<\/p>\n\n\n\n
    ssh_host_ed25519_key.pub\n<\/code><\/pre>\n\n\n\n
    The difference is fundamental:<\/p>\n\n\n\n
    administrators_authorized_keys\n    = who is allowed to log in\n\nssh_host_ed25519_key.pub\n    = identity of the Windows SSH server\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    7. What the Other Files in C:\\ProgramData\\ssh<\/code> Do<\/h2>\n\n\n\n
    sshd_config<\/code><\/h3>\n\n\n\n
    C:\\ProgramData\\ssh\\sshd_config\n<\/code><\/pre>\n\n\n\n
    This is the main OpenSSH Server configuration file.<\/p>\n\n\n\n
    It controls settings such as:<\/p>\n\n\n\n
      \n
    • SSH listening port<\/li>\n\n\n\n
    • authentication methods<\/li>\n\n\n\n
    • public-key authentication<\/li>\n\n\n\n
    • password authentication<\/li>\n\n\n\n
    • authorized-key locations<\/li>\n\n\n\n
    • logging<\/li>\n\n\n\n
    • access restrictions<\/li>\n\n\n\n
    • host keys<\/li>\n<\/ul>\n\n\n\n
      It can be considered the main configuration file for the Windows SSH server.<\/p>\n\n\n\n
      sshd.pid<\/code><\/h3>\n\n\n\n
      sshd.pid\n<\/code><\/pre>\n\n\n\n
      This records the process ID of the running SSH server process.<\/p>\n\n\n\n
      It is not a key and is not part of authentication.<\/p>\n\n\n\n
      logs<\/code><\/h3>\n\n\n\n
      logs\\\n<\/code><\/pre>\n\n\n\n
      This directory may contain OpenSSH server logs depending on the logging configuration.<\/p>\n\n\n\n
      \n\n\n\n
      8. Windows and Linux Use the Same Basic SSH Model<\/h2>\n\n\n\n
      Although their filesystem layouts are different, Windows OpenSSH and Linux OpenSSH use essentially the same architecture.<\/p>\n\n\n\n
      Purpose<\/th>Windows<\/th>Linux<\/th><\/tr><\/thead>
      Server host keys<\/td>C:\\ProgramData\\ssh\\ssh_host_*<\/code><\/td>\/etc\/ssh\/ssh_host_*<\/code><\/td><\/tr>
      Server configuration<\/td>C:\\ProgramData\\ssh\\sshd_config<\/code><\/td>\/etc\/ssh\/sshd_config<\/code><\/td><\/tr>
      User private key<\/td>%USERPROFILE%\\.ssh\\id_ed25519<\/code><\/td>~\/.ssh\/id_ed25519<\/code><\/td><\/tr>
      User public key<\/td>%USERPROFILE%\\.ssh\\id_ed25519.pub<\/code><\/td>~\/.ssh\/id_ed25519.pub<\/code><\/td><\/tr>
      Authorized client keys<\/td>.ssh\\authorized_keys<\/code><\/td>~\/.ssh\/authorized_keys<\/code><\/td><\/tr>
      Previously trusted servers<\/td>.ssh\\known_hosts<\/code><\/td>~\/.ssh\/known_hosts<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
      The major Windows-specific difference is the special default handling of administrator accounts through:<\/p>\n\n\n\n
      C:\\ProgramData\\ssh\\administrators_authorized_keys\n<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      9. A Simple Mental Model<\/h2>\n\n\n\n
      SSH becomes much easier to understand when reduced to three files or concepts.<\/p>\n\n\n\n
      id_ed25519<\/code><\/h3>\n\n\n\n
      Who am I?\n<\/code><\/pre>\n\n\n\n
      This is the client’s private key.<\/p>\n\n\n\n
      It stays on the client.<\/p>\n\n\n\n
      authorized_keys<\/code><\/h3>\n\n\n\n
      Who may log in?\n<\/code><\/pre>\n\n\n\n
      This is stored on the server and contains authorized client public keys.<\/p>\n\n\n\n
      ssh_host_ed25519_key<\/code><\/h3>\n\n\n\n
      Which server am I?\n<\/code><\/pre>\n\n\n\n
      This is the server’s private host key.<\/p>\n\n\n\n
      It stays on the server.<\/p>\n\n\n\n
      The complete authentication relationship can therefore be visualized as:<\/p>\n\n\n\n
      CLIENT                                    SERVER\n\nid_ed25519\nPrivate user key\n     |\n     | proves possession\n     |\n     +-------------------------------> authorized_keys\n                                       contains permitted\n                                       public user keys\n\n\nknown_hosts\nremembers server\nidentity\n     ^\n     |\n     | server proves identity\n     |\nssh_host_ed25519_key\nexists on the SERVER\n<\/code><\/pre>\n\n\n\n
      There are two independent trust questions:<\/p>\n\n\n\n
      Client asks:\n\"Is this really the server expected?\"\n\nServer asks:\n\"Is this really an authorized user?\"\n<\/code><\/pre>\n\n\n\n
      The host-key system answers the first question.<\/p>\n\n\n\n
      The user-key and authorized_keys<\/code> system answer the second.<\/p>\n\n\n\n
      \n\n\n\n
      10. Practical Security Rules<\/h2>\n\n\n\n
      Several rules prevent most SSH key-management mistakes.<\/p>\n\n\n\n
      Never copy a private key to the remote server.<\/strong><\/p>\n\n\n\n
      Files such as:<\/p>\n\n\n\n
      id_ed25519\nssh_host_ed25519_key\n<\/code><\/pre>\n\n\n\n
      are private keys and should remain on the machine where they were generated.<\/p>\n\n\n\n
      Only public keys such as:<\/p>\n\n\n\n
      id_ed25519.pub\n<\/code><\/pre>\n\n\n\n
      should normally be distributed for user authentication.<\/p>\n\n\n\n
      Do not use:<\/p>\n\n\n\n
      C:\\ProgramData\\ssh\\ssh_host_ed25519_key.pub\n<\/code><\/pre>\n\n\n\n
      as the user public key for logging in to Linux.<\/p>\n\n\n\n
      That file represents the identity of the Windows SSH server<\/strong>, not the Windows user.<\/p>\n\n\n\n
      When Windows needs to log in to another machine, the relevant public key normally comes from:<\/p>\n\n\n\n
      C:\\Users\\<username>\\.ssh\\id_ed25519.pub\n<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      Conclusion<\/h2>\n\n\n\n
      Windows 11’s built-in OpenSSH implementation follows essentially the same security model used on Linux.<\/p>\n\n\n\n
      The apparent complexity mainly comes from the fact that SSH manages two different identities simultaneously:<\/p>\n\n\n\n
        \n
      1. The identity of the server<\/strong>, represented by ssh_host_*<\/code> host keys.<\/li>\n\n\n\n
      2. The identity of the connecting user<\/strong>, represented by user keys such as id_ed25519<\/code>.<\/li>\n<\/ol>\n\n\n\n
        The authorized_keys<\/code> file connects these two sides by telling the server which client public keys are trusted.<\/p>\n\n\n\n
        For Windows administrators, one additional Windows-specific detail is worth remembering:<\/p>\n\n\n\n
        C:\\ProgramData\\ssh\\administrators_authorized_keys\n<\/code><\/pre>\n\n\n\n
        is commonly used to authorize SSH public keys for administrator accounts.<\/p>\n\n\n\n
        Once the distinction between host keys<\/strong>, user keys<\/strong>, and authorized keys<\/strong> is clear, SSH configuration on Windows 11 becomes almost identical conceptually to SSH administration on Linux.<\/p>\n","protected":false},"excerpt":{"rendered":"
        Windows 11 includes native support for OpenSSH, which means it can work both as an SSH client and as an SSH server. This makes it possible to manage Linux servers directly from Windows, connect remotely to Windows from Linux, transfer files with SCP\/SFTP, and use public-key authentication without installing third-party …<\/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":[242],"class_list":["post-6083","post","type-post","status-publish","format-standard","hentry","category-windows","tag-ssh"],"_links":{"self":[{"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/posts\/6083","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=6083"}],"version-history":[{"count":1,"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/posts\/6083\/revisions"}],"predecessor-version":[{"id":6084,"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/posts\/6083\/revisions\/6084"}],"wp:attachment":[{"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/media?parent=6083"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/categories?post=6083"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/tags?post=6083"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}