When facing authentication failures with freeSSHd, first verify these critical configurations:

1. Service running status:
   net start | find "freeSSHd"

2. Port binding:
   netstat -ano | find ":22"

3. User permissions:
   Ensure the account has "Log on as a service" right in:
   secpol.msc -> Local Policies -> User Rights Assignment

The most common pitfall is mismatched authentication settings. In freeSSHd.exe GUI:

- Navigate to Authentication tab
- Check "Password authentication" is enabled
- For NTLM auth, ensure: 
  [X] Enable NTLM authentication
  [X] Enable keyboard-interactive authentication

- For SHA1 hashed passwords:
  [X] Password stored as SHA1 hash
  [ ] Enable NTLM authentication

Beyond just opening port 22, Windows Firewall may block the freeSSHd process specifically:

# Create permanent firewall rule (admin cmd):
netsh advfirewall firewall add rule name="freeSSHd" dir=in action=allow program="C:\Program Files\freeSSHd\freeSSHd.exe" enable=yes

Enable detailed logging in freeSSHd.ini:

[Log]
LogLevel=5  # Debug mode
LogFile=C:\freeSSHd.log

Key log entries to monitor:

2024/01/01 12:00: Auth: NTLM failed for user 'dspitzer'
2024/01/01 12:01: Auth: SHA1 password mismatch

Use PuTTY with event logging for detailed diagnostics:

putty.exe -v -ssh -l dspitzer 12.34.56.78 -loghost:putty.log

Or with OpenSSH in verbose mode:

ssh -vvv dspitzer@12.34.56.78

Create a test PowerShell script to verify credentials independently:

# Test-LocalCredential.ps1
param($username, $password)

Add-Type -AssemblyName System.DirectoryServices.AccountManagement
$context = New-Object System.DirectoryServices.AccountManagement.PrincipalContext([System.DirectoryServices.AccountManagement.ContextType]::Machine)
$context.ValidateCredentials($username, $password)

---

After setting up freeSSHd on Windows Server 2008 with proper firewall rules and user accounts, many administrators still encounter persistent "Permission denied" errors during SSH authentication attempts. Let's break down the complete troubleshooting process.

First, confirm that freeSSHd is running as a service with proper permissions:

sc query freeSSHd
net start freeSSHd

Check the service properties to ensure it's set to log on with sufficient privileges (typically "Local System account" with "Allow service to interact with desktop" enabled).

The most common culprit is authentication method mismatch. In freeSSHd's GUI:
1. Navigate to Authentication tab
2. Ensure "Password authentication" is enabled
3. Verify your selected authorization method (NTLM/SHA1) matches the user account type
4. For NTLM, the Windows account must exist and have login rights

Even with port 22 open, Windows Firewall might still block the connection. Run these commands:

netsh advfirewall firewall show rule name="freeSSHd"
telnet 127.0.0.1 22

If local connections work but remote fail, create an explicit inbound rule:

netsh advfirewall firewall add rule name="SSHD" dir=in action=allow protocol=TCP localport=22

For NTLM authentication, the account must:
- Not be locked out
- Have password never expired
- Have proper user rights assignment
- Not require smart card authentication

Check these settings in Local Security Policy (secpol.msc):
- Local Policies → User Rights Assignment → "Allow log on locally"
- Account Policies → Password Policy

From your SSH client, use verbose mode to identify where authentication fails:

ssh -vvv dspitzer@12.34.56.78

Look for these key messages in the output:
- "Authentication succeeded" (indicates server-side rejection)
- "Permission denied" timing (immediate vs delayed response)
- Supported authentication methods list

If standard setup fails, try these advanced options:

# In freeSSHd.ini configuration file:
[SSH]
Authentication=password,publickey
AllowEmptyPasswords=0
PasswordAttempts=3

For public key authentication (recommended for production):
1. Generate keys on client: ssh-keygen -t rsa
2. Copy public key to server's authorized_keys file
3. In freeSSHd GUI: enable publickey authentication

Examine freeSSHd's logs (typically in %ProgramFiles%\freeSSHd):
- Failed login attempts with error codes
- Authentication method used
- IP address of connecting client

Common log patterns to investigate:
- "USER=dspitzer AUTH=password RESULT=fail"
- "AUTH: invalid user/password combination"

The freeSSHd service account needs these minimum permissions:
- "Log on as a service" right
- Read access to HKLM\SOFTWARE\freeSSHd registry key
- Write access to its installation directory

Verify with:

whoami /priv
icacls "C:\Program Files\freeSSHd"