Overview

The Windows SSH User Policy gives users SSH access to managed Windows devices with their public keys. You list each user and their keys in the policy, and the Swif agent adds them to the device's OpenSSH configuration.

Use it to give admins or support staff key-based SSH access to Windows devices, and to manage that access centrally.

Important: Administrator accounts share one key file on Windows. Windows OpenSSH stores the keys for every member of the local Administrators group in one shared file, C:\ProgramData\ssh\administrators_authorized_keys. A key added for one administrator account can sign in to any administrator account on the device. Grant SSH access to administrator accounts only to people you trust with every administrator account.

Requirements

Requirement	Details
Platform	Windows 10 or later
Device ownership	Company-owned and BYOD
Swif agent	Installed and running
OpenSSH Server	[Confirm whether Swif installs and starts OpenSSH Server, or whether it must already be set up.]
Accounts	Local Windows accounts or Active Directory (domain) accounts. Microsoft Entra ID accounts can't sign in with SSH keys.
Network	Users must be able to reach the device on the SSH port (TCP 22 by default)

Settings reference

Users

Each entry is one user who can sign in over SSH.

Field	What to enter	Required
Username	The Windows account name that accepts the keys, such as `admin`	Yes
Public Keys	One OpenSSH public key per entry, such as an `ssh-ed25519` or `ssh-rsa` key	No

Public key format. Use the format from an authorized_keys file, such as the contents of id_ed25519.pub. For example: ssh-ed25519 AAAAC3Nza... user@laptop

Add each key as its own entry. A user with a laptop and a desktop can have two keys. Only add public keys (the .pub file). Never paste a private key into the policy.

How Windows stores the keys

Account type	Where Windows OpenSSH reads keys
Standard user	The user's own `C:\Users\<username>\.ssh\authorized_keys`
Member of the local Administrators group	The shared `C:\ProgramData\ssh\administrators_authorized_keys`

This is how Windows OpenSSH works by default.

Things to know about SSH on Windows

Microsoft Entra ID accounts aren't supported. Windows OpenSSH supports key-based sign-in only for local and Active Directory accounts.
SSH sessions can't access network resources as the user. A session started with a key has no user credentials, so it can't sign in to network shares or other servers as that user. This is how Windows OpenSSH is designed.

Before you start

Collect each user's public key. Ask users to send their .pub file. If someone needs a new key, they can create one with:
```
ssh-keygen -t ed25519
```
Check the account names on the devices. Use each account's exact Windows name.
Decide whether administrator accounts need SSH access. Remember that administrator keys are shared across all administrator accounts.
Check network access. Make sure users can reach the devices on the SSH port, through your firewall or VPN if needed.

Create the policy

In Swif, go to Device Management > Policies, then select Create new policy > Configure a Policy.
Select Windows SSH User Policy.
Enter a clear name, such as Windows SSH – IT Support.
Under Users, add a user:
- Username: the Windows account name
- Public Keys: one entry per key
Repeat for each user who needs access.
Save the policy.
Assign it to a device group of Windows devices.

Example configuration

IT support access to Windows workstations

Add two users:

Username: itsupport
- Public Keys: ssh-ed25519 AAAAC3Nza...1 alex@laptop
- Public Keys: ssh-ed25519 AAAAC3Nza...2 alex@desktop
Username: helpdesk
- Public Keys: ssh-ed25519 AAAAC3Nza...3 sam@laptop

Assign the policy to a device group of Windows workstations. Both support accounts can sign in over SSH with their keys.

Verify the policy

Test with a throwaway key before you give access to real users.

On your computer, create a test key:

ssh-keygen -t ed25519 -N "" -f ~/.ssh/qa_key

Copy the line in ~/.ssh/qa_key.pub into the policy as the public key of a test account. Assign the policy to a Windows device you can reach on port 22.
Wait a few minutes after the policy is sent to the device.

ssh -i ~/.ssh/qa_key <username>@<device-ip>

The sign-in should succeed.

Remove the user from the policy, or unassign the policy. Run the same command again. It should end with Permission denied (publickey).

When you're done, delete the test key:

rm ~/.ssh/qa_key ~/.ssh/qa_key.pub

Troubleshooting

The sign-in fails with Permission denied (publickey)

Wait a few minutes after the policy is sent, then try again.
Check that the key in the policy matches the private key you're using with ssh -i.
Check that the username matches the Windows account name exactly.
Check that the account is a local or Active Directory account. Microsoft Entra ID accounts can't sign in with keys.

The connection times out or is refused

The device isn't reachable on the SSH port. Check that:

the device is online
your firewall or VPN allows the connection
the OpenSSH Server service (sshd) is running on the device

An administrator's key signs in to another administrator account

This is how Windows OpenSSH works. Keys for administrator accounts are stored in one shared file, so any of them can sign in to any administrator account.

A user can't access network shares over SSH

This is expected. SSH sessions started with a key have no user credentials, so they can't sign in to other resources as the user.

Related resources

Swif

Microsoft

Key-based authentication in OpenSSH for Windows