Ct-113-Authelia - blame (7aa3e9)

Blame

7aa3e9	Claude Code	2026-05-28 15:40:46
2026-05-28: Wiki-Aktualisierung - neue CTs, Versionen, Dienste

# CT 113 – Authelia

> [!NOTE]

> CT 113 hostet **Authelia** als zentrale vorgeschaltete Authentifizierungs- und 2FA-Schicht für ausgewählte Webdienste hinter Caddy.

## Basisdaten

| Eigenschaft | Wert |

|---|---|

| **CT-ID** | `113` |

| **Name** | `authelia` |

| **IP** | `192.168.178.64` |

| **OS** | Debian 13 |

| **Öffentliche URL** | `https://auth.ls-cloud.biz` |

| **Interner Port** | `9091/tcp` |

| **Compose-Pfad** | `/opt/authelia/compose.yml` |

| **Konfig-Pfad** | `/opt/authelia/config/configuration.yml` |

| **User-Datei** | `/opt/authelia/config/users_database.yml` |

| **Notification-Datei** | `/opt/authelia/config/notification.txt` |

## Zweck

Authelia sitzt vor ausgewählten Webdiensten und erzwingt dort je nach Regel:

- kein Login (`bypass`)

- Passwort-Login (`one_factor`)

- Passwort + zweiter Faktor (`two_factor`)

Aktuell ist Authelia bereits für folgende Dienste in Benutzung:

- `terminal.ls-cloud.biz` → `two_factor`

- `files.ls-cloud.biz` → `two_factor`

- `termix.ls-cloud.biz` → `two_factor` (Termix mit SSH/RDP)

## Architektur

```text

Browser

-> Caddy auf dem Host

-> forward_auth gegen Authelia (CT 113 :9091)

-> bei Erfolg weiter zum eigentlichen Backend-Dienst

```

Portal selbst:

```text

https://auth.ls-cloud.biz

-> Caddy reverse_proxy

-> CT 113 :9091

```

## Wie ein neuer Dienst geschützt wird

Es braucht immer **zwei Änderungen**:

### 1. Authelia-Regel

In `configuration.yml` unter `access_control.rules` eine Domain-Regel ergänzen, z. B.:

```yaml

- domain: 'files.ls-cloud.biz'

  policy: two_factor

```

### 2. Caddy davor schalten

Im jeweiligen Domain-Block:

```caddy

forward_auth http://192.168.178.64:9091 {

uri /api/authz/forward-auth

copy_headers Remote-User Remote-Groups Remote-Email Remote-Name

}

```

Danach erst das eigentliche `reverse_proxy` zum Backend.

## Benutzerverwaltung

Aktuell wird der **file-based authentication backend** genutzt.

Benutzer stehen in:

```text

/opt/authelia/config/users_database.yml

```

Dort liegen u. a.:

- Benutzername

- Anzeige-Name

- Mailadresse

- Argon2-Passworthash

- Gruppen

### Aufbau eines Benutzers

Ein einzelner Benutzer sieht im aktuellen Setup z. B. so aus:

```yaml

users:

  admin:

    disabled: false

    displayname: "Sergej"

100

    password: "$argon2id$..."

101

    email: "sergej@ls-cloud.biz"

102

    groups:

103

      - admins

104

```

105

106

### Vorlage für einen neuen Benutzer

107

108

```yaml

109

  neueruser:

110

    disabled: false

111

    displayname: "Neuer User"

112

    password: "$argon2id$HIER_DEN_HASH_EINTRAGEN"

113

    email: "user@example.com"

114

    groups:

115

      - users

116

```

117

118

### Passwort-Hash erzeugen

119

Ein Passwort wird nicht im Klartext gespeichert, sondern als Hash.

120

Ein neuer Hash kann z. B. so erzeugt werden:

121

122

```bash

123

pct exec 113 -- docker run --rm authelia/authelia:latest \

124

  authelia crypto hash generate argon2 --password 'NEUES_PASSWORT'

125

```

126

127

Den `Digest:`-Wert dann in `users_database.yml` als `password:` eintragen.

128

129

### Benutzer hinzufügen – Schritt für Schritt

130

131

1. Passwort-Hash erzeugen

132

2. Benutzerblock unter `users:` in `users_database.yml` ergänzen

133

3. Datei speichern

134

4. Authelia neu starten:

135

136

```bash

137

pct exec 113 -- bash -lc "cd /opt/authelia && docker compose -f compose.yml restart"

138

```

139

140

5. Danach mit dem neuen Benutzer an `https://auth.ls-cloud.biz` testen

141

142

### Passwort eines bestehenden Benutzers ändern

143

144

1. neuen Hash erzeugen

145

2. beim Benutzer nur den Wert von `password:` ersetzen

146

3. Authelia neu starten

147

148

### Benutzer deaktivieren

149

150

```yaml

151

  neueruser:

152

    disabled: true

153

```

154

155

> [!IMPORTANT]

156

> Nach Änderungen an `users_database.yml` ist ein Restart von Authelia der saubere Weg, damit die Änderung sicher übernommen wird.

157

158

## TOTP / Google Authenticator / Aegis

159

160

Für den Benutzer kann in der Weboberfläche unter Sicherheitsoptionen ein **Einmal-Passwort (TOTP)** hinzugefügt werden.

161

Das funktioniert mit:

162

- Google Authenticator

163

- Aegis

164

- Ente Auth

165

- Authy

166

- anderen TOTP-Apps

167

168

## „E-Mails“ / One-Time-Codes

169

170

Aktuell ist **kein echter SMTP-Versand** eingerichtet.

171

Stattdessen schreibt Authelia Benachrichtigungen in eine Datei auf dem Server:

172

173

```text

174

/opt/authelia/config/notification.txt

175

```

176

177

Dort landen z. B.:

178

- Identity-Confirmation-Codes

179

- One-Time-Codes

180

- Links zum Widerruf

181

- andere notifier-basierte Meldungen

182

183

### Beispiel ansehen

184

185

```bash

186

pct exec 113 -- tail -60 /opt/authelia/config/notification.txt

187

```

188

189

> [!IMPORTANT]

190

> Wenn ein Benutzer behauptet, es komme „keine Mail“, ist im aktuellen Setup zuerst **diese Datei** zu prüfen.

191

192

## Prüfung

193

194

```bash

195

pct status 113

196

pct exec 113 -- bash -lc "cd /opt/authelia && docker compose -f compose.yml ps"

197

curl -k -I https://auth.ls-cloud.biz

198

curl -k -I https://terminal.ls-cloud.biz

199

curl -k -I https://files.ls-cloud.biz

200

```

201

202

## Wichtige Dateien

203

204

| Pfad | Zweck |

205

|---|---|

206

| `/opt/authelia/compose.yml` | Docker-Compose-Definition |

207

| `/opt/authelia/config/configuration.yml` | Hauptkonfiguration |

208

| `/opt/authelia/config/users_database.yml` | Benutzer & Passwort-Hashes |

209

| `/opt/authelia/config/db.sqlite3` | lokaler Storage |

210

| `/opt/authelia/config/notification.txt` | serverseitige „E-Mails“ / Codes |

211

| `/etc/caddy/Caddyfile` (Host) | Portal + ForwardAuth vor geschützten Diensten |

212

213

## Hinweise

214

215

> [!TIP]

216

> Für neue Dienste immer in zwei Schritten denken: **Authelia-Regel** und **Caddy forward_auth**.

217

218

> [!WARNING]

219

> Nur Webdienste hinter Caddy lassen sich so sauber schützen. Nicht-HTTP-Protokolle brauchen andere Wege.