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

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