Microsoft's integration of OpenSSH in Windows 10 (build 1809 and later) provides native SSH capabilities, but its configuration differs from typical Linux implementations. The configuration file resides at C:\Windows\System32\OpenSSH\sshd_config, requiring administrative privileges for modification.

To properly disable password authentication, three critical directives must be set:

# Core security settings
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no

Unlike Unix systems, Windows requires special handling of services:

# PowerShell commands for proper service restart
Restart-Service ssh-agent -Force
Restart-Service sshd -Force

Important: Simply restarting services through the GUI may not properly reload configurations. The SSH Broker and SSH Proxy services should remain running but don't require restarting.

After making changes, verify with:

ssh -v -o PreferredAuthentications=publickey user@localhost

Expected output should show:

debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

Windows OpenSSH has specific requirements for the authorized_keys file:

• Must be located at C:\Users\username\.ssh\authorized_keys
• Requires NTFS permissions: SYSTEM and Administrator (Full Control), User (Read)
• Inheritance should be disabled for the .ssh folder

For enterprise environments, consider these additional hardening measures:

# Additional security parameters
PermitEmptyPasswords no
PermitRootLogin no
MaxAuthTries 3
LoginGraceTime 1m

If password authentication persists:

1. Check for multiple sshd_config files (search entire system)
2. Verify no Group Policy is overriding settings
3. Examine Windows Event Viewer for SSH-related errors
4. Test with fresh local user account

For high-traffic servers, adjust these parameters:

MaxSessions 10
MaxStartups 30:60:120
ClientAliveInterval 300
ClientAliveCountMax 3

---

When working with Windows 10's built-in OpenSSH server, many administrators encounter a frustrating scenario: despite explicitly setting PasswordAuthentication no in sshd_config, the server continues to accept password logins. This behavior persists even after restarting all related services.

The complete set of required changes in C:\ProgramData\ssh\sshd_config (note the corrected path) includes:

# Core authentication settings
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no
PubkeyAuthentication yes

Unlike Unix systems, Windows OpenSSH requires additional steps:

1. Verify the correct config file location:
   Default: C:\ProgramData\ssh\sshd_config
   Alternative: C:\Windows\System32\OpenSSH\sshd_config (less common)

2. Set proper permissions:
   icacls "C:\ProgramData\ssh\sshd_config" /grant "NT SERVICE\sshd":(R)

3. Restart services in this specific order:
   Stop-Service sshd
   Stop-Service ssh-agent
   Start-Service ssh-agent
   Start-Service sshd

To verify active authentication methods, run this PowerShell command after configuration changes:

sshd -T | Select-String -Pattern "authentication"

Expected output should show:

passwordauthentication no
challengeresponseauthentication no
pubkeyauthentication yes

For domain-joined machines, check for conflicting GPO settings:

Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\OpenSSH\Server"

Here's a verified functional configuration for passwordless authentication:

# Authentication:
LoginGraceTime 30
PermitRootLogin prohibit-password
StrictModes yes
MaxAuthTries 3
MaxSessions 5

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

# Disable password authentication
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no

# Security enhancements
ClientAliveInterval 300
ClientAliveCountMax 2
MaxStartups 10:30:60

Test your configuration with these SSH client options:

ssh -v -o PreferredAuthentications=publickey user@localhost
ssh -v -o PreferredAuthentications=password user@localhost

The first should succeed (if you've configured public keys properly) while the second must fail with "Permission denied" if password authentication is truly disabled.