Developer tools · Chmod calculator
SSH permissions too open: the exact modes ~/.ssh needs and why
· Why it matters
chmod unix access-control
OpenSSH refuses keys and authorized_keys files that other users could read or change. This post lists the modes it expects, explains the StrictModes check, and shows how to verify them.
Permissions 0644 for id_ed25519 are too open — the key that worked yesterday is rejected after a copy to a new machine
A copied private key with mode 0644 decodes to rw-r--r--. The owner may read and change it, while group and other may read it. The 600 private-file preset instead renders rw-------, leaving those classes empty. This states the bits precisely, but cannot prove why an SSH client accepted or rejected the key.
Compare the observed mode with the private preset. Inputs 0644, 644 and 0o644 are equivalent, and changing to 600 removes group-read and other-read while preserving owner read and write. The generated command is inert. Client behavior, ownership, ACLs and storage semantics require evidence beyond this converter.
Why the client checks at all — a private key readable by others is no longer private, so ssh refuses to trust it
The repository labels 600 “private file” and describes owner-only access. Its arithmetic supports that description: 6 gives owner read and write, while both zeroes remove ordinary permissions from group and other. The symbolic result is rw-------. This proves the grants are absent from the mode, not that a client accepts it.
No OpenSSH implementation, manual, configuration or runtime message appears in the sources, so the preset cannot establish refusal policy. The calculator neither promises that one mode resolves every error nor validates key contents. It reliably shows whether a candidate exposes read, write or execute beyond the owner class, and no more.
The repository labels 600 private; client refusal policy needs OpenSSH evidence
StrictModes behavior is neither implemented nor verified here. The browser has no SSH server, home-directory inspection, ownership lookup or configuration input. It cannot know whether authorized_keys is consulted, whether another identity can write a directory or whether a setting applies. Entering a mode performs conversion, not a daemon decision or filesystem audit.
Accurate bits and accurate policy are separate questions. Mode 600 proves rw-------, while 700 proves rwx------. Neither identifies ownership, checks parent directories or models a daemon. Collect server documentation and filesystem evidence independently, then use the calculator to decode observations without presenting its output as a StrictModes verdict or complete security audit.
StrictModes behavior is not implemented or verified here
Modes 600 and 700 are shipped private presets. Mode 600 gives a regular file owner read and write, with no group or other permissions. Mode 700 adds owner execute for a directory, enabling entry and named-content access, while other classes receive nothing through ordinary bits. The calculator still knows no actual owner.
Other SSH-related file rules remain external. Although public keys and authorized_keys may be relevant, the repository supplies no verified requirements for them. The calculator can decode 644 as rw-r--r-- but cannot certify SSH acceptance. Any broader requirements table needs authoritative OpenSSH evidence absent from these sources and the existing article.
600 and 700 are shipped private presets; other SSH file rules remain external
A supported example converts listing strings without auditing a directory. If external output shows -rw-r--r--, the parser returns 644; if it shows rw-------, it returns 600. The matrix highlights the changed group-read and other-read boxes. This verifies transcription and arithmetic while leaving path, ownership and listing provenance unexamined.
Directory strings work similarly. A supplied drwx------ becomes 700 because the recognized type character is removed before parsing nine permission positions. The summary can display a directory prefix. The page neither lists ~/.ssh nor discovers files, owners or ACL indicators, so this conversion must not be described as an audit.
Worked example: convert copied mode strings without auditing the directory
Mode loss across transfer tools and filesystems lies outside repository evidence. No source copies files, opens archives, mounts storage or compares metadata across locations. The calculator cannot attribute an observed 644 to a share, drive, initialization system or archive utility. It sees only the mode typed into its field, without transfer history.
When a copied item has an unexpected mode, compare expected and observed values without assigning blame. Between 600 and 644, owner permissions stay unchanged while group-read and other-read appear. The converter supports that exact delta. Determining whether transfer, preservation or recreation caused it requires evidence from the destination and transfer path.
Mode loss across transfer tools and filesystems is outside repository evidence
Key format, agent state and server logs fall outside this calculator. It parses octal and symbolic permission text, never private keys, ssh-agent data or logs. A valid 600 conversion says nothing about cryptographic material, loaded identities, network exchange or server response. It proves only owner read and write with empty group and other classes.
This boundary prevents treating every SSH failure as chmod work. If an observed mode differs from the private preset, the calculator shows exact bits; if it already matches, the route offers no further SSH evidence. Continue with external diagnostics rather than broadening access. Successful conversion is not authentication, and the preview executes nothing.
Takeaway: private means 600 and 700 — and the calculator confirms that a mode you are about to set gives nothing to group or others
The repository-backed takeaway is that 600 and 700 reserve ordinary permissions for the owner. Their symbolic forms, rw------- and rwx------, contain no group or other grants. Octal, symbolic text, checkboxes and summary verify those representations, while malformed positions are rejected. None of this proves SSH acceptance, ownership, key validity or authentication.
Do not turn conversion into universal SSH policy. The route does not implement StrictModes, inspect home directories, identify owners or validate key files. Use it to confirm empty group and other classes, then rely on authoritative SSH evidence and the actual system. Copying a displayed command transfers responsibility to the shell and filesystem.