Corrections Policy

Corrections policy

We correct factual errors, misleading wording, and broken primary-source links. We cannot reconfigure your servers or reset your host-key cache for you.

How to request a correction

1. Open the contact form and choose Correction request or Security-content correction.
2. Include the exact page URL and the incorrect sentence or screenshot.
3. Provide a preferred correction and a primary source link when claiming a factual error.
4. Omit passwords, private keys, and confidential logs; redact aggressively.

Priority

Security-impacting mistakes (fake download advice, host-key handling, key compromise steps) outrank typographical issues. We may edit for clarity without a formal note on minor typos; substantive corrections update the page content and review timestamp.

Out of scope

• Requests to troubleshoot a single private server without public educational value.
• Demands to host binaries or mirror unofficial builds.
• Unsourced claims that contradict official documentation without evidence.
• Personal disputes unrelated to site content accuracy.

Follow-up

If you believe a correction was mishandled, reply with additional primary sources. We aim to be accurate, not merely fast.

Field notes and runbook extras

Additional operational depth for Corrections Policy (path /corrections-policy/): treat every change to authentication, forwarding, or host-key storage as a reversible change under change control. Record the PuTTY version string from Help → About, the Windows build, and whether Pageant was running. Those three facts explain a surprising fraction of “it works on my laptop” discrepancies.

When documenting the procedure for teammates, include: the saved session name, Host Name and Port from the Session panel, whether Connection type is SSH, the username, whether a PPK path is set under Connection → SSH → Auth, and whether agent forwarding is enabled. Explicitly state that Putty.info is an independent educational site and that binaries must be obtained from the official project download page. Link readers to safe download guidance, host key verification, and the official manual so they can cross-check labels that differ slightly across releases.

If you still need more diagnostics after following the sections above, reproduce the issue with logging enabled under Session → Logging to a local file you control, scrub secrets from the transcript, and compare against server auth logs for the same UTC timestamp. Avoid third-party “PuTTY fix” utilities. Prefer updating to the current stable release from official hosts, re-importing a known-good saved session, and testing from a second network path before declaring the workstation broken.

• Keep private keys passphrase-protected and backed up offline according to your organization's secret-handling policy.
• Prefer named saved sessions over ad-hoc connections for anything beyond a one-off debug.
• Disable unused tunnels and agent forwarding by default; enable them per session only when required.
• Schedule periodic key rotation and remove stale authorized_keys entries during access reviews.
• Teach new operators the difference between connection errors and authentication errors before giving them production bastion access.