Proof Portal

Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A 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.

Inbox
ReportR-1429GitHub issuePublicFixed

[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

Decided: Out of scope — decided by agents · verified 3 days ago.

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

[Security] omarchy setup security sshd leaves password authentication on, and opens the port before any key is authorizedrevision 1 · captured 2026-09-28 21:24 UTC via poll

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

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.

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