Good — the WinMerge message confirms the files differ only by EOL, which is a very likely reason the server rejected the key. On Windows the authorized_keys must be the exact OpenSSH-format public-key line (no CRLF/BOM/extra characters) and readable by sshd; converting the file to Unix line endings (LF) and removing any BOM normally fixes this. Below are safe, concrete steps (with copy/paste commands) to fix EOL/encoding, verify the key matches, and confirm ACLs — followed by what to send me if it still fails. I’ve included the same troubleshooting checks we discussed earlier.
Quick plan
1) Back up the current authorized_keys.
2) Replace/rewrite authorized_keys with the exact public-key output from the client, saved with LF-only line endings and no BOM.
3) Verify fingerprints match between client key and server file.
4) Confirm ACLs so sshd can read the file.
5) Retry and read the DEBUG3 log if it still fails.
Commands — do these on the server (run PowerShell as Administrator)
1) Back up existing file
Replace <username> with the Windows account name.
PowerShell:
Copy-Item -Path "C:\Users\<username>.ssh\authorized_keys" -Destination "C:\Users\<username>.ssh\authorized_keys.bak"
2) On the client produce the exact public key line
(on MobaXterm / client shell)
ssh-keygen -y -f ~/.ssh/id_rsa > /tmp/mykey.pub
cat /tmp/mykey.pub
Copy the single line it prints (starts with ssh-rsa or ssh-ed25519 ....
3) Recreate authorized_keys on the server as a plain, single-line file with LF and no BOM
On the server (PowerShell), paste the one-line public key into the command below (replace <paste-key-here> with the copied single line exactly):
Set-Content -Path "C:\Users\<username>.ssh\authorized_keys" -Value '<paste-key-here>' -Encoding ascii
Notes:
- Using -Encoding ascii (or -Encoding utf8NoBOM on newer PowerShell) ensures no BOM is added; ascii is safe because the key line is plain ASCII. This removes CRLF/BOM issues. If you prefer GUI, open the file in Notepad++ and: Encoding → UTF-8 without BOM, Edit → EOL Conversion → UNIX (LF), then Save.
4) Verify fingerprints match (client vs server)
- Client fingerprint (run on the client):
ssh-keygen -y -f ~/.ssh/id_rsa | ssh-keygen -lf -
- Server fingerprint (on the server; creates temp file from authorized_keys and checks it with the OpenSSH ssh-keygen that ships with Windows):
$ak = Get-Content "C:\Users\<username>.ssh\authorized_keys"
Set-Content -Path C:\Temp\authkey.pub -Value $ak -Encoding ascii
& 'C:\Windows\System32\OpenSSH\ssh-keygen.exe' -lf C:\Temp\authkey.pub
Compare the two fingerprints; they must be identical. If they differ, the public key on the server is not the same as the private key on the client and you need to re-copy the client output exactly.
5) Check and set safe ACLs so sshd can read the file
Show current ACLs:
icacls "C:\Users\<username>.ssh"
icacls "C:\Users\<username>.ssh\authorized_keys"
A practical (safe-enough) fix to apply (run as Administrator; replace <username>):
icacls "C:\Users\<username>.ssh" /grant "<username
F)" /grant "SYSTEM
F)" /grant "Administrators
F)" /T
icacls "C:\Users\<username>.ssh\authorized_keys" /grant "<username
R)" /grant "SYSTEM
R)" /grant "Administrators
R)"
After changing ACLs restart the sshd service:
Restart-Service sshd
Windows OpenSSH has known ACL/permission gotchas after some updates — fixing ACLs is a common resolution.
6) (Optional short test) Temporarily set StrictModes no to rule out permission problems quickly
- Edit C:\ProgramData\ssh\sshd_config and set StrictModes no, Restart-Service sshd, then test. If key auth works only when StrictModes is off, the issue is definitely permissions/ownership/line-ending related. (Do not leave StrictModes disabled in production.
7) Re-test from the client with max verbosity and, if it fails, collect the server debug lines
Client:
ssh -vvv -i ~/.ssh/id_rsa
username>@<server
If auth still fails, on the server collect the DEBUG3 lines from Event Viewer / OpenSSH log around the failure and paste them here (about 10–20 lines). That log will show the precise reason (e.g., “no matching key found”, “bad ownership or modes”, “signature invalid”).
If you want, I can give you a one-line pipeline to copy the client public key into the server authorized_keys over an SSH/password session (so you avoid manual paste), or exact PowerShell commands that write the key and set ACLs automatically — tell me whether you prefer to (A) paste the key manually or (B) use an automated command and I’ll provide it.
Recap / next steps
- Convert authorized_keys to LF/no BOM and overwrite it with the client’s ssh-keygen -y output; verify fingerprints as shown.
- Ensure ACLs permit SYSTEM and the user to read the file; restart sshd.
- If it still fails, paste: (a) the server DEBUG3 log lines around the Failed publickey, and (b) the outputs of the two icacls commands above. I’ll read them and tell you the exact fix.
Which do you want to do now — paste the public-key line and I’ll give the exact Set-Content command with it, or shall I provide the automated copy command you can run from the client?
