"Bad Permissions" Was Never About the Permissions

OpenSSH kept rejecting a private key as insecure no matter how the file's Windows ACLs were rewritten — because the check it was actually running had nothing to do with the ACL at all.

July 31, 2026

This article is also available in Traditional Chinese: 中文版 — same content, just a language difference.

Setting up an SSH reverse tunnel as a background Windows service, OpenSSH refused the private key every time with a "bad permissions" / "too open" error — the exact wording that points straight at file ACLs. Round after round of permission tightening changed nothing, because the actual invariant being checked wasn't a permission bit at all.

The obvious fix, applied repeatedly, with zero effect

The setup: an SSH reverse tunnel running as a Windows background service (via a service-wrapper tool, so it starts unattended rather than needing an interactive login), using a private key file for authentication. OpenSSH refused to use the key every time the service started, with an error to the effect of "UNPROTECTED PRIVATE KEY FILE" / permissions too open — wording that reads as an unambiguous instruction to fix the file's access control list. That's exactly what got tried, repeatedly: stripping inherited permissions from the key file, granting explicit, minimal access only to the account the service ran as, re-checking the resulting ACL directly to confirm it looked textbook-correct. Every round produced an ACL that, by every normal reading of Windows file permissions, should have satisfied any reasonable security check. The error didn't change at all.

Unlock this article to keep reading, or subscribe for unlimited access to everything. See Pricing for details.