tiagoagueda/a80

Fork 0

Root password is published in a public repository #1

New issue

Closed

opened 2026-08-27 23:22:23 +00:00 by tiagoagueda · 2 comments

tiagoagueda commented

2026-08-27 23:22:23 +00:00

Owner

23-sd-boot.md line 244 documents the console root password in plain text:

root password draco for the serial console — change it

The note has said "change it" since it was written, and it has not been changed.

Why this is worse than a stale note. The repository at
source.tiagoagueda.com/tiagoagueda/a80 is public (private: false; unauthenticated
GET /api/v1/repos/tiagoagueda/a80 returns 200). And the board currently accepts password
logins as root:

permitrootlogin yes
passwordauthentication yes

So this is a working credential, not documentation. The rescue SD was cloned from the eMMC
system, so the same password very likely works on both.

Mitigating: the board is on a private LAN (192.168.27.0/24) and is not internet-facing, so
an attacker needs to be on the network first.

Done when

the password is rotated on both the eMMC system and the rescue SD
23-sd-boot.md no longer contains a real credential
password auth is disabled entirely (see the SSH hardening issue), making it moot
decide whether to rewrite history: the password is in the initial commit 204884e, so
removing it from the working tree does not remove it from the repo. Requires a force
push, so it needs an explicit decision.

`23-sd-boot.md` line 244 documents the console root password in plain text: > `root password draco` for the serial console — **change it** The note has said "change it" since it was written, and it has not been changed. **Why this is worse than a stale note.** The repository at `source.tiagoagueda.com/tiagoagueda/a80` is **public** (`private: false`; unauthenticated `GET /api/v1/repos/tiagoagueda/a80` returns 200). And the board currently accepts password logins as root: ``` permitrootlogin yes passwordauthentication yes ``` So this is a working credential, not documentation. The rescue SD was cloned from the eMMC system, so the same password very likely works on both. Mitigating: the board is on a private LAN (`192.168.27.0/24`) and is not internet-facing, so an attacker needs to be on the network first. **Done when** - [ ] the password is rotated on both the eMMC system and the rescue SD - [ ] `23-sd-boot.md` no longer contains a real credential - [ ] password auth is disabled entirely (see the SSH hardening issue), making it moot - [ ] decide whether to rewrite history: the password is in the initial commit `204884e`, so removing it from the working tree does not remove it from the repo. Requires a force push, so it needs an explicit decision.

tiagoagueda added the

security

P1-critical

labels

2026-08-27 23:22:23 +00:00

tiagoagueda commented

2026-08-29 07:52:05 +00:00

Author

Owner

Half done 2026-08-29, and the half that is done is the half that matters least.

The literal password is removed from 23-sd-boot.md and 16-ethernet-broken.md, and SSH no
longer accepts passwords at all (#2): PasswordAuthentication no, verified as
Permission denied (publickey) from a fresh session.

But the credential itself is unchanged and still works on the serial console, and it
remains in git history, so this stays open. Two commands, and only you should run them:

ssh draco@192.168.27.44
sudo passwd draco     # needed for sudo and for serial console recovery
sudo passwd root      # this is the one that retires the published credential

sudo will ask for draco's password, which does not exist yet - so run passwd draco from
the existing root session first, or do both as root:

ssh root@192.168.27.44 -t 'passwd draco && passwd root'

Until passwd root runs, the password published in this repository still opens a serial
console on this board. SSH is closed; the physical path is not.

Git history is #6 and is a separate, larger job. Rotating the credential is what makes the
published copy worthless, and that is the important half.

⚠️ The rescue SD card is a clone from before this and still accepts root over SSH with that
password. It needs a re-sync.

**Half done 2026-08-29, and the half that is done is the half that matters least.** The literal password is removed from `23-sd-boot.md` and `16-ethernet-broken.md`, and SSH no longer accepts passwords at all (#2): `PasswordAuthentication no`, verified as `Permission denied (publickey)` from a fresh session. **But the credential itself is unchanged and still works on the serial console**, and it remains in git history, so this stays open. Two commands, and only you should run them: ```sh ssh draco@192.168.27.44 sudo passwd draco # needed for sudo and for serial console recovery sudo passwd root # this is the one that retires the published credential ``` `sudo` will ask for `draco`'s password, which does not exist yet - so run `passwd draco` from the existing root session first, or do both as root: ```sh ssh root@192.168.27.44 -t 'passwd draco && passwd root' ``` Until `passwd root` runs, **the password published in this repository still opens a serial console on this board.** SSH is closed; the physical path is not. Git history is #6 and is a separate, larger job. Rotating the credential is what makes the published copy worthless, and that is the important half. ⚠️ The rescue SD card is a clone from before this and still accepts root over SSH with that password. It needs a re-sync.

tiagoagueda commented

2026-08-29 08:04:04 +00:00

Author

Owner

Done 2026-08-29. The published credential no longer works anywhere on this board.

Both accounts were given fresh 28-character random passwords. The plaintext never crossed the
network: generated locally, hashed locally with openssl passwd -6, and only the SHA-512
crypt hashes were sent, staged in tmpfs and shredded after chpasswd -e.

Verified rather than assumed - the old password was checked against the stored hashes directly:

root:  old published password rejected
draco: old published password rejected

and the new ones confirmed by recomputing the hash from the stored salt:

root   new password verified against stored hash: YES
draco  new password verified against stored hash: YES

The credentials are in an untracked secrets/ directory, ignored before the file existed, for
the owner to move into a password manager.

The literal is removed from 23-sd-boot.md and 16-ethernet-broken.md. It remains in git
history - that is #6 and is untouched. Rotating the credential is what makes the published
copy worthless, and that is now done.

⚠️ The rescue SD card is a clone from before this and still carries the old password and
unhardened sshd. tools/sync-rescue-sd.sh now copies the hardening drop-in and the admin key,
but the card is not safe until it is re-synced - and it is a full system with a shell.

**Done 2026-08-29. The published credential no longer works anywhere on this board.** Both accounts were given fresh 28-character random passwords. The plaintext never crossed the network: generated locally, hashed locally with `openssl passwd -6`, and only the SHA-512 crypt hashes were sent, staged in tmpfs and shredded after `chpasswd -e`. Verified rather than assumed - the old password was checked against the stored hashes directly: ``` root: old published password rejected draco: old published password rejected ``` and the new ones confirmed by recomputing the hash from the stored salt: ``` root new password verified against stored hash: YES draco new password verified against stored hash: YES ``` The credentials are in an untracked `secrets/` directory, ignored before the file existed, for the owner to move into a password manager. The literal is removed from `23-sd-boot.md` and `16-ethernet-broken.md`. **It remains in git history - that is #6 and is untouched.** Rotating the credential is what makes the published copy worthless, and that is now done. ⚠️ **The rescue SD card is a clone from before this** and still carries the old password and unhardened sshd. `tools/sync-rescue-sd.sh` now copies the hardening drop-in and the admin key, but the card is not safe until it is re-synced - and it is a full system with a shell.

tiagoagueda closed this issue

2026-08-29 08:04:05 +00:00

tiagoagueda referenced this issue from a commit

2026-08-29 11:58:10 +00:00

ssh is key-only, and a uid that would have become an escalation path

tiagoagueda referenced this issue from a commit

2026-08-29 11:58:10 +00:00

gitignore: keep board credentials out of the repo

tiagoagueda referenced this issue from a commit

2026-08-29 12:07:51 +00:00

ssh is key-only, and a uid that would have become an escalation path

tiagoagueda referenced this issue from a commit