Editorial Policy

Editorial mission

Independent resource: Putty.info is an independent educational website about PuTTY and SSH. It is not affiliated with, operated by, sponsored by, or endorsed by the official PuTTY project or Simon Tatham. We do not host PuTTY binaries.

Putty.info publishes original educational material that helps people use PuTTY and SSH safely. Each page should target a real operator problem, cite primary sources for facts that need them, and avoid thin spun text.

Content standards

  • Original writing inspired by real PuTTY concepts—not verbatim copies of the official manual.
  • Concrete UI panel names (Session, Connection → SSH → Auth, Tunnels) when instructing Windows users.
  • Clear independent-site disclosure, especially on download and security pages.
  • No hosting of PuTTY binaries; official links only.
  • Examples use documentation hosts such as example.com or TEST-NET addresses.
  • Corrections welcomed; security-impacting errors prioritized.

Sources

We prefer official PuTTY project pages, documentation, FAQ, changelog, and licence text; OS vendor docs; and CVE/vendor advisories. See Source policy for verification states. Unverified scrapes are never silent “truth.”

Conflicts of interest

Editors should disclose material conflicts. Advertising and affiliate rules appear on their respective disclosure pages. Editorial conclusions about safety are not for sale.

Review cadence

Pages carry reviewed_at metadata. High-traffic download and host-key articles are reviewed preferentially when official releases or advisories change. Snapshot version numbers displayed elsewhere on the site come from monitored official sources with fail-safe behaviour when verification fails.

Contact editors

Use the contact form with Correction request or Security-content correction. Include URLs and supporting sources.

Field notes and runbook extras

Additional operational depth for Editorial Policy (path /editorial-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.

Sources