Die Seite geht online

Verfasst von

in

Die Seite war fertig, und sie lag noch im Keller. Im Ordner staging auf meinem Heimserver, dem Cube, standen 71 Dateien, zusammen 2,6 Megabyte. Es fehlte nur noch der Weg zum Hoster, also zu der Firma, bei der die Seite für alle erreichbar im Netz steht.

Der Weg heißt SSH. Das ist eine verschlüsselte Verbindung zu einem anderen Rechner, die sich statt mit einem Passwort mit einem Schlüsselpaar ausweist: Ein Schlüssel bleibt bei mir, sein Gegenstück liegt beim Hoster. Passen beide zusammen, öffnet sich die Tür.

Auf dem Cube arbeite ich meist als root, der Verwalter mit allen Rechten. Für diese Aufgabe wollte ich das nicht. Wer nur Dateien verschicken soll, braucht keine Schlüssel zum ganzen Haus. Also entstand ein eigener Benutzer, kisp-deploy. Er kann sich nicht anmelden und hat keine Verwaltungsrechte. Er darf den Export lesen, den Schlüssel benutzen und mit dem Hoster sprechen.

Der Schlüsselordner gehört einer Gruppe, die auch Protokolle lesen darf. In sie wollte ich kisp-deploy nicht aufnehmen. Ein schmales Durchgangsrecht auf dem übergeordneten Ordner löst das: Der Benutzer darf hindurchgehen, hineinschauen darf er nicht.

Dann schickte ich den öffentlichen Schlüssel zum Hoster und prüfte die Verbindung. Sie stand beim ersten Versuch. Mein Claude hat daraufhin ein Skript geschrieben, das den Export kopiert, bereinigt und hochlädt. Das Hochladen übernimmt rsync. Das Programm schickt nur, was sich geändert hat, und entfernt auf dem Server, was es im Export nicht mehr gibt.

Vor dem echten Lauf gab es einen Probelauf. Er zeigt, was passieren würde, und ändert nichts. Er nannte 71 Dateien zum Hochladen und eine zum Löschen: eine Platzhalterseite des Hosters mit dem Namen index.htm. Damit war klar, dass der Lauf nichts Wichtiges trifft.

Dann kam der echte Lauf, und die Seite war da. Eine Sache fehlte noch: Im Backend stand ein Haken, der Suchmaschinen bat, die Seite zu übergehen. Er gehörte zur Bauphase. Ich habe ihn entfernt, neu exportiert und übertragen. Ein Blick in den Quelltext zeigte: Kein noindex mehr.

Ergebnis: Die Seite ist unter https://thekeepitsimpleproject.org/ erreichbar, mit Zertifikat von Let’s Encrypt und einem Hinweis an Browser, nur noch verschlüsselt zu verbinden (HSTS, 180 Tage). Zugriffsprotokolle sind beim Hoster abgeschaltet.

Zeig mir, wie es geht: Benutzer und Schlüssel
  • Benutzer ohne Shell und ohne sudo, als root:
useradd --system --home-dir /var/lib/kisp-deploy --create-home --shell /usr/sbin/nologin kisp-deploy
  • Durchgangsrecht auf den Credentials-Ordner (root:adm, 750) statt Gruppenmitgliedschaft in adm:
apt install acl
setfacl -m u:kisp-deploy:--x /etc/terruhn.it/credentials
getfacl /etc/terruhn.it/credentials

Die Ausgabe enthält user:kisp-deploy:--x.

  • Eigener Unterordner und Schlüsselpaar (ed25519, ohne Passphrase, nur für diesen Zweck):
install -d -m 0700 -o kisp-deploy -g kisp-deploy /etc/terruhn.it/credentials/kisp-deploy
runuser -u kisp-deploy -- ssh-keygen -t ed25519 -N "" -C "kisp-deploy@cube" -f /etc/terruhn.it/credentials/kisp-deploy/id_ed25519_all-inkl
cat /etc/terruhn.it/credentials/kisp-deploy/id_ed25519_all-inkl.pub

Den öffentlichen Schlüssel trägst du im KAS des Hosters beim SSH-Benutzer ein.

  • Erste Verbindung mit eigener known_hosts, danach mit StrictHostKeyChecking=yes:
runuser -u kisp-deploy -- ssh -i /etc/terruhn.it/credentials/kisp-deploy/id_ed25519_all-inkl \
  -o IdentitiesOnly=yes \
  -o UserKnownHostsFile=/etc/terruhn.it/credentials/kisp-deploy/known_hosts \
  -o StrictHostKeyChecking=accept-new \
  ssh-wXXXXXXXX@wXXXXXXXX.kasserver.com 'pwd; ls -la'

Der SSH-Benutzer landet in einer eingeschränkten Umgebung mit / als Home; die Webdateien liegen unter /www/htdocs/<Kundenkennung>/<Domain>.

  • Verworfen: den Benutzer in die Gruppe adm aufnehmen (liest auch Protokolle) und den Schlüssel außerhalb von /etc/terruhn.it/credentials ablegen (bräche die Pfadkonvention).
Zeig mir, wie es geht: Übertragung mit rsync
  • Skript export-uebertragen.sh (0.3) nach /usr/terruhn.it/sbin/, zusammen mit export-bereinigen.sh:
install -m 0755 export-bereinigen.sh export-uebertragen.sh /usr/terruhn.it/sbin/
  • Ablauf: Staging per rsync -rlt --delete in ein Arbeitsverzeichnis (/var/lib/kisp-deploy/export) kopieren, dort export-bereinigen.sh ausführen, dann hochladen:
rsync -rlt --delete-after --no-owner --no-group --chmod=D755,F644 --itemize-changes --stats \
  -e "ssh -i …/id_ed25519_all-inkl -o IdentitiesOnly=yes -o UserKnownHostsFile=…/known_hosts -o StrictHostKeyChecking=yes" \
  /var/lib/kisp-deploy/export/ ssh-wXXXXXXXX@wXXXXXXXX.kasserver.com:/www/htdocs/<Kundenkennung>/<Domain>/

Die Kopie ist nötig, weil kisp-deploy im Staging nicht schreiben darf.

  • Schutz vor einem leeren Export: Abbruch, wenn index.html fehlt oder weniger als 20 Dateien im Staging liegen.
  • Probelauf und echter Lauf:
runuser -u kisp-deploy -- /usr/terruhn.it/sbin/export-uebertragen.sh --dryrun
runuser -u kisp-deploy -- /usr/terruhn.it/sbin/export-uebertragen.sh

Der Probelauf nutzt rsync --dry-run; in der Ausgabe stehen mit *deleting die Dateien, die der echte Lauf löschen würde.

  • Kontrolle der Live-Seite:
curl -sI https://thekeepitsimpleproject.org/ | grep -i "^HTTP\|x-robots\|strict-transport"
curl -s https://thekeepitsimpleproject.org/ | grep -io noindex

Erwartet: HTTP/2 200, strict-transport-security: max-age=15552000, keine Treffer für noindex.

  • Die Indexierungssperre (Einstellungen → Lesen) lässt sich per kisp-wp nicht ändern, option update steht nicht in der Allowlist. Das Entfernen des Hakens im Backend und ein neuer Export genügen.