---
title: edge2 Access Reference
type: runbook
tags:
  - proxmox
aliases: []
related:
  - [[expose-service-edge2]]
  - [[proxmox-onboard-node]]
  - [[vaultwarden-plan]]
  - [[lxc-service-migration]]
  - [[headscale-onboard-node]]
updated: 2026-06-18
---
# edge2 Access Reference

## SSH Access

edge2 is hardened differently from home-cluster Proxmox nodes.

| Property | edge2 | Home Proxmox (data, utility, etc.) |
|----------|-------|------------------------------------|
| SSH user | `admin` (not root) | `root` or `zvx` |
| Auth method | Key-only | Key or password |
| PasswordAuthentication | `no` (hardened) | varies |
| Root login | Disabled | Allowed |
| Sudo | Passwordless for admin | N/A (already root) |
| SSH alias | `ssh edge2` | `ssh zvx@<ip>` |

### SSH config entry

```
Host edge2
    HostName 100.64.0.26
    User admin
```

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

`/etc/ssh/sshd_config.d/50-cloud-init.conf` has `PasswordAuthentication yes`, which contradicts the hardened `no` in the main config. The main config wins (loaded first), but this inconsistency should be cleaned up:

```bash
ssh edge2
sudo rm /etc/ssh/sshd_config.d/50-cloud-init.conf
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

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