Skip to main content

max / alloy

2.7 KB · 50 lines History Blame Raw
1 # Alloy sshd policy: a key, for every account, always.
2 #
3 # sshd is enabled on every Alloy install (see
4 # etc/systemd/system-preset/50-alloy.preset). fedora-bootc:43 leaves
5 # `PasswordAuthentication yes`, which means the account the installer creates is
6 # reachable by password from anywhere that can route to the machine. Root was
7 # already key-only there; nothing covered uid 1000. This file closes that, and
8 # states the rule rather than leaving it to a built-in default: a valid public
9 # key is required for any account, root included.
10 #
11 # Read before Fedora's own drop-ins. `/etc/ssh/sshd_config` puts its
12 # `Include /etc/ssh/sshd_config.d/*.conf` at line 15, ahead of every keyword it
13 # sets, and sshd takes the FIRST value it obtains for a keyword rather than the
14 # last. So the number is what makes this authoritative, and lowering it is the
15 # way to override, not raising it. Neither 40-redhat-crypto-policies.conf nor
16 # 50-redhat.conf sets these three today, so this wins on merit as well as on
17 # order, but the ordering is the part that keeps being true when they change.
18
19 # The rule. `no` rather than relying on a default, because the default is
20 # whatever the base ships and the base shipped `yes`.
21 PasswordAuthentication no
22
23 # The other password door. PAM's keyboard-interactive stack can authenticate a
24 # password even with PasswordAuthentication off, so turning off one without the
25 # other leaves the rule half-applied. 50-redhat.conf already sets this; it is
26 # repeated here so the policy is legible in one file instead of depending on a
27 # neighbour that Alloy does not own.
28 KbdInteractiveAuthentication no
29
30 # Root: key or nothing. This matches what fedora-bootc already had in effect
31 # (`without-password`, the older spelling of the same thing), written in the
32 # current spelling and stated rather than inherited.
33 PermitRootLogin prohibit-password
34
35 # WHAT THIS COSTS, said plainly. On a desktop install nothing: greetd is on the
36 # console, so a user who has not planted a key logs in locally and adds one.
37 #
38 # On a HEADLESS install it would be a lockout, and the other half of the
39 # decision is what stops it being one. `alloy install` collects a public key on
40 # its account step and writes it to the new user's authorized_keys, and on a
41 # minted medium that field arrives already filled from
42 # /usr/lib/alloy/authorized_keys, which is the key the operator is connected
43 # with. So the headless path never reaches this file empty-handed.
44 #
45 # An install that ends with no key is still possible, and it is a real answer
46 # rather than an oversight: a desktop, with a person at the console. The
47 # installer says so on its summary and again on the gate before the disk is
48 # written, because from the far side of a reboot there is no way to tell that
49 # machine from a broken one.
50