audit-ssh-keys 0.1.0__tar.gz

audit_ssh_keys-0.1.0/.gitignore

@@ -0,0 +1,25 @@
+# Generated test keys — tests create these with ssh-keygen; never commit them
+id_*
+ssh_host_*
+*.pem
+
+# Python
+__pycache__/
+*.py[cod]
+.pytest_cache/
+.ruff_cache/
+.coverage
+.coverage.*
+coverage.xml
+htmlcov/
+dist/
+build/
+*.egg-info/
+
+# Environments
+.venv/
+venv/
+# Tool-manager lockfile: the tool has no runtime dependencies, and the dev
+# workflow is `pip install -e ".[dev]"`, so nothing reads this file. Revisit
+# if CI adopts uv.
+uv.lock

audit_ssh_keys-0.1.0/CHANGELOG.md

@@ -0,0 +1,21 @@
+# Changelog
+
+All notable changes to this project will be documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+## [0.1.0] - 2026-09-12
+
+### Added
+
+- Initial release: audits `sshd` host keys, every account's `authorized_keys` (resolved from the effective `AuthorizedKeysFile`), and private keys in `~/.ssh`
+- Server-configuration checks for weak accepted signature algorithms, `StrictModes`, `PermitRootLogin`, and password authentication
+- Coverage warnings when keys come from `AuthorizedKeysCommand` or `TrustedUserCAKeys`, when `HostKeyAgent` holds the private host keys, or when `AuthorizedKeysFile` mixes `none` with real paths (which OpenSSH's current development code rejects, so a future upgrade may stop `sshd` starting)
+- `--json` output for fleet rollups; `-v/--verbose` to list every key including clean ones; `--skip-host`, `--skip-authorized`, `--skip-private`, `--min-rsa-bits`, `--debug`, `--version`; and the opt-in modification-time thresholds `--authorized-keys-unchanged-for`, `--authorized-keys-changed-within` and `--host-keys-changed-within`
+- The date each key file was last modified, on each host key, `authorized_keys` file, key entry and private key heading in the text report, and as `last_modified` (`file_last_modified` on an `authorized_keys` entry) in the JSON
+- Test suite and docs
+- Every release attaches `audit-ssh-keys.py`, a copy of the tool's single source file that runs on any host with `python3` and `ssh-keygen` without installing anything and reports its version with `--version`
+- Published on PyPI as `audit-ssh-keys`; the release workflow uploads the wheel and sdist through a PyPI trusted publisher, and attaches the wheel, sdist, and standalone script to the GitHub release
+
+[0.1.0]: https://github.com/seanthegeek/audit-ssh-keys/releases/tag/v0.1.0

audit_ssh_keys-0.1.0/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Sean Whalen
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

audit_ssh_keys-0.1.0/PKG-INFO

@@ -0,0 +1,147 @@
+Metadata-Version: 2.5
+Name: audit-ssh-keys
+Version: 0.1.0
+Summary: Audit sshd host keys, every account's authorized_keys, and ~/.ssh private keys on a Linux server
+Project-URL: Homepage, https://github.com/seanthegeek/audit-ssh-keys
+Project-URL: Issues, https://github.com/seanthegeek/audit-ssh-keys/issues
+Project-URL: Changelog, https://github.com/seanthegeek/audit-ssh-keys/blob/main/CHANGELOG.md
+Author: Sean Whalen
+License-Expression: MIT
+License-File: LICENSE
+Keywords: audit,authorized_keys,host-keys,openssh,security,ssh
+Classifier: Development Status :: 4 - Beta
+Classifier: Environment :: Console
+Classifier: Intended Audience :: System Administrators
+Classifier: License :: OSI Approved :: MIT License
+Classifier: Operating System :: POSIX :: Linux
+Classifier: Programming Language :: Python :: 3
+Classifier: Programming Language :: Python :: 3 :: Only
+Classifier: Topic :: Security
+Classifier: Topic :: System :: Systems Administration
+Requires-Python: >=3.10
+Provides-Extra: dev
+Requires-Dist: pyright; extra == 'dev'
+Requires-Dist: pytest-cov; extra == 'dev'
+Requires-Dist: pytest>=8; extra == 'dev'
+Requires-Dist: ruff; extra == 'dev'
+Description-Content-Type: text/markdown
+
+# audit-ssh-keys
+
+[![CI](https://github.com/seanthegeek/audit-ssh-keys/actions/workflows/ci.yml/badge.svg)](https://github.com/seanthegeek/audit-ssh-keys/actions/workflows/ci.yml)
+[![codecov](https://codecov.io/gh/seanthegeek/audit-ssh-keys/graph/badge.svg)](https://codecov.io/gh/seanthegeek/audit-ssh-keys)
+
+Audit every SSH key on a Linux server in one pass: the server's own host keys,
+every account's `authorized_keys`, and any private keys sitting in `~/.ssh`.
+
+It reads the *effective* `sshd` configuration (via `sshd -T`) so it checks the
+files `sshd` will actually consult — including custom `AuthorizedKeysFile`
+locations and home directories outside `/home` — and tells you when `sshd` is
+sourcing keys from somewhere a file audit cannot see.
+
+```text
+$ sudo python3 audit-ssh-keys.py
+sshd config source: sshd -T
+
+=== Server configuration ===
+  [MEDIUM] PubkeyAcceptedAlgorithms accepts ssh-rsa (RSA with SHA-1 signatures)
+
+=== Host keys (3) ===
+
+/etc/ssh/ssh_host_rsa_key (last modified 2023-11-04)
+  RSA 2048-bit  SHA256:/EqCt23YD1l/qoc+0D2kBP6H6jCo3An+wBUshL+LFPY
+  [MEDIUM] RSA 2048-bit is below policy minimum of 3072
+...
+=== authorized_keys (3 file(s), 6 key(s)) ===
+
+svc-backup: /var/lib/svc-backup/.ssh/authorized_keys (2 key(s), last modified 2026-02-17)
+  [HIGH] /var/lib/svc-backup/.ssh/authorized_keys is owned by mallory, not svc-backup or root
+...
+Totals: CRITICAL: 1  HIGH: 3  MEDIUM: 5  LOW: 1  INFO: 2
+```
+
+## Run it
+
+The tool is one Python file. It needs nothing but Python 3.10+ and
+`ssh-keygen` (package `openssh-client` / `openssh-clients`) — no third-party
+dependencies, and no package to install. Copy it to the server and run it as
+root. No package is installed and no key file or configuration is touched;
+the only thing a run writes is a temporary directory holding a single symlink,
+created while fingerprinting a legacy PEM or PKCS#8 private key and removed
+immediately afterwards.
+
+```bash
+curl -fsSLO https://github.com/seanthegeek/audit-ssh-keys/releases/latest/download/audit-ssh-keys.py
+scp audit-ssh-keys.py server:
+ssh server sudo python3 audit-ssh-keys.py
+```
+
+`releases/latest/download/` always fetches the newest release that is not a
+prerelease (the workflow marks any tag containing a letter as a prerelease, so
+`latest` never hands out one of those). To pin a specific version, use
+`https://github.com/seanthegeek/audit-ssh-keys/releases/download/vX.Y.Z/audit-ssh-keys.py`
+instead. Either way, `python3 audit-ssh-keys.py --version` tells you which
+version you have — worth recording alongside any report you keep.
+
+Run it as root — other accounts' key files and the host private keys are not
+readable otherwise, and `sshd -T` needs root.
+
+```bash
+sudo python3 audit-ssh-keys.py            # human-readable report
+sudo python3 audit-ssh-keys.py -v         # list every key, not just those with findings
+sudo python3 audit-ssh-keys.py --json     # machine-readable, for pipelines and fleet rollups
+sudo python3 audit-ssh-keys.py --authorized-keys-changed-within 7   # flag authorized_keys files modified in the last 7 days
+```
+
+## Install
+
+For a machine you administer, rather than one you're investigating, installing
+from PyPI gets you an `audit-ssh-keys` command that takes exactly the same
+options.
+
+```bash
+pipx install audit-ssh-keys
+# or, from a checkout
+pipx install .
+```
+
+Then run it as `audit-ssh-keys`, with the same options:
+
+```bash
+sudo audit-ssh-keys
+```
+
+## What it checks
+
+| Section | Checks |
+| ------- | ------ |
+| Server configuration | Weak signature algorithms still accepted (`ssh-dss`, SHA-1 `ssh-rsa`, and their certificate forms); `StrictModes no`; `PermitRootLogin yes`; password auth enabled |
+| Host keys | Algorithm and size; ownership and mode (`sshd` refuses a root-owned key with group/other permission bits; a key owned by anyone else loads regardless, which is its own problem); a `.pub` file next to the key checked against the key itself; configured-but-missing keys; passphrase-protected keys; missing Ed25519 key; optionally, keys whose file changed inside a window you name (`--host-keys-changed-within`) |
+| `authorized_keys` | Every account, every configured path; algorithm and size; what `StrictModes` would reject (the file and every directory above it, up to `$HOME` for a file inside the home directory and otherwise up to `/`, must be owned by the user or root and not group/world-writable); the same key reused across accounts; unrestricted keys on uid-0 accounts; malformed lines; optionally, files changed inside, or untouched for longer than, a window you name (`--authorized-keys-changed-within`, `--authorized-keys-unchanged-for`) |
+| Private keys in `~/.ssh` | Algorithm and size; ownership and mode; whether a passphrase is set; a `.pub` file next to the key checked against the key itself |
+
+Every host key, `authorized_keys` file and private key is also reported with
+the date it was last modified. The three `DAYS` options in the table turn
+that date into a finding; they are off unless you ask for them.
+
+Every finding has a severity (CRITICAL, HIGH, MEDIUM, LOW, INFO). See
+[docs/findings.md](docs/findings.md) for what each one means and why it has the
+severity it does.
+
+## Documentation
+
+- [Usage](docs/usage.md) — options, exit codes, JSON schema, running without installing, fleet usage
+- [Findings reference](docs/findings.md) — every finding, its severity, and remediation
+- [How it works](docs/how-it-works.md) — what is read, what is not, known gaps
+- [Development](docs/development.md) — running tests, linting, releasing
+
+## Disclaimer
+
+This tool was developed with the assistance of AI coding agents. All code has
+been reviewed and tested by a human, but you should review it yourself before
+running it on systems you care about. It only reads files and runs `ssh-keygen`
+and `sshd -T`; it never modifies keys or configuration.
+
+## License
+
+MIT — see [LICENSE](LICENSE).

audit_ssh_keys-0.1.0/README.md

@@ -0,0 +1,119 @@
+# audit-ssh-keys
+
+[![CI](https://github.com/seanthegeek/audit-ssh-keys/actions/workflows/ci.yml/badge.svg)](https://github.com/seanthegeek/audit-ssh-keys/actions/workflows/ci.yml)
+[![codecov](https://codecov.io/gh/seanthegeek/audit-ssh-keys/graph/badge.svg)](https://codecov.io/gh/seanthegeek/audit-ssh-keys)
+
+Audit every SSH key on a Linux server in one pass: the server's own host keys,
+every account's `authorized_keys`, and any private keys sitting in `~/.ssh`.
+
+It reads the *effective* `sshd` configuration (via `sshd -T`) so it checks the
+files `sshd` will actually consult — including custom `AuthorizedKeysFile`
+locations and home directories outside `/home` — and tells you when `sshd` is
+sourcing keys from somewhere a file audit cannot see.
+
+```text
+$ sudo python3 audit-ssh-keys.py
+sshd config source: sshd -T
+
+=== Server configuration ===
+  [MEDIUM] PubkeyAcceptedAlgorithms accepts ssh-rsa (RSA with SHA-1 signatures)
+
+=== Host keys (3) ===
+
+/etc/ssh/ssh_host_rsa_key (last modified 2023-11-04)
+  RSA 2048-bit  SHA256:/EqCt23YD1l/qoc+0D2kBP6H6jCo3An+wBUshL+LFPY
+  [MEDIUM] RSA 2048-bit is below policy minimum of 3072
+...
+=== authorized_keys (3 file(s), 6 key(s)) ===
+
+svc-backup: /var/lib/svc-backup/.ssh/authorized_keys (2 key(s), last modified 2026-02-17)
+  [HIGH] /var/lib/svc-backup/.ssh/authorized_keys is owned by mallory, not svc-backup or root
+...
+Totals: CRITICAL: 1  HIGH: 3  MEDIUM: 5  LOW: 1  INFO: 2
+```
+
+## Run it
+
+The tool is one Python file. It needs nothing but Python 3.10+ and
+`ssh-keygen` (package `openssh-client` / `openssh-clients`) — no third-party
+dependencies, and no package to install. Copy it to the server and run it as
+root. No package is installed and no key file or configuration is touched;
+the only thing a run writes is a temporary directory holding a single symlink,
+created while fingerprinting a legacy PEM or PKCS#8 private key and removed
+immediately afterwards.
+
+```bash
+curl -fsSLO https://github.com/seanthegeek/audit-ssh-keys/releases/latest/download/audit-ssh-keys.py
+scp audit-ssh-keys.py server:
+ssh server sudo python3 audit-ssh-keys.py
+```
+
+`releases/latest/download/` always fetches the newest release that is not a
+prerelease (the workflow marks any tag containing a letter as a prerelease, so
+`latest` never hands out one of those). To pin a specific version, use
+`https://github.com/seanthegeek/audit-ssh-keys/releases/download/vX.Y.Z/audit-ssh-keys.py`
+instead. Either way, `python3 audit-ssh-keys.py --version` tells you which
+version you have — worth recording alongside any report you keep.
+
+Run it as root — other accounts' key files and the host private keys are not
+readable otherwise, and `sshd -T` needs root.
+
+```bash
+sudo python3 audit-ssh-keys.py            # human-readable report
+sudo python3 audit-ssh-keys.py -v         # list every key, not just those with findings
+sudo python3 audit-ssh-keys.py --json     # machine-readable, for pipelines and fleet rollups
+sudo python3 audit-ssh-keys.py --authorized-keys-changed-within 7   # flag authorized_keys files modified in the last 7 days
+```
+
+## Install
+
+For a machine you administer, rather than one you're investigating, installing
+from PyPI gets you an `audit-ssh-keys` command that takes exactly the same
+options.
+
+```bash
+pipx install audit-ssh-keys
+# or, from a checkout
+pipx install .
+```
+
+Then run it as `audit-ssh-keys`, with the same options:
+
+```bash
+sudo audit-ssh-keys
+```
+
+## What it checks
+
+| Section | Checks |
+| ------- | ------ |
+| Server configuration | Weak signature algorithms still accepted (`ssh-dss`, SHA-1 `ssh-rsa`, and their certificate forms); `StrictModes no`; `PermitRootLogin yes`; password auth enabled |
+| Host keys | Algorithm and size; ownership and mode (`sshd` refuses a root-owned key with group/other permission bits; a key owned by anyone else loads regardless, which is its own problem); a `.pub` file next to the key checked against the key itself; configured-but-missing keys; passphrase-protected keys; missing Ed25519 key; optionally, keys whose file changed inside a window you name (`--host-keys-changed-within`) |
+| `authorized_keys` | Every account, every configured path; algorithm and size; what `StrictModes` would reject (the file and every directory above it, up to `$HOME` for a file inside the home directory and otherwise up to `/`, must be owned by the user or root and not group/world-writable); the same key reused across accounts; unrestricted keys on uid-0 accounts; malformed lines; optionally, files changed inside, or untouched for longer than, a window you name (`--authorized-keys-changed-within`, `--authorized-keys-unchanged-for`) |
+| Private keys in `~/.ssh` | Algorithm and size; ownership and mode; whether a passphrase is set; a `.pub` file next to the key checked against the key itself |
+
+Every host key, `authorized_keys` file and private key is also reported with
+the date it was last modified. The three `DAYS` options in the table turn
+that date into a finding; they are off unless you ask for them.
+
+Every finding has a severity (CRITICAL, HIGH, MEDIUM, LOW, INFO). See
+[docs/findings.md](docs/findings.md) for what each one means and why it has the
+severity it does.
+
+## Documentation
+
+- [Usage](docs/usage.md) — options, exit codes, JSON schema, running without installing, fleet usage
+- [Findings reference](docs/findings.md) — every finding, its severity, and remediation
+- [How it works](docs/how-it-works.md) — what is read, what is not, known gaps
+- [Development](docs/development.md) — running tests, linting, releasing
+
+## Disclaimer
+
+This tool was developed with the assistance of AI coding agents. All code has
+been reviewed and tested by a human, but you should review it yourself before
+running it on systems you care about. It only reads files and runs `ssh-keygen`
+and `sshd -T`; it never modifies keys or configuration.
+
+## License
+
+MIT — see [LICENSE](LICENSE).

audit_ssh_keys-0.1.0/docs/development.md

@@ -0,0 +1,130 @@
+# Development
+
+```bash
+git clone https://github.com/seanthegeek/audit-ssh-keys
+cd audit-ssh-keys
+python3 -m venv .venv && . .venv/bin/activate
+pip install -e ".[dev]"
+```
+
+## Checks
+
+Run exactly these, from the repo root, before opening a PR:
+
+```bash
+ruff check .
+ruff format --check .
+pyright
+pytest
+```
+
+`ruff format .` fixes formatting in place.
+
+CI (`.github/workflows/ci.yml`) runs the first three commands unchanged, and
+`pytest` with coverage (`pytest --cov=audit_ssh_keys --cov-report=term-missing
+--cov-report=xml`) on Python 3.10 through 3.14, on every pull request and every
+push to `main`. It also lints Markdown and runs the root-only tests under
+`sudo` in a separate job. The release workflow runs the four commands exactly
+as written above.
+
+## Tests
+
+- Tests generate real keys with `ssh-keygen` into `tmp_path`; nothing key-shaped is committed. Tests that need `ssh-keygen` are skipped if it is not installed.
+- Audit functions take an explicit list of `pwd.struct_passwd` entries (`users=`) and explicit config paths / `sshd` binary, so tests build fake accounts under `tmp_path` and never touch the real system.
+- A few ownership tests need root (`chown`) and are skipped otherwise; run them locally with `sudo -E pytest` if you touch ownership logic.
+- The test uid helper `USER_UID` is `os.getuid()` or `1000` when running as root, because files the suite creates are owned by the real uid and `sshd` accepts root-owned files for any account.
+
+## Layout
+
+```text
+src/audit_ssh_keys/
+  __init__.py   re-exports __version__ from audit.py
+  __main__.py   python -m entry point
+  audit.py      everything else, including __version__, in sections: config,
+                ssh-keygen helpers, parsing, grading, the three audit
+                sections, output, CLI
+tests/
+  conftest.py   key-generation and fake-passwd fixtures
+  test_parsing.py   pure functions (no filesystem, no ssh-keygen)
+  test_config.py    sshd config reading and server-setting grading
+  test_audit.py     permission checks and the three audit sections
+docs/
+```
+
+## Releasing
+
+1. Add a `## [X.Y.Z] - YYYY-MM-DD` heading to `CHANGELOG.md` above the
+   previous release's, brackets included — that is Keep a Changelog's form, and
+   the release workflow greps for exactly `## [X.Y.Z]` and stops if it is
+   missing — and list the changes under it. Add the matching
+   `[X.Y.Z]: https://github.com/seanthegeek/audit-ssh-keys/releases/tag/vX.Y.Z`
+   link definition at the end of the file.
+2. Bump `__version__` in `src/audit_ssh_keys/audit.py`, just after the imports.
+3. Commit, then tag and push:
+
+   ```bash
+   git tag vX.Y.Z
+   git push origin vX.Y.Z
+   ```
+
+Pushing the tag runs the release workflow
+(`.github/workflows/release.yml`), which checks the tag against
+`__version__` and the changelog heading, runs the checks, builds the wheel and
+sdist, checks that `dist/` holds exactly one of each, uploads both to PyPI,
+copies `audit.py` into `dist/` as `audit-ssh-keys.py`, checks that copy is
+byte-identical to the module and that `python -S dist/audit-ssh-keys.py
+--version` reports the tag's version, and creates the GitHub release titled
+without the `v` with all three files attached.
+
+### If the workflow fails after the PyPI upload
+
+Only the steps after the upload can be redone by hand, and the section below
+says how to tell which side of it a failure landed on. A failure before or
+during the upload is fixed by fixing the cause and re-running the job — there
+is no manual upload path.
+
+Everything after the upload is three steps: copying the standalone script,
+checking that copy, and creating the GitHub release. By hand you need only the
+first and last — the check exists to catch a copy that the workflow made
+wrongly, and a `cp` you run yourself from the same checkout cannot fail that
+way. Build the wheel and sdist locally:
+
+```bash
+uvx hatch build
+```
+
+(or `python -m build`). Both land in `dist/`. Then copy the standalone script
+alongside them and create the release, attaching all three files:
+
+```bash
+cp src/audit_ssh_keys/audit.py dist/audit-ssh-keys.py
+gh release create vX.Y.Z --title X.Y.Z --generate-notes dist/*
+```
+
+The title has no `v` prefix, per this repo's release rules, even though the tag does.
+
+### How PyPI publishing works
+
+PyPI is published through a trusted publisher, so no API token is stored
+anywhere: the project is registered on pypi.org against this repository and the
+`release.yml` workflow file, and the job's OIDC token is what proves who it is.
+That registration names no environment, so the release job must not declare one
+— PyPI rejects the token if the two disagree.
+
+The upload runs before the GitHub release is created, because PyPI never
+accepts the same version twice, and a GitHub release can be made by hand while
+an upload cannot.
+
+If the upload fails, fix the cause and re-run the failed job from the Actions
+tab, leaving the tag where it is. The wheel and the sdist go up as two separate
+files, so a failure part way through can leave one of them on PyPI; the step
+runs with `skip-existing`, so the re-run uploads whichever file is still
+missing instead of stopping at the one already there. Check the project's
+release page on PyPI afterwards to confirm both files are present. If the
+upload succeeded and a later step failed, PyPI already has the files and only
+the standalone script copy and the GitHub release still need doing, by hand as
+above.
+
+There is no manual upload path — that is why the by-hand steps above stop at
+the GitHub release. A release whose files have to change gets a new version
+number.

audit_ssh_keys-0.1.0/docs/findings.md

@@ -0,0 +1,90 @@
+# Findings reference
+
+Every finding has a severity. The scale is about *what an attacker gets* or *what silently stops working*, not about how hard the fix is.
+
+| Severity | Meaning |
+| -------- | ------- |
+| CRITICAL | Broken cryptography or key material readable by anyone on the box |
+| HIGH | Something `sshd` itself refuses, or that lets another local account inject or use a key |
+| MEDIUM | Below current policy but not broken today |
+| LOW | Hygiene, or something the tool could not fully check |
+| INFO | Worth knowing; no action required by default |
+
+## Server configuration
+
+| Finding | Severity | Why | Fix |
+| ------- | -------- | --- | --- |
+| `*Algorithms accepts ssh-dss` | MEDIUM | DSA signatures; 1024-bit only, removed from OpenSSH defaults | Remove `ssh-dss` from `HostKeyAlgorithms` / `PubkeyAcceptedAlgorithms` / `CASignatureAlgorithms` |
+| `*Algorithms accepts ssh-rsa` | MEDIUM | `ssh-rsa` is RSA with SHA-1 signatures (the key itself is fine; the signature scheme is not). Disabled by default since OpenSSH 8.8 | Remove `ssh-rsa`; RSA keys keep working via `rsa-sha2-256`/`rsa-sha2-512` |
+| `StrictModes is 'no'` | MEDIUM | `sshd` will read key files another account can write to | Set `StrictModes yes` and fix whatever permission problem prompted turning it off |
+| `PermitRootLogin is 'yes'` | MEDIUM | Permits password-based login as root when `PasswordAuthentication` is enabled | `PermitRootLogin prohibit-password` (or `no`) |
+| `PasswordAuthentication is 'yes'` | INFO | Keys are not the only way in | Consider `PasswordAuthentication no` once all users have keys |
+
+Algorithm checks only run when `sshd -T` succeeds, because only it prints the fully expanded effective lists.
+
+## Host keys
+
+| Finding | Severity | Why | Fix |
+| ------- | -------- | --- | --- |
+| `RSA N-bit is below 2048` | CRITICAL | Factoring risk | `ssh-keygen -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key`; clients will see a host-key change |
+| `DSA key` | HIGH | Deprecated; modern clients will not accept it | Delete the key and its `HostKey` line |
+| `RSA N-bit is below policy minimum` | MEDIUM | Below `--min-rsa-bits` | Regenerate at 3072+ or 4096 |
+| `world-accessible private key` | CRITICAL | Any local user can read the server's identity key and impersonate the host. When root owns the file `sshd` refuses to load it as well ("UNPROTECTED PRIVATE KEY FILE") | `chmod 600` |
+| `group-accessible private key` | HIGH | The group can read the server's identity key, and replace it if the directory allows. When root owns the file `sshd` refuses to load it too; when another account owns it, `sshd` loads it whatever its mode says, because `sshkey_perm_ok()` only looks at the mode of a file owned by the account `sshd` runs as | `chmod 600` |
+| `group/other bits set but not readable by them` | LOW | The mode has a group or other write or execute bit but no read bit, so nobody else can read the key; when root owns the file `sshd` still refuses to load it, because `sshkey_perm_ok()` refuses any group/other bit, not just a read one, and a write bit lets that group or anyone replace the file with one `sshd` refuses just the same | `chmod 600` |
+| `modified within the last N days` | MEDIUM | Only reported when `--host-keys-changed-within N` is given. The file a `HostKey` line names changed inside that window — the private key `sshd` loads, or a public key or certificate file a `HostKey` line names by mistake (each already has a finding of its own above) — which is either a rotation somebody carried out or the first sign that somebody else replaced the server's identity — the audit cannot tell those apart, so it asks. Clients that have the old key saved in `known_hosts` normally refuse to connect until it is updated, so a genuine rotation is rarely silent. The window is measured against the file's own modification time, so anything that rewrites the file — a configuration-management run, a restore from backup, `cp` without `-p` — starts it again even when the key inside is the same one | Find out who changed the file and why; compare the fingerprint `ssh-keygen -lf <key>` prints now against the one recorded for this host before the change |
+| `owned by X, expected root` | HIGH | `sshd` runs as root, so it loads the key anyway — the problem is that account X can read the host's identity key and replace it with one of its own | `chown root:root` |
+| `public key file; the private half is held by HostKeyAgent` | INFO | The `HostKey` names a public key file and `HostKeyAgent` is set, which is how `sshd` is told which agent-held key to serve. It is graded like any other host key, but the private half is not on disk, so its permissions, its passphrase, and any `.pub` file beside it cannot be checked here | Nothing to fix on the host; audit the agent's own key store |
+| `HostKey names a public key file and no HostKeyAgent is set` | LOW | `sshd` can load no private key from the file, so the entry grants the host nothing: it logs `Unable to load host key` and, with no other key configured, exits with `no hostkeys available`. The key's type is not counted among the ones the host can offer, and its algorithm and size are not graded either — `sshd` never offers this key to anyone, so nothing about it is reachable | Point `HostKey` at the private key file (drop the `.pub`), or set `HostKeyAgent` |
+| `HostKey names a certificate file` | LOW | A certificate is not a host key `sshd` can load, so the entry grants the host nothing. `sshd` only falls back to the agent for a plain key type, so this fails even with `HostKeyAgent` set and the agent holding both the key and its certificate — verified against OpenSSH 10.2, which logs `Unable to load host key` and exits with `no hostkeys available`. As with a public key file and no agent, the key's type is not counted among the ones the host can offer and its algorithm and size are not graded | Point `HostKey` at the private key file and name the certificate on a `HostCertificate` line instead |
+| `HostKey is set to none and no other HostKey is configured` | LOW | `none` is a sentinel `sshd` keeps as an empty host-key entry rather than the name of a file (`sshd -T` prints it as `hostkey (null)`), so there is no file to audit — and with nothing else configured `sshd` has no key to offer at all: it exits with `no hostkeys available -- exiting`, verified against OpenSSH 10.2 | Remove the `HostKey none` line, or configure a real one (`ssh-keygen -A`) |
+| `no host key exists at any default path` | LOW | No `HostKey` is configured and none of the default files exist, so `sshd` has nothing to offer and exits with `no hostkeys available -- exiting` (verified against OpenSSH 10.2). The audit only says this when it could stat every default path | `ssh-keygen -A` |
+| `configured HostKey does not exist` | LOW | `sshd` logs an error at start; harmless if another key is present | Remove the line or `ssh-keygen -A` |
+| `could not stat host key` | LOW | The tool could not even tell whether the file is there — for example, permission denied on a directory above it, which happens when the tool is not running as root. Different from a configured key that is confirmed absent, which has its own row above | Run as root, or fix the directory permissions |
+| `host key is passphrase-protected` | LOW | `sshd` cannot load it at boot | Regenerate without a passphrase |
+| `<name>.pub does not match this private key` | LOW | The public file next to the key is stale or belongs to a different key, so anything copied out of it — into an `authorized_keys` file, a config-management repo, a `known_hosts` entry — authorises the wrong key | Regenerate it: `ssh-keygen -y -f <key> > <key>.pub` |
+| `no Ed25519 host key present` | LOW | Ed25519 is the current best-practice host key. The note only appears when every configured host key that is there could be fingerprinted: a key the audit could not stat or could not read has an unknown type, and the host may well already have the Ed25519 key this note would tell you to generate — which is what a non-root run meets on every root-owned host key | `ssh-keygen -A` |
+| `could not fingerprint host key` | LOW | The key could not be fingerprinted: a passphrase-protected key in the old PEM format with no `.pub` file, a key file the tool cannot read at all (a root-owned host key on a non-root run, where the `.pub` file beside it is not used either, since nothing says it describes this key), an empty file or one holding something that is not a private key at all (for either of those two the `.pub` file beside it is not used either, for the same reason), a private key file bigger than 1 MiB, which the audit stops at (the limit is on reading a private key file, so a `HostKey` naming a public key file is fingerprinted whatever its size; and the limit is this tool's own and not one `ssh` applies: `sshd` loads such a file perfectly well, so the finding says only that the audit did not read it, and the `.pub` file beside it gets no say for such a file either), a corrupt or truncated key body in the current OpenSSH format (reported this way even when a `.pub` file is present, since a corrupt file says nothing about which key it was), or a current-format key whose private half `ssh`'s own loader cannot load — mismatched check integers, private fields that do not deserialize, bad padding, or a body mangled in transit (CRLF line endings, indentation). Its algorithm and size were not graded. Its ownership and permissions are still checked and reported normally, because those come from `stat` and do not need the file's contents; whether a passphrase is set is only known when the file could be read, so nothing is reported about that for a file the tool could not read | Run the audit as root if it could not read the file; write the public file (`ssh-keygen -y -f <key> > <key>.pub`) or convert the key to the current format with `ssh-keygen -p -o -f <key>`; for a current-format key `ssh` itself cannot load, regenerate the key (delete the file and run `ssh-keygen -A`) and expect every client to see a changed host key; for a file over 1 MiB, look at what it actually holds, because a real host key is a few kilobytes |
+
+## authorized_keys — file level
+
+| Finding | Severity | Why | Fix |
+| ------- | -------- | --- | --- |
+| `<file/dir/home> is group/world-writable` | HIGH | With `StrictModes yes` (default) `sshd` ignores the file and the account's keys silently stop working. With `StrictModes no` another account can add keys | `chmod g-w,o-w` on the offending path |
+| `<path> is owned by X, not <user> or root` | HIGH | Same as above; `sshd` requires the user or root to own the whole path | `chown` |
+| `line N: unparseable entry` | LOW | `sshd` reads no key from the line and skips it. Usually a corrupted paste. Also a line copied out of a `known_hosts` file, where a host name, a host pattern, or an `@cert-authority` or `@revoked` marker sits where the key type belongs: `ssh-keygen -l` accepts `known_hosts` lines and `sshd` does not, so the key material is held to `sshd`'s own test before it is fingerprinted. Most `known_hosts` lines are reported by the row below instead, because the host field parses as an option name and is then turned down as an option `sshd` does not know — `somehost <key>`, `*.example.com <key>`, `192.0.2.1,host <key>`, a hashed `\|1\|salt\|hash <key>` and a bare `@cert-authority <key>` or `@revoked <key>` with no host pattern all land there. Two shapes land here instead: a marker line, `@cert-authority <pattern> <key>` or `@revoked <pattern> <key>`, where the marker is read as the options and the host pattern is then where the key type should be; and a `known_hosts` line with anything at all in front of it that reads as options, such as `no-pty somehost <key>` or `bogusopt somehost <key>`. Neither gets an options finding, and neither does `sshd`: `auth_check_authkey_line()` (`auth2-pubkeyfile.c`) jumps to the end of the line when the second `sshkey_read()` fails, without calling `sshauthopt_parse()` at all | Remove or re-add the key |
+| `line N: bad key options (...)` | LOW | `sshd` refuses the whole line when its options do not parse, so the key on it grants nothing while the file still reads as if it authorised someone. Usually a typo in an option name, or a `known_hosts` line whose leading host field is read as one (see the row above for which shapes go where). One shape is reported here that `sshd` says nothing about: a line that is a single unknown word and no key, such as `garbage`. `sshd` ignores it silently, because `sshkey_advance_past_options()` fails only on an unterminated quote, so the options on such a line are never parsed. Naming the unknown option is more useful to whoever has to fix the file, and both answers say the line grants nothing | Correct the option; the `AUTHORIZED_KEYS FILE FORMAT` section of `sshd(8)` lists every option `sshd` accepts |
+| `line N: longer than 65536 characters, so it was not read` | LOW | The audit reads a line only as far as 65536 characters and winds past the rest of it. `sshd` applies no such limit — `auth_check_authkeys_file()` (`auth2-pubkeyfile.c`) reads the file with `getline()`, which grows its buffer to whatever the line needs — so this is a deliberate divergence, and one of the few places the report is less complete than `sshd` rather than more cautious than it: the line may hold a key that works, and it is neither graded nor entered in the check for keys reused across accounts. The limit is there because `sshd` reads one account's file in a process serving one connection while this tool reads every account's files in a single root process, and a file that is one enormous line costs the account that owns it a handful of disk blocks (`truncate -s 3G ~/.ssh/authorized_keys`), which used to end the audit for every account after that one. The rest of the file is still read, and every line number in the report is still the one an editor shows. A line over the limit does not stop the file getting `not modified in N days`, unlike a read that failed: the file was read from end to end, one line of it was skipped rather than lost, and that line has this finding of its own sitting beside it. Nothing written on purpose comes close to the limit: a 16384-bit RSA key is about 2.8 KB of base64 | Look at the line; if it is a real key it will fit, so shorten or remove whatever is there |
+| `modified within the last N days` | MEDIUM | Only reported when `--authorized-keys-changed-within N` is given. The file changed inside that window: a key added or removed, or the whole file rewritten. That is either an edit somebody made on purpose or exactly what the option was switched on to catch. It is reported whether or not the file still holds any keys, because emptying a file out is a change like any other, and it is reported for a file the tool cannot read as well, since the window is decided from the file's modification time alone. Anything that rewrites the file — a configuration-management run, a restore from backup, `cp` without `-p` — starts the window again even when the lines in it are unchanged | Find out who changed the file and why, and check the keys in it against the people who should have access |
+| `not modified in N days` | LOW | Only reported when `--authorized-keys-unchanged-for N` is given, and only for a file holding at least one key line `sshd` would parse — a file of comments, a file holding nothing but certificate lines (which authorise nobody), a file the tool could not read, and a file the tool could not read to the end (a read that failed partway, or a close that failed after it) all say nothing about whose access is old — for the last of those, the keys the audit did read say nothing about the ones it did not. Whether a line's `expiry-time=` has passed is not evaluated, the same as in every other check here. The finding is about the file: it has gone that long without a change, so nothing in it was added more recently unless its modification time was set by hand, which is the limit of any check built on that time. It says how long the file has gone unchanged, not whether anybody has looked at it: a review that changes nothing leaves the modification time where it was | Check each key in the file against the people and systems that should still have access, and remove the ones that should not |
+| `could not resolve` / `could not stat` / `could not read` / `could not close` | LOW | Tool could not check it. This is what a non-root run reports for another account's files it cannot even stat, rather than silently treating them as absent. `could not read` also covers a read that failed partway through a file — a failing disk, a network filesystem going away — which leaves the lines read before it reported and the rest of the file unread; `could not close` is that same failure arriving as the file is closed, after every line has been read. Neither ends the audit of the accounts that follow | Run as root; a read that fails partway, or a close that fails at all, points at the filesystem rather than at permissions |
+
+The tool follows any symbolic links, then checks the file and every directory above it, stopping once it has checked the home directory if the file is inside it and otherwise carrying on up to `/`. That is the same walk `sshd`'s `safe_path()` does, which is why an `authorized_keys` file placed outside the home under a world-writable directory such as `/tmp` is rejected outright. Only *write* bits for group/other matter: mode 644 on `authorized_keys` or 755 on `~/.ssh` is accepted by `sshd` and is not flagged.
+
+## authorized_keys — key level
+
+| Finding | Severity | Why | Fix |
+| ------- | -------- | --- | --- |
+| `RSA N-bit is below 2048` | CRITICAL | Factoring risk | Replace with Ed25519 or RSA 4096 |
+| `DSA key` | HIGH | Deprecated; cannot log in on modern `sshd` anyway | Remove |
+| `SSH-1 RSA key` | CRITICAL | Protocol 1, long removed | Remove |
+| `RSA N-bit is below policy minimum` | MEDIUM | Below `--min-rsa-bits` | Rotate |
+| `same key also authorized at: ...` | MEDIUM | One compromised private key opens every listed account; also a sign of shared or copied keys | One key per (person, purpose); remove the extras |
+| `same key also listed for this account at: ...` | LOW | The same key twice for one account grants no extra access, but an admin who deletes one entry believes the key is revoked while the other one still admits it | Keep a single entry per key |
+| `certificate listed in authorized_keys` | INFO | `sshd` matches a plain key against the line itself and a certificate against a `cert-authority` line holding the CA's plain key; a certificate blob matches neither, so the line is dead weight that looks like an authorisation. It is also left out of the check for keys reused across accounts, because `ssh-keygen -l` reports a certificate under the fingerprint of the key it certifies, which would otherwise make that key look reused | Remove it; to trust the CA, add its plain public key with the `cert-authority` option |
+| `uid-0 account key has no from= or command= restriction` | INFO | Unrestricted root key. Common, but a `from=` or `command=` option limits blast radius | Add options where the use case allows |
+
+## Private keys in ~/.ssh
+
+| Finding | Severity | Why | Fix |
+| ------- | -------- | --- | --- |
+| `world-accessible private key` | CRITICAL | Any local user can copy it | `chmod 600` |
+| `group-accessible private key` | HIGH | Group members can copy it | `chmod 600` |
+| `group/other bits set but not readable by them` | LOW | Nobody else can read the key, but `ssh` refuses to load it for its owner ("UNPROTECTED PRIVATE KEY FILE") because `sshkey_perm_ok()` rejects any group/other bit | `chmod 600` |
+| `owned by X, expected <user> or root` | HIGH | Someone else's key in this account's directory, or a copied home | Investigate |
+| `private key has no passphrase` (root) | HIGH | A root-owned key that is one file read away from use elsewhere | Add a passphrase (`ssh-keygen -p`) or move to an agent / hardware key |
+| `private key has no passphrase` (other) | MEDIUM | Same, smaller blast radius. Automation keys are often legitimately passphrase-less; pair them with `from=`/`command=` on the receiving side | Same |
+| `RSA N-bit ...`, `DSA key` | as above | | Rotate |
+| `could not determine whether the key is passphrase-protected` | LOW | Unrecognised file format, an OpenSSH-format key cut short before its closing line, which leaves no way to trust anything read out of it, a key file bigger than the 1 MiB the audit reads (`ssh` loads a far larger file than that, so this says the audit did not look, not that the key is unusable), or a key file holding a byte that is not ASCII (a private-key file is ASCII from end to end, so such a file is corrupt) | Inspect manually |
+| `<name>.pub does not match this private key` | LOW | The public file next to the key is stale or belongs to a different key, so anything copied out of it — for example into an `authorized_keys` file — authorises the wrong key | Regenerate it: `ssh-keygen -y -f <key> > <key>.pub` |
+| `could not fingerprint private key` | LOW | The key could not be fingerprinted: a passphrase-protected key in the old PEM format with no `.pub` file, a PEM key with no `.pub` that is owned by the account running the tool with any group or other permission bits set (`ssh-keygen` refuses to open such a key), a file bigger than 1 MiB, which the audit stops at (that limit is the audit's own and not one `ssh` applies: `ssh` loads such a file without trouble, so the finding says only that the audit did not read it), a corrupt or truncated key body in the current OpenSSH format (reported this way even when a `.pub` file is present, since a corrupt file says nothing about which key it was), or a current-format key whose private half `ssh`'s own loader cannot load — mismatched check integers, private fields that do not deserialize, bad padding, or a body mangled in transit (CRLF line endings, indentation). Its algorithm and size were not graded | Fix the permissions if that is the cause; otherwise write the public file (`ssh-keygen -y -f <key> > <key>.pub`) or convert the key to the current format with `ssh-keygen -p -o -f <key>`; for a current-format key `ssh` itself cannot load, regenerate the key and replace it everywhere it is authorised; for a file over 1 MiB, look at what it actually holds, because a real private key is a few kilobytes |