echo6-docs/vault/runbooks/edge2-access-reference.md
echo6-autocommit 8f95c6e5c3 auto: docs sync 2026-08-15T12:00:04+00:00
Files changed: engine/.embcache.json engine/changelog.md engine/lint-report.md vault/.obsidian/workspace.json vault/docs/hardware/environment.md vault/projects/fleet-storage-memory-upgrade.md vault/projects/navi-recon-separation.md vault/runbooks/corescope-ingest-stall-oom.md vault/runbooks/edge2-access-reference.md vault/runbooks/edge2-boot-recovery.md vault/runbooks/navi-lift-to-media.md vault/runbooks/peertube-sitemap-redis-oom.md
2026-08-15 12:00:04 +00:00

148 lines
5.9 KiB
Markdown

---
title: edge2 Access Reference
type: runbook
tags:
- proxmox
aliases: []
related:
- [[proxmox-onboard-node]]
- [[expose-service-edge2]]
- [[lxc-service-migration]]
- [[authentik]]
- [[headscale-onboard-node]]
updated: 2026-08-15
---
# edge2 Access Reference
## SSH Access
edge2 is hardened differently from home-cluster Proxmox nodes. If you are here because edge2 rebooted and its [[services]] are returning 502, go to [[edge2-boot-recovery]] instead.
| Property | edge2 | Home Proxmox (data, utility, etc.) |
|----------|-------|------------------------------------|
| SSH user | `admin` (not root) | `root` or `zvx` |
| Auth method | Key-only | Key or password |
| PasswordAuthentication | **effectively `yes`** — see below | varies |
| Root login | Key-only (`without-password`) | Allowed |
| Sudo | Passwordless for admin | N/A (already root) |
| SSH alias | `ssh edge2` | `ssh zvx@<ip>` |
### SSH config entry
On cortex there are two aliases — `edge2` goes over the public IP, `ts-edge2` over the tailnet. Both use the contabo2 key.
```
Host edge2
HostName 184.174.35.153
User admin
IdentityFile ~/.ssh/contabo2_ed25519
Host ts-edge2
HostName 100.64.0.26
User admin
IdentityFile ~/.ssh/contabo2_ed25519
```
`ssh root@100.64.0.26` does **not** work — root login is key-only and root has no authorized key. Use the alias.
### Authorized keys
Located at `/home/admin/.ssh/authorized_keys` on edge2:
| Key name | Source | Purpose |
|----------|--------|---------|
| echo6-contabo2-184.174.35.153 | cortex `~/.ssh/contabo2_ed25519` | Original provisioning key |
| cortex (id_ed25519) | cortex default key | Normal automation |
| matt-desktop-wsl2 | WSL2 default key | WSL/Claude sessions |
| cookie-sync | Windows SSH key | Native Windows terminal |
### Known gotcha: cloud-init conflict — the drop-in WINS (corrected 2026-08-15)
`/etc/ssh/sshd_config.d/50-cloud-init.conf` sets `PasswordAuthentication yes`, contradicting the hardened `no` in the main config. **An earlier version of this page claimed the main config wins. It does not.** sshd takes the *first* value it obtains, and `Include` sits at **line 12** while `PasswordAuthentication no` is at **line 57** — so the drop-in is read first and its `yes` wins.
Verified on edge2:
```
$ sudo sshd -T | grep -iE 'passwordauthentication|permitrootlogin'
permitrootlogin without-password
passwordauthentication yes
```
So password authentication is live on edge2's public IP. Root is still key-only (`without-password`), which is why the constant internet brute-force against root in `journalctl -u ssh` never succeeds — but non-root accounts are exposed to password guessing. Always confirm with `sshd -T` (effective config) rather than reading `sshd_config` and assuming.
Fix:
```bash
ssh edge2
sudo rm /etc/ssh/sshd_config.d/50-cloud-init.conf
sudo sshd -T | grep -i passwordauthentication # expect: no
sudo systemctl reload sshd
```
## PVE API Access
The PVE web UI and REST API use a separate auth system (`root@pam`) with its own password (see credentials file: `EDGE2_ROOT_PASSWORD`).
- **Web UI:** https://100.64.0.26:8006 (or https://184.174.35.153:8006)
- **API base:** `https://100.64.0.26:8006/api2/json/`
- **Auth:** `POST /access/ticket` with `username=root@pam&password=<EDGE2_ROOT_PASSWORD>`
The PVE API is useful when SSH is unavailable (e.g., before keys are authorized). It can create/start/stop CTs, read node status, and manage storage. It cannot directly execute arbitrary commands on the host — for that, use SSH or the PVE web shell.
### Container management via SSH
**`pct` needs sudo, and the failure is not an obvious permission error.** Running it as `admin` fails with pmxcfs IPC noise that reads like a broken cluster:
```
ipcc_send_rec[1] failed: Unknown error -1
Unable to load access control list: Unknown error -1
```
That means "you are not root", not "PVE is broken". Use `sudo -n` for every `pct` and in-container `systemctl` call.
```bash
# List CTs
ssh edge2 'sudo pct list'
# Exec into a CT
ssh edge2 'sudo pct exec <CTID> -- bash'
# Push files into a CT
scp file.txt edge2:/tmp/
ssh edge2 'sudo pct push <CTID> /tmp/file.txt /tmp/file.txt'
# Start/stop CTs
ssh edge2 'sudo pct start <CTID>'
ssh edge2 'sudo pct stop <CTID>'
```
## Lessons Learned (2026-06-16 deployment)
### Problem: SSH "Permission denied" to edge2
**Symptoms:** `ssh root@100.64.0.26``Permission denied (publickey,password)`
**Root cause:** edge2 was hardened at provisioning:
- SSH user is `admin`, not `root` — root login is disabled
- `PasswordAuthentication no` — only key auth works
- Only one key was authorized: `echo6-contabo2-184.174.35.153`, which is cortex's `~/.ssh/contabo2_ed25519` (not the default `id_ed25519`)
**Why it was confusing:**
1. The SSH error shows `publickey,password` as available methods — this is misleading because `PasswordAuthentication no` is enforced, but the SSH banner still lists both
2. We tried `root@` (wrong user) and the default `id_ed25519` (wrong key)
3. The [[environment]] docs didn't document the `admin` user or the specific key requirement
**Resolution:** Added cortex's default `id_ed25519`, WSL2 key, and Windows key to admin's `authorized_keys`. Added SSH config alias `edge2``admin@100.64.0.26`.
**Prevention:**
- Always document the SSH user + required key for hardened hosts in environment.md
- Add SSH config aliases immediately when onboarding new hosts
- For Contabo VPS instances: check cloud-init config for hardening applied at provisioning
### Problem: PVE API vs system passwords
**Symptoms:** PVE API login works with `EDGE2_ROOT_PASSWORD`, but SSH with same password fails.
**Root cause:** PVE `root@pam` password and the system root SSH password are managed separately. On edge2, the system root password was set by cloud-init at provisioning and may differ. Additionally, root SSH login is disabled entirely.
**Prevention:** Document both auth paths (SSH user + PVE API) separately in credentials and [[environment]] docs.