Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
[Security] omarchy setup security sshd leaves password authentication on, and opens the port before any key is authorized
Reported by Chessing234 · filed Aug 26, 2026 · open at source
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- AreaOutside the audited area· Decided by agents · verified
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Decided by agents and verified by a second, independent agent — see the decision.
Original report
omarchy setup security sshd prints "Setting up SSH server access with key-based authentication", and then starts sshd with the distribution defaults — which accept passwords.
Password authentication is never turned off
Nothing in the repo writes to sshd_config:
$ grep -rn "PasswordAuthentication\|PermitRootLogin\|sshd_config" bin install migrations default etc
$OpenSSH's own compiled-in default is PasswordAuthentication yes. Arch ships /etc/ssh/sshd_config.d/99-archlinux.conf, and it does not change that — it only sets:
KbdInteractiveAuthentication no
UsePAM yes
PrintMotd noSo after the command finishes, the machine accepts SSH password logins for every local account, from whatever network it is attached to. ufw limit 22/tcp rate-limits a single source IP; it does not stop a distributed attempt, and it does nothing about a weak or reused login password — which on a personal desktop is common, and which Omarchy also lets you retry ten times at the sudo prompt (etc/sudoers.d/omarchy-passwd-tries).
A command whose entire purpose is to authorize a public key should not leave password authentication reachable.
The port opens before the key exists
setup_sshd # omarchy-pkg-add openssh; systemctl enable --now sshd.service
open_firewall # ufw limit 22/tcp
echo
if [[ -n $KEY ]]; then
authorize_key "$KEY" || exit 1
...The server is enabled and the firewall opened first. Every way the key step can fail happens after that:
gum choose/gum inputcancelled —|| exit 1- a pasted key that
ssh-keygen -lfrejects —authorize_key ... || exit 1 --gh-keysfor a user with no public keys —exit 1
Each leaves a listening, network-reachable sshd with password authentication on and no authorized key at all, and says nothing about it. The set -e at the top means an unexpected failure anywhere in between does the same.
Reproduce
$ omarchy setup security sshd
(choose "Paste key manually", then press Esc)
$ systemctl is-enabled sshd
enabled
$ sudo sshd -T | grep -i passwordauthentication
passwordauthentication yes
$ ls ~/.ssh/authorized_keys
ls: cannot access '/home/you/.ssh/authorized_keys': No such file or directoryExpected
Password (and keyboard-interactive) authentication off, and nothing listening or opened until a key has actually been authorized.
Related but separate: #8248 asks about which interfaces sshd binds to. This one is about how it authenticates and when it starts.
View raw text
`omarchy setup security sshd` prints "Setting up SSH server access with key-based authentication", and then starts sshd with the distribution defaults — which accept passwords. ## Password authentication is never turned off Nothing in the repo writes to `sshd_config`: ``` $ grep -rn "PasswordAuthentication\|PermitRootLogin\|sshd_config" bin install migrations default etc $ ``` OpenSSH's own compiled-in default is `PasswordAuthentication yes`. Arch ships `/etc/ssh/sshd_config.d/99-archlinux.conf`, and it does not change that — it only sets: ``` KbdInteractiveAuthentication no UsePAM yes PrintMotd no ``` So after the command finishes, the machine accepts SSH password logins for every local account, from whatever network it is attached to. `ufw limit 22/tcp` rate-limits a single source IP; it does not stop a distributed attempt, and it does nothing about a weak or reused login password — which on a personal desktop is common, and which Omarchy also lets you retry ten times at the sudo prompt (`etc/sudoers.d/omarchy-passwd-tries`). A command whose entire purpose is to authorize a public key should not leave password authentication reachable. ## The port opens before the key exists ```bash setup_sshd # omarchy-pkg-add openssh; systemctl enable --now sshd.service open_firewall # ufw limit 22/tcp echo if [[ -n $KEY ]]; then authorize_key "$KEY" || exit 1 ... ``` The server is enabled and the firewall opened *first*. Every way the key step can fail happens after that: - `gum choose` / `gum input` cancelled — `|| exit 1` - a pasted key that `ssh-keygen -lf` rejects — `authorize_key ... || exit 1` - `--gh-keys` for a user with no public keys — `exit 1` Each leaves a listening, network-reachable sshd with password authentication on and **no authorized key at all**, and says nothing about it. The `set -e` at the top means an unexpected failure anywhere in between does the same. ## Reproduce ``` $ omarchy setup security sshd (choose "Paste key manually", then press Esc) $ systemctl is-enabled sshd enabled $ sudo sshd -T | grep -i passwordauthentication passwordauthentication yes $ ls ~/.ssh/authorized_keys ls: cannot access '/home/you/.ssh/authorized_keys': No such file or directory ``` ## Expected Password (and keyboard-interactive) authentication off, and nothing listening or opened until a key has actually been authorized. Related but separate: #8248 asks about which interfaces sshd binds to. This one is about how it authenticates and when it starts.
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
- Fixed bypr/9474· confirmed
- Related PRpr/8472· confirmed
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
- Out of scopeDecided by agents · verified · 2026-10-09 09:19 UTC