echo6-docs/vault/runbooks/edge2-access-reference.md

title	type	tags	aliases	related	updated
edge2 Access Reference	runbook	proxmox		proxmox-onboard-node expose-service-edge2 lxc-service-migration authentik headscale-onboard-node	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:

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.

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