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 SSH software.
The most important concept is that SSH uses different keys for different purposes. The keys used when Windows acts as a server are not the same as the keys used when Windows acts as a client.
1. Windows 11 as an SSH Client
When Windows connects to another machine, it acts as the SSH client.
For example:
ssh user@192.168.1.100
The SSH client is normally included with Windows 11 and can be checked with:
ssh -V
A typical installation reports something similar to:
OpenSSH_for_Windows_...
Client-side user keys
Public-key authentication normally uses a key pair stored under the current Windows user’s profile:
C:\Users\<username>\.ssh\
For an ED25519 key pair:
id_ed25519
id_ed25519.pub
Their roles are:
id_ed25519 Private key
id_ed25519.pub Public key
The private key must remain on the Windows computer.
The public key is copied to machines that Windows needs to access.
For example, when connecting to a Linux account, the contents of:
C:\Users\<username>\.ssh\id_ed25519.pub
are added to:
~/.ssh/authorized_keys
on the Linux server.
If no key pair exists, one can be generated with:
ssh-keygen -t ed25519
In simple terms:
Windows client
|
| owns private key
|
+-- id_ed25519
Public key
|
+---------> remote server
~/.ssh/authorized_keys
The private key proves the identity of the user connecting to the server.
2. Windows 11 as an SSH Server
Windows 11 can also run OpenSSH Server, allowing another computer to connect to Windows using SSH.
The server-side files are mainly stored in:
C:\ProgramData\ssh\
A typical directory may contain:
administrators_authorized_keys
ssh_host_ecdsa_key
ssh_host_ecdsa_key.pub
ssh_host_ed25519_key
ssh_host_ed25519_key.pub
ssh_host_rsa_key
ssh_host_rsa_key.pub
sshd_config
sshd.pid
logs\
At first glance, the number of key files may seem excessive. In reality, they fall into a few clearly defined categories.
3. Host Keys: The Identity of the Windows SSH Server
Files beginning with:
ssh_host_
are server host keys.
Examples include:
ssh_host_ed25519_key
ssh_host_ed25519_key.pub
and:
ssh_host_rsa_key
ssh_host_rsa_key.pub
There are usually several sets because OpenSSH supports multiple cryptographic algorithms:
- ED25519
- ECDSA
- RSA
Each algorithm has a private key and a public key.
For example:
ssh_host_ed25519_key Private host key
ssh_host_ed25519_key.pub Public host key
These keys answer a specific question:
Which SSH server is the client connecting to?
They identify the Windows machine itself as an SSH server.
They do not identify the Windows user who is connecting to another server.
This distinction is important.
When an SSH client connects to a server for the first time, a message may appear similar to:
The authenticity of host ... can't be established.
ED25519 key fingerprint is SHA256:...
That fingerprint is derived from the SSH server’s host key.
After accepting it, the client normally records the server identity in:
known_hosts
This helps detect unexpected changes to the server’s SSH identity during later connections.
4. User Keys and Host Keys Are Different
The easiest way to understand SSH keys is to separate two identities.
Server identity
The server proves:
This is the same server that was connected to previously.
Windows stores its server host keys under:
C:\ProgramData\ssh\ssh_host_*
Linux normally stores equivalent keys under:
/etc/ssh/ssh_host_*
Client user identity
The client proves:
This user possesses the private key corresponding to an authorized public key.
Windows normally stores user keys under:
C:\Users\<username>\.ssh\
Linux normally stores them under:
~/.ssh/
Therefore:
Host key = identity of the SSH server
User key = identity of the user connecting to the SSH server
These are two separate key systems even though both use SSH cryptography.
5. What authorized_keys Does
Another important file is:
authorized_keys
This file does not contain the server’s own identity.
Instead, it contains the public keys of users or devices that are allowed to log in.
For example:
Client machine
C:\Users\<username>\.ssh\id_ed25519.pub
|
|
v
Linux server
/home/user/.ssh/authorized_keys
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.
Linux usually keeps an authorized_keys file for each account:
/home/alice/.ssh/authorized_keys
/home/bob/.ssh/authorized_keys
/root/.ssh/authorized_keys
Windows OpenSSH follows essentially the same design for ordinary users:
C:\Users\<username>\.ssh\authorized_keys
6. The Windows Administrator Exception
Windows OpenSSH has an important default behavior for accounts belonging to the Administrators group.
Instead of using:
C:\Users\<administrator>\.ssh\authorized_keys
the default configuration commonly uses:
C:\ProgramData\ssh\administrators_authorized_keys
This provides a centralized public-key authorization file for administrator accounts.
The relevant configuration is typically defined in sshd_config with a rule similar to:
Match Group administrators
AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys
Therefore, for an administrator account:
Client public key
|
v
C:\ProgramData\ssh\administrators_authorized_keys
This file should not be confused with:
ssh_host_ed25519_key.pub
The difference is fundamental:
administrators_authorized_keys
= who is allowed to log in
ssh_host_ed25519_key.pub
= identity of the Windows SSH server
7. What the Other Files in C:\ProgramData\ssh Do
sshd_config
C:\ProgramData\ssh\sshd_config
This is the main OpenSSH Server configuration file.
It controls settings such as:
- SSH listening port
- authentication methods
- public-key authentication
- password authentication
- authorized-key locations
- logging
- access restrictions
- host keys
It can be considered the main configuration file for the Windows SSH server.
sshd.pid
sshd.pid
This records the process ID of the running SSH server process.
It is not a key and is not part of authentication.
logs
logs\
This directory may contain OpenSSH server logs depending on the logging configuration.
8. Windows and Linux Use the Same Basic SSH Model
Although their filesystem layouts are different, Windows OpenSSH and Linux OpenSSH use essentially the same architecture.
| Purpose | Windows | Linux |
|---|---|---|
| Server host keys | C:\ProgramData\ssh\ssh_host_* | /etc/ssh/ssh_host_* |
| Server configuration | C:\ProgramData\ssh\sshd_config | /etc/ssh/sshd_config |
| User private key | %USERPROFILE%\.ssh\id_ed25519 | ~/.ssh/id_ed25519 |
| User public key | %USERPROFILE%\.ssh\id_ed25519.pub | ~/.ssh/id_ed25519.pub |
| Authorized client keys | .ssh\authorized_keys | ~/.ssh/authorized_keys |
| Previously trusted servers | .ssh\known_hosts | ~/.ssh/known_hosts |
The major Windows-specific difference is the special default handling of administrator accounts through:
C:\ProgramData\ssh\administrators_authorized_keys
9. A Simple Mental Model
SSH becomes much easier to understand when reduced to three files or concepts.
id_ed25519
Who am I?
This is the client’s private key.
It stays on the client.
authorized_keys
Who may log in?
This is stored on the server and contains authorized client public keys.
ssh_host_ed25519_key
Which server am I?
This is the server’s private host key.
It stays on the server.
The complete authentication relationship can therefore be visualized as:
CLIENT SERVER
id_ed25519
Private user key
|
| proves possession
|
+-------------------------------> authorized_keys
contains permitted
public user keys
known_hosts
remembers server
identity
^
|
| server proves identity
|
ssh_host_ed25519_key
exists on the SERVER
There are two independent trust questions:
Client asks:
"Is this really the server expected?"
Server asks:
"Is this really an authorized user?"
The host-key system answers the first question.
The user-key and authorized_keys system answer the second.
10. Practical Security Rules
Several rules prevent most SSH key-management mistakes.
Never copy a private key to the remote server.
Files such as:
id_ed25519
ssh_host_ed25519_key
are private keys and should remain on the machine where they were generated.
Only public keys such as:
id_ed25519.pub
should normally be distributed for user authentication.
Do not use:
C:\ProgramData\ssh\ssh_host_ed25519_key.pub
as the user public key for logging in to Linux.
That file represents the identity of the Windows SSH server, not the Windows user.
When Windows needs to log in to another machine, the relevant public key normally comes from:
C:\Users\<username>\.ssh\id_ed25519.pub
Conclusion
Windows 11’s built-in OpenSSH implementation follows essentially the same security model used on Linux.
The apparent complexity mainly comes from the fact that SSH manages two different identities simultaneously:
- The identity of the server, represented by
ssh_host_*host keys. - The identity of the connecting user, represented by user keys such as
id_ed25519.
The authorized_keys file connects these two sides by telling the server which client public keys are trusted.
For Windows administrators, one additional Windows-specific detail is worth remembering:
C:\ProgramData\ssh\administrators_authorized_keys
is commonly used to authorize SSH public keys for administrator accounts.
Once the distinction between host keys, user keys, and authorized keys is clear, SSH configuration on Windows 11 becomes almost identical conceptually to SSH administration on Linux.