Qbi's Weblog

Innerhalb unseres Hackspaces wird unter anderem gern git verwendet. Anfangs nutzten wir hierfür GitHub und später stiegen wir auf Selbsthosting um.

Die ersten Experimente mit Selbsthosting begannen mit trac. Aus verschiedenen Gründen wurde das jedoch wenig benutzt. Also startete der nächste Versuch mit Gitea. Das wurde deutlich mehr benutzt. Aufgrund der Entwicklungen bei Gitea entschlossen wir uns später, zu Forgejo zu wechseln. Mittlerweile sind alle Repositorys von GitHub umgezogen und die Adresse https://git.kraut.space/ ist der zentrale Ort für die Repositorys des Krautspace sowie von einigen Mitgliedern.

Um das Bild abzurunden, wollte ich die Seite auch als Tor Onion Service verfügbar machen. Einige Personen im Umfeld des Space' nutzen gern Tor und den Tor-Browser. Daher versuchen wir, einige der selbst gehosteten Dienste auch mit Onion-Adressen zu versehen.

Bei der Einrichtung achten wir nicht darauf, den Dienst bzw. dessen IP-Adresse zu verstecken. Wenn man das als “richtigen” Onion-Dienst betreiben will, müsste man noch weitere Einstellungen im Webserver und im Betriebssystem vornehmen.

Die Einrichtung von Forgejo als Tor Onion Service passiert in zwei Schritten:

1. Konfiguration von Tor
2. Konfiguration des Webservers

Konfiguration von Tor

Auf unseren Servern kommt Systemd zum Einsatz. Daher richte ich zunächst eine neue Instanz des Tor-Service ein:

tor-instance-create forgejo

Das legt einen neuen Systembenutzer namens _tor-forgejo und Verzeichnisse in /etc sowie /var/lib/tor-instances an. Weiterhin wird von einem Systemd-Template ein neuer Dienst tor@forgejo.service abgeleitet.

Im Verzeichnis /etc/tor/instances gibt es das Unterverzeichnis forgejo und darin liegt die relevante torrc um den Dienst zu konfigurieren.

Üblicherweise würde man dort folgende Zeilen eintragen:

HiddenServiceDir /var/lib/tor-instances/forgejo
HiddenServicePort 80 127.0.0.1:80
HiddenServiceVersion 3

Nach einem Neustart des Systemd-Dienstes wird in obigem Verzeichnis eine Datei namens hostname angelegt. Dort ist die Onion-Adresse.

Ansonsten sorgt Tor dafür, dass alle Anfragen über den virtuellen Port 80 an die Adresse 127.0.0.1 mit Port 80 weitergegeben werden. Damit müsste ein Webserver entsprechend eingestellt werden.

Wir nutzen Forgejo mit einem nginx als Reverse Proxy, d.h. es gibt einen Unix-Socket, über den kommuniziert wird. Diesen kann man natürlich direkt für Tor verwenden:

HiddenServiceDir /var/lib/tor-instances/forgejo
HiddenServicePort 80 unix:/run/forgejo/forgejo.sock
HiddenServiceVersion 3

Nach einem Neustart des Tor-Dienstes wartet dieser nun auf Anfragen.

Konfiguration des Webservers

An sich wäre bei obigem Schritt die Arbeit zu Ende. Allerdings gibt es den HTTP-Header Onion-Location. Damit kann man den Tor-Browser informieren, dass es einen Onion-Dienst gibt und dieser leitet ggf. automatisch auf die Onion-Adresse um.

In den Einstellungen des nginx für den Dienst wird daher noch folgende Zeile eingetragen:

add_header onion-location  http://kqfdxjpzqt345qplxy6yrgkj4rotfokskmxyqz5a4t4yewg6n62ea2ad.onion$request_uri

Nachdem die Konfiguration neu eingelesen wurde, kann man die Adresse https://git.kraut.space aufrufen. Sofern man einen Browser ohne spezifischen “Onion-Fähigkeiten” verwendet, wird einfach die reguläre Seite verwendet. Sollte man einen Tor-Browser oder einen anderen Browser verwenden, der mit Onion-Adressen umgehen kann und den Header kennt, wird man entweder gefragt, ob man zur Onion-Seite weitergeleitet werden möchte oder es wird automatisch gemacht.

Vor etwa einem Jahr schrieb ich hier einen Beitrag zu Mastodon und der DSGVO. Darin beschrieb ich, was Betreiber:innen zur Einhaltung der DSGVO zu beachten haben. Daraufhin wurde ich von der Stiftung Datenschutz kontaktiert. Sie wollten gern einen Leitfaden zum Datenschutz bei Mastodon schreiben und fragten mich, ob ich gern daran mitarbeiten wolle. Natürlich wollte ich.

So entstand in einer Zusammenarbeit mit Rebecca Sieber und Malte Engeler der Leitfaden als PDF-Datei sowie weitere sehr hilfreiche Dokumente. Ich habe die Zusammenarbeit sehr genossen und insbesondere der wissenschaftliche Aufsatz von Rebecca Sieber bringt viele interessante Aspekte beim Betrieb des Dienstes ans Licht.

Wenn also jemand von euch Mastodon betreibt, kann ich euch die Lektüre der Dokumente bzw. die Umsetzung unserer Hinweise nur raten. Viele der Hinweise lassen sich auch auf andere Dienste im Fediverse übertragen. Das heißt, auch hier bieten die Dokumente einen Mehrwert. Wenn ihr Fragen, Hinweise oder Kommentare habt, freue ich mich sehr über einen Kommentar hier im Blog. Ihr könnt natürlich auch die Stiftung Datenschutz gern direkt kontaktieren.

Viel Spaß beim Lesen und Umsetzen.

Mastodon ist ein soziales Netzwerk zum Selberbasteln. So oder ähnlich lautet eine der Versprechungen des Dienstes. Wer mag, kann einen eigenen Server betreiben und sich somit dem Fediverse vernetzen. Daher betreibe ich Anfang 2023 auch einen Server. Der ist unter den Adressen

• https://freie-re.de
• http://az7swyjuxw4pf4bbsmsgbfpwtyfs5y5pa6a4d5vklnw7ziv54cn7u2ad.onion/

erreichbar.

Seit kurzem gibt es nun die Version 4.2.0, die recht viele Verbesserungen bietet. Also wollte ich die Software aktualisieren. Bei Mastodon erfolgen Aktualisierungen in der Regel über git. Das heißt, mittels git fetch wird das Repository aktualisiert und dann wird die “richtige” Version ausgecheckt. Eventuell sind noch Pakete zu aktualisieren und das wars im Wesentlichen.

Als ich das bei meinem Server versuchte, stellte ich fest, dass einige Programme veraltet waren. Das Image, was ich zur Installation verwendete, basiert auf Debian bullseye. Mittlerweile ist Debian bookworm aktuell. Vor dem Update von Mastodon stand also ein Update von Debian. In der Regel ist ein Update von der Vor- zur nächsten Debian-Version recht unproblematisch. So auch hier. Das Update war schnell gemacht.

Also gab ich ein git fetch && git checkout v4.2.0 ein und startete so die Aktualisierung von Mastodon. Danach mussten die Befehle

• bundle install
• yarn install --frozen-lockfile

durchgeführt werden. Bei letzten Kommando sagte mir mein System, dass dieser Befehl nicht verfügbar sei. Allerdings lag im Unterverzeichnis bin/ eine ausführbare Datei namens yarn. Als ich diese direkt ausführte, war die Ausgabe wieder, dass Yarn nicht verfügbar sei. Yarn wurde mittels corepack installiert. Aber corepack war auch nicht verfügbar. Damit musste ich noch einen Schritt zurückgehen: zur Installation von node.js selbst.

Hier lag dann die Lösung: Beim Update von Debian wurde auch node.js aktualisiert. In dem Update war vermutlich corepack und anderes nicht mit eingeschlossen. Ich deinstallierte also node.js, aktualisierte die sources.list-Datei und installierte node.js wieder. Damit waren corepack und yarn auch wieder verfügbar und der obige Befehl lief problemlos durch.

Die letzte Hürde bestand im Neustart der Mastodon-Dienste. Ich hatte diese mittels systemctl restart mastodon-* neu gestartet. Dies führte zu Connection refused-Meldungen. Der Streaming-Dienst unter Port 4000 war nicht erreichbar. Dies lag daran, dass der Systemd-Service mastodon-streaming erneuert wurde. Also fehlte noch ein systemctl daemon-reload gefolgt vom Neustart.

Das war dann der Punkt, an dem der Server mit Version 4.2.0 anstandslos weiterlief.

In meinem Beitrag zum einjährigen Jubiläum von Logseq war unter anderem auch der damalige Graph zu sehen. Mittlerweile ist der natürlich weiter gewachsen. Hier ist eine aktuelle Ansicht.

Die meisten der Knoten sind weiß oder eher grau. Allerdings haben einige auch Farbe. Mich interessiert nun schon eine Weile, was die Farben bedeuten. Leider fand ich bisher keine Doku dazu. In einem Forum findet sich nur eine unbeantwortete Frage.

Ich habe mal die eingefärbten Knoten angeschaut und hatte eine Idee. Zu Testzwecken legte ich nun einen leeren Graphen an und experimentierte mit Logseq. Das sind meine aktuellen Erkenntnisse:

• Seiten ohne weitere Eigenschaften haben eine weiße oder gräuliche Farbe. Dies ändert sich auch nicht, wenn die Seiten untereinander verlinkt sind.
• Wenn man die tags::-Eigenschaft auf einer Seite verwendet, so färbt sich der Knoten der getaggten Seite gelb.

  

• Ich nutze recht häufig Hierarchien innerhalb von Logseq. Beispielsweise habe ich eine Seite zur DSGVO und Seiten über Artikel der DSGVO sind dann untergeordnet. Diese Hierarchie wird in Logseq mit einem Slash markiert. Das heißt, ich könnte folgende Seiten haben:
  • [[DSGVO]]
  • [[DSGVO/Kapitel 1]]
  • [[DSGVO/Kapitel 10]]
  • usw.
  Damit sind die Seiten der DSGVO-Seite zugeordnet und von dort erreichbar. Das kann man dann über mehrere Hierarchie-Ebenen machen. Die Seiten unterhalb der Hauptebene werden bunt gemacht. Jede Unterseite bekommt eine eigene Farbe. Vermutlich werden die Farben nach einem Schema vergeben. Das konnte ich bisher nicht herausfinden.

  

Die oben genannten Möglichkeiten sind bisher die einzigen, die ich fand, die Farben verteilen. Kennt ihr andere? Sollte ich von euch noch Beispiele hören oder selbst etwas finden, ergänze ich den Artikel.

ChatGPT ist derzeit in aller Munde. Hin und wieder spiele ich auch damit herum. Bisher bin ich jedoch “underwhelmed” von der “Intelligenz” dieses Systems. Die Anzahl an falschen oder verwirrenden Antworten auf meine Fragen ist mir zu hoch. Das folgende Beispiel belegt das recht schön.

Aus einer Laune heraus fragte ich nach der Anzahl der Buchstaben des Wortes “Informationssicherheitsmanagementsysteme”:

Ich nahm natürlich an, dass ein “Computer” eine derart einfache Aufgabe korrekt bearbeiten kann. Dennoch habe ich versucht, ChatGPT von meiner (falschen) Meinung zu überzeugen.

Nun teilte ich ChatGPT mit, dass diese Antwort nicht stimmt und so versuchte sich die Software auch an einer neuen Raterunde.

Erst beim letzten Versuch zählte ChatGPT die Buchstaben des Worts “Informationssicherheitsmanagementsysteme” aus und präsentierte das korrekte Ergebnis.

Die Linux-Kommandozeile benötigte nur einen Versuch:

:~$ echo -n Informationssicherheitsmanagementsysteme | wc
      0       1      40

Ich habe im Blog schon einige Male über Logseq geschrieben. Ich habe die Software über Flatpak installiert, ähnlich wie schon OnionShare. Hin und wieder muss die Software aktualisiert werden. Dies passiert über den Befehl 

flatpak update com.logseq.Logseq

Alternativ kann man auch den Namen einer anderen Software oder auch nichts angeben. Im letzteren Fall aktualisiert FlatPak alle installierte Software.

Als ich das nun heute versuchte, begrüßte mich FlatPak mit einer Fehlermeldung:

Warnung: Failed to create a mountpoint for revokefs-fuse: Can't create temporary directory
Warning: Can't create temporary directory

Tja, was tun? Der erste Versuch war, FlatPak mit einer Verbose-Option zu mehr Ausgabe zu überreden. Dies sagte mir nur, Calling system helper. Das ist für die Fehlersuche wenig hilfreich.

Also habe im nächsten Versuch mal eine Suchanfrage gestartet. Hier gab es ein paar Hinweise auf fusermount, ein paar Beiträge empfehlen, die Rechte von Verzeichnissen zu ändern oder es wird den Fragenden gleich empfohlen, eine andere Art der Installation zu wählen. Insgesamt war die Ausbeute wenig hilfreich.

Viel hilfreicher war ein Blick auf das Dateisystem. Neben dem FlatPak-Updates gab es auch Updates meines Betriebssystems. Und die große Menge an Dateien hatte die Partition, die /var beinhaltet, gefüllt. Also flugs aufgeräumt:

apt autoremove

Damit war das var-Verzeichnis wieder frei und das Update von FlatPak lief problemlos durch. Falls ihr also auch die Meldung erhaltet, könnte es sich lohnen, einen Blick auf das Dateisystem zu werfen.

Ich überlege noch, ob es nicht sinnvoll wäre, wenn FlatPak dies auch als Fehler meldet und werde diesbezüglich eventuell einen Bugreport einreichen.

Letztes Jahr entschied ich mich, Obsidian und Logseq auszuprobieren und entschied mich im Anschluss, mit Logseq weiterzumachen. Ich benutze die Software mittlerweile nicht nur für das im Artikel angesprochene Projekt, sondern auch für andere Sachen. Es ist also Zeit für einen Rückblick.

So sieht das Projekt heute aus:

Der Graph ist über das letzte Jahr definitiv gewachsen. Insgesamt sind ca. 600 Artikel in Logseq hinzu gekommen. Das sind sowohl solche, die ich als atomar bezeichnen würde. Das heißt, Artikel über einen Begriff, wie er in dem Projekt genutzt wird. Daneben gibt es Dokumente, die bestimmte Arbeitsschritte umfassen oder komplexere Sachen erklären.

Als ich meinen Artikel schrieb, gefiel mir die Konzentration auf das Journalling nicht allzusehr. Nach einem Jahr Benutzung muss ich sagen, dass das Journal doch ein zentraler Punkt für mich geworden ist. Die Software ist nicht nur eine einfache Dokumentation der Software, sondern ich schreibe im Journal auf, was ich getan habe und zu tun gedenke. Dort lege ich manchmal einen neuen Artikel an und springe vom Journal aus dahin. Insofern hat sich meine Benutzung ein wenig angepasst.

Im Laufe der Zeit habe ich in die Artikel Meta-Angaben eingebaut. Also beispielsweise arbeite ich viel mit Alias-Seiten. Dort gibt es eine Seite, die den Inhalt enthält und ich kann Aliase anlegen, unter der die Seite auch erreichbar ist. So könnte es etwa eine Seite namens »Auftrag« geben und eine Alias-Seite namens »Aufträge«. Beide kann ich verlinken und über den Link komme ich wieder zur Seite »Auftrag«. Weiterhin habe ich Tags verwendet und einige eigene Meta-Angaben definiert. Letztere nutze ich um, über Suchen (Querys) Informationen zu sammeln.

Insgesamt hat mir Logseq schon sehr oft geholfen, Informationen wiederzufinden und Wissen zu kombinieren. Insofern erfüllt die Software genau den Zweck, für die es gebaut wurde.

Insgesamt habe ich mich gut an die Software gewöhnt und die Kritikpunkte aus meinem ersten Artikel stellen sich als nicht so stark dar, wie gedacht.

Ich wollte damals die Benutzung mit git ausprobieren. Das habe ich nie gemacht. Allerdings teile ich den Graphen (also alle Dateien) über NextCloud mit anderen. Hier gibt es immer nur getrennte Schreibzugriffe. Daher hatte ich nie Konflikte. Für mich funktioniert dieses Teilen bisher problemlos.

Alles in allem nutze ich die Software mit großer Zufriedenheit und werde das auch weiterhin tun.

Habt ihr in der letzten Zeit von Mastodon gehört? Seitdem Elon Musk Twitter übernommen hat, gibt es viele Menschen, die Twitter den Rücken kehren und Neues suchen. Ein wichtiges, oft gewähltes Ziel heißt Mastodon.

Mastodon ist eine Software, die sehr stark an Twitter erinnert und von Eugen Rochko auch in Unzufriedenheit mit der Plattform entwickelt wurde. Dennoch gibt es einige Unterschiede zu Twitter und einige Menschen, die sich mit viel Enthusiasmus in das Abenteuer stürzen, sind anfangs verwirrt oder unzufrieden. Denn Mastodon ist eben doch nicht Twitter. Die Unterschiede sind beim Einstieg stark zu spüren.

Daher haben viele Leute Anleitungen, Tutorials und Erklärungen geschrieben, um den Einstieg zu erleichtern. Unten findet ihr einige dieser Quellen.

Aus meiner Sicht solltet ihr einfach mit Offenheit und Neugierde zu Mastodon kommen. Sucht euch einfach eine grob passende Instanz, legt euch ein Konto an und legt los. Wenn ihr nach einiger Zeit feststellt, dass die Instanz nicht passt, könnt ihr die einfach wechseln. Wenn euch euer Account insgesamt nicht gefällt, dann löscht ihn und fangt vielleicht unter anderen Vorzeichen nochmal an. Aber ich stelle fest, dass sich bei Vielen nach anfänglichen Schwierigkeiten ein Wohlfühlgefühl einstellt und sie sich mit großer Freude dort tummeln. Also kommt vorbei und probiert euch aus!

• Wie starte ich von Twitter neu auf Mastodon
• Fediverse -- So geht gutes Social Media von Digitalcourage
• #neuHier - und wie interagiere ich?
• Komm´ ins Fediverse – leave Enlo Muks behind – hier eine umfassende Auflistung, wer schon alles im Fediverse ist. von Katja Diehl
• Fedi.Tips (englisch)
• Umziehen auf eine andere Mastodon-Instanz

In regelmäßigen Abständen habe ich das Vergnügen, auf Journalisten aus verschiedenen Ländern der Welt zu treffen. Ich schule diese, wie man Internetsperren umgehen kann, worauf es bei der Anonymität ankommt etc. Eines der Werkzeuge, die ich dabei erwähne und welche Begeisterung auslöst, ist OnionShare (Onion-Link).

Wie der Name schon sagt, geht es um den Austausch (von Dateien) über Onions (also das Tor-Netzwerk). OnionShare entstand ursprünglich als Werkzeug, um eine einfache und sichere Downloadmöglichkeit über Tor Onion Services zur Verfügung zu stellen. Das Gute hieran ist, dass der Austausch komplett über das Tor-Netzwerk läuft, Sender und Empfänger können also unerkannt kommunizieren. Wenn OnionShare beendet wird, dann verschwindet auch der Link und kann auch nicht wieder wiederhergestellt werden. Mittlerweile lassen sich über das Programm Downloads oder Uploads bereitstellen, chatten und auch Webseiten anbieten. All das passiert mit wenigen Klicks. Wie funktionier das?

Für Windows gibt es eine MSI-Datei und für macOS eine DMG-Datei, die man installieren kann. Unter Linux gibt es Flatpak- oder Snap-Pakete. Ich nutze in der Regel das Flatpak. Dazu müsst ihr zunächst Flatpak einrichten. Der konkrete Weg ist abhängig von eurer Distribution und verbirgt sich hinter dem Link. Wenn das eingerichtet ist, kann das dann über flatpak install flathub org.onionshare.OnionShare installiert werden.

Oben seht ihr das Menü nach dem Start von OnionShare. Im einfachsten Fall klickt ihr auf “Connect to Tor”, OnionShare verbindet sich mit Tor und ihr könnt nun aus vier Möglichkeiten auswählen:

1. Dateien teilen
2. Dateien empfangen
3. Webseite
4. Anonym chatten

Sollte keine Verbindung zu Tor hergestellt werden können, empfehle ich einen Blick in das Handbuch. Dort stehen verschiedene Möglichkeiten beschrieben, die ihr einstellen könnt.

Die weitere Benutzung von OnionShare ist recht einfach. Ihr wählt den entsprechenden Menüpunkt aus, beantwortet ein paar Fragen und schon kann es losgehen.

Wenn ihr Dateien teilen wollt, klickt auf Dateien oder Ordner hinfügen und wählt diese aus. Wenn ihr damit fertig seid, könntet ihr schon mit dem Teilen beginnen. Allerdings solltet ihr über zwei Punkte nachdenken:

1. Standardmäßig lässt OnionShare einen Download zu und schließt danach den Onion Service. Das ist sinnvoll, wenn ihr einer Person die Datei(en) schicken wollt. Wenn sich der Download an mehrere richtet, solltet ihr den Menüpunkt “Dateifreigabe beenden, …” deaktivieren. Dann bleibt der Dienst bis zum Schließen von OnionShare erhalten.
2. Weiterhin richtet OnionShare eine private OnionShare-Adresse ein. Damit wird neben der Onion-Adresse ein privater Schlüssel erzeugt, der an den Empfänger übertragen werden muss. Dies ist einerseits die sichere Variante, andererseits macht das aus meiner Erfahrung mehr Probleme. Daher wähle ich meist aus, dass das ein öffentlicher OnionShare-Dienst ist.

Beide Punkte findet ihr auch bei den anderen Menüpunkten von OnionShare. Wenn ihr eure Auswahl getroffen habt, klickt auf den grünen Knopf und das Teilen kann beginnen.

Die obigen Ansicht zeigt euch OnionShare an, nachdem das Teilen begonnen wurde. Ich habe mal eine Datei geteilt, die nsu-akten-gratis.pdf heißt. Wenn ihr den Artikel lest, wird es die Onion-Adresse nicht mehr geben. Die Datei bezieht sich auf eine Veröffentlichung von Frag den Staat und Jan Böhmermann (Alternative). Das Original liegt hier.

Das Wichtige oben ist die Onion-Adresse. Diese schickt ihr weiter und der Empfänger öffnet diese mit dem Tor-Browser. Dort wird dann folgendes angezeigt:

Mit einem Klick auf “Download Files” werden die Dateien schließlich heruntergeladen. Probiert das mal aus. Ihr werdet sehen, dass dies wirklich einfach ist.

Doch wie funktionieren die anderen drei Punkte? Findet es heraus! Probiert es mal für euch und teilt eure Erfahrungen in den Kommentaren. Ich freue mich, von euren Erfahrungen zu hören.

Was haben die beiden unten stehenden Bilderkollektionen gemeinsam?

Auf den ersten Blick sehen beide komplett unterschiedlich aus und es ist vielleicht noch nicht einmal klar, woher diese stammen. Letzteres lässt sich leicht auflösen, da diese Art von Bildern in Form von Memes öfter auftauchen: Sie sind mit einer künstlichen Intelligenz erzeugt worden. Die Eingabe bei beiden Bildern waren die jeweils meistgenutzten Passwörter, nämlich password und 12345. Jetzt ratet mal, welches Bild welcher Eingabe entspricht.

Das Computerprogramm, welches die Grafiken erzeugt, nennt sich DALL-E und wurde von OpenAI entwickelt. Auf der Webseite CrAIyon könnt ihr mit der Software interagieren. Gebt einfach ein paar Begriffe in das Eingabefeld ein und wartet auf die Ausgabe. Die Idee ist, dass die Software aufgrund der Eingabe ein mehr oder weniger schönes Bild erzeugt. Aber es lässt natürlich beliebige Eingaben zu. Warum also mal nicht etwas “anderes” eingeben?

Im Bereich der IT-Sicherheit fallen einem vielleicht sofort Eingaben wie ' OR 1=1 oder <script>alert(1)</script> ein. Aber was spricht denn gegen Passwörter als Eingabe? Natürlich die Tatsache, dass man selbst verwendete Passwörter nie irgendwo in unklare Webseiten eingibt. Dennoch kann man CrAIyon ein wenig zum Spielen benutzen.

Ich habe mal ein Upload-Verzeichnis (auch als Tor-Onion-Service) für den nächsten Monat freigeschalten. Wenn ihr aus einem (Pseudo-)Passwort ein schönes Bild erzeugen könnt, ladet es mal hoch. Ich werde die dann hier im Blog später zeigen. Also:

Zeigt mir eure Passwörter!

Wenn ich mich auf einem Server per SSH einlogge, starte ich in der Regel direkt die Software screen oder tmux. Dies sind so genannte Multiplexer. Sie erlauben es mir mehrere “Fenster” zu öffnen und auch wenn die Verbindung weg ist, werden die Befehle weiter abgearbeitet.

Im Normalfall gebe ich also zuerst ssh server ein und wenn ich dann auf dem Server eingeloggt bin, gebe ich screen -R oder tmux a ein. Viel schöner wäre es nun, wenn der letzte Schritt automatisiert geschehen würde. Man mag es kaum glauben, aber OpenSSH ist dazu in der Lage.

Hier hilft eine kleine Einstellung in der Konfigurationsdatei. Diese liegt normalerweise im Verzeichnis ~/.ssh und heißt config. Ein Eintrag könnte so aussehen:

Host server
  HostName server.example.com
  IdentityFile ~/.ssh/mein-geheimer-schluessel
  User jens

Mit der Eingabe ssh server verbindet sich SSH zu dem Rechner unter der Adresse server.example.com, nutzt den angegebenen Schlüssel und loggt sich als Nutzer jens ein. Mit den Optionen RemoteCommand und RequestTTY kann ich nun den gewünschten Effekt erzielen:

Host server
  HostName server.example.com
  IdentityFile ~/.ssh/mein-geheimer-schluessel
  User jens
  RemoteCommand screen -RD #oder tmux a
  RequestTTY yes

Nun führt OpenSSH den gewünschten Befehl aus und ich lande sofort in meiner gewünschten Sitzung.

Dies ist natürlich nur eine Kleinigkeit. Aber es nimmt mir einen kleinen Schritt ab und fühlt sich so bequemer an. Vielleicht probiert ihr es auch mal aus und erzählt von euren Erfahrungen.

Ich habe angefangen, Logseq und Obisidan für das Wissensmanagement auszuprobieren. Meine ersten Erfahrungen hatte ich verbloggt. Mittlerweile nutze ich Logseq recht regelmäßig und bin bisher recht zufrieden.

Eine Sache, die mich bislang störte, war der so genannte Date Picker. Damit lässt sich ein Datum aussuchen. Logseq stellt den Wochenbeginn auf Sonntag. “Meine” Woche beginnt jedoch montags. Bisher gab es keine Möglichkeit, dies umzuschalten. Seit kurzem hat sich dies geändert. Der Pullrequest 4949 brachte die Erleichterung. Nun gibt es eine Konfigurationsoption namens :start-of-week. Wenn der Wert auf 0 steht, beginnt die Woche auch am Montag.

Dazu müsst ihr die Einstellungen öffnen und “config.edn bearbeiten” wählen. In der Datei, die sich öffnet, sucht ihr nach der Konfigurationsoption und ändert diese. Ein explizites Speichern ist nicht nötig.

Später ist vorgesehen, dass sich das auch über einen Menüeintrag anpassen lässt.

Im obigen Screenshot seht ihr die Abkürzung des Wochentages. Sat steht für Saturday. Das ist die nächste Kleinigkeit, die mich noch stört. Dies lässt sich nämlich nicht ins Deutsche übertragen. Hierzu gibt es den Issue 5421. Mal sehen, wann und ob dieser behoben wird …

In meinem vorigen Beitrag hatte ich über den vergleichsweise neuen RFC 9116 geschrieben. Der RFC 742 ist hingegen schon 45 Jahre alt. Der definierte damals das Finger-Protokoll, mit dem sich Informationen über Benutzer:innen gewinnen ließen:

jens@host:~$ finger
Login     Name               Tty      Idle  Login Time   Office     Office Phone
peter     Peter Ones        *:3             Apr 19 13:09 (:3)
paul      Paul Twos         *:2             Apr 17 21:01 (:2)
mary      Mary Threes       *:1             Apr  2 22:38 (:1)

Oder für einen bestimmten Username:

jens@host:~$ finger peter
Login: peter                       Name: Peter Ones
Directory: /home/peter             Shell: /bin/bash
On since Sun Apr 17 21:01 (CEST) on :2 from :2 (messages off)
No mail.
No Plan.

Kürzlich fand ich heraus, dass ich auch Personen bei Mastodon, einem Twitter-ähnlichen sozialen Netzwerk, fingern kann. Hierzu benötigt man im wesentlichen die Domain der Mastodoninstanz und den Usernamen. Daraus wird eine Anfrage gebaut, die wieder das .well-known-Verzeichnis nutzt, welches ich schon im letzten Beitrag erwähnt hatte.

Eine Anfrage auf die Adresse https://mastodon.social/.well-known/webfinger?resource=acct:qbi@mastodon.social liefert dann folgendes Ergebnis:

{
  “subject”: “acct:qbi@mastodon.social”,
  “aliases”: [
    “https://mastodon.social/@qbi”,
    “https://mastodon.social/users/qbi”
  ],
  “links”: [
    {
      “rel”: “http://webfinger.net/rel/profile-page”,
      “type”: “text/html”,
      “href”: “https://mastodon.social/@qbi”
    },
    {
      “rel”: “self”,
      “type”: “application/activity+json”,
      “href”: “https://mastodon.social/users/qbi”
    },
    {
      “rel”: “http://ostatus.org/schema/1.0/subscribe”,
      “template”: “https://mastodon.social/authorize_interaction?uri={uri}”
    }
  ]
}

Das bedeutet, den angefragten Username gibt es und dessen Profil ist unter der Adresse https://mastodon.social/users/qbi verfügbar.

Im Allgemeinen heißt dieses Protokoll Webfinger und ist für die Mastodon-Instanzen verfügbar. Probiert es doch mal aus!

Kennt ihr noch die Datei robots.txt, die auf verschiedenen Webseiten hinterlegt sind? Dahinter stand der Robots Exclusion Standard und die verschiedenen Bots sollen zuerst die Seite ausweren, bevor sie eine Webpräsenz indexieren. Daneben entstand auch die Idee für eine humans.txt und mit dem “Erschaffen” des .well-known-Verzeichnisses auf dem Webserver gibt es eine ganze Reihe Dateiformate zur Information oder für andere Zwecke.

Seit April 2022 gibt es nun den RFC 9116 für die Datei security.txt. Diese soll anderen helfen, Sicherheitslücken an die richtige Stelle zu melden. Denn oftmals steht das Problem, dass eine Schwachstelle gefunden wurde und es vielleicht unklar ist, wohin diese zu melden ist.

Mail wäre natürlich eine mögliche Wahl. Im besten Fall existiert sogar eine E-Mail-Adresse namens security@. Aber sehr häufig ist dies nicht der Fall. Mails an info@ oder ähnliche Adressen landen eher im Nirwana oder werden mit Standardtextbausteinen beantwortet. Daher ist ein gezielter, standardisierter Weg gut.

Der RFC 9116 definiert hierfür eben die Datei security.txt, die im Unterordner .well-known einer Webpräsenz liegen muss. Die Datei selbst muss über HTTPS erreichbar sein. Ein korrekter Pfad wäre also https://example.com/.well-known/security.txt.

Doch was darf da drin stehen? Naheliegend sind Kontaktinformationen. Spezieller Informationen, an die man Informationen zu Schwachstellen melden kann. Hierfür ist der Eintrag Contact: gedacht. Dieser muss in der Datei enthalten sein und sollte die Kontaktmöglichkeiten in absteigender Reihenfolge enthalten. Daneben benötigt die Datei zwingend ein Ablaufdatum. Eine Minimalversion der Datei kann also so aussehen:

Contact: mailto:security@example.com
Expires: 2023-05-01T12:13:24+02:00

Weiterhin könnt ihr in der Datei Informationen zu einer Policy hinterlegen, welche Sprachen ihr sprecht, ob ihr Leute einstellt, wer in der Vergangenheit Lücken meldete und einen Verweis zu einem Schlüssel machen. Eine erweiterte Version der Datei sähe also so aus:

Contact: mailto:security@example.com
Contact: +49-123-456-7890
Contact: https://example.com/meldeformular.html
Policy: https://example.com/security-policy.html
Preferred-Languages: de, en
Acknowledgments: https://example.com/hall-of-fame.html
Encryption: https://example.com/pgp-key.txt
Expires: 2023-05-01T12:13:24+02:00

Hier sind mehrere Kontaktmöglichkeiten genannt. Es gibt eine Policy. Die Leute sprechen Deutsch und Englisch und ihr bekommt Infos über andere, die etwas gemeldet haben. Am Schluss findet sich auch ein PGP-Schlüssel. Optimalweise würde der über Web Key Discovery bereit gestellt. Aber das ist ein Thema für einen anderen Beitrag.

Schließlich könnt ihr den Eintrag auch noch mittels OpenPGP signieren. Dann sähe meine obige Datei so aus:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Contact: mailto:security@example.com
Contact: +49-123-456-7890
Contact: https://example.com/meldeformular.html
Policy: https://example.com/security-policy.html
Preferred-Languages: de, en
Acknowledgments: https://example.com/hall-of-fame.html
Encryption: https://example.com/pgp-key.txt
Expires: 2023-05-01T12:13:24+02:00

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.2.19

[Viele Zeichen, die gpg auswerten kann]
-----END PGP SIGNATURE-----

Wenn ihr also eine Schwachstelle gefunden habt, dann lohnt es sich nach der Datei zu schauen und die dort genannten Kontakte anzusprechen. Ich habe mal ein wenig gegraben. Bei den großen, bekannten Seiten, wie Google, Facebook, Twitter, GitHub usw., fand ich jeweils eine solche Datei. Seiten aus dem Microsoft-Universum wie auch viele chinesische Seiten haben keinerlei solche Informationen.

Ansonsten ist das Bild recht gemischt. Während beispielsweise Facebook und WhatsApp eine security.txt anbieten, hat Instagram keine, obwohl alle zum selben Konzern gehören.

Unter andere namhaften Seiten fand ich nichts bei

• Reddit
• Wikipedia
• Zoom
• Netflix
• Stackoverflow
• Apple
• und weiteren

Hier ist also noch ein wenig Arbeit zu tun. Wenn die Datei auch bei euch oder eurem Arbeigeber fehlt, sprecht die doch an und bittet die, diese Informationen bereitzustellen (und natürlich bei Bedarf zu aktualisieren).

Siehe auch:

• Eintrag in der Wikipedia
• Homepage securitytxt
• Beitrag bei KrebsOnSecurity

Update: Ich hatte übersehen, dass das Expires:-Feld auch ein Pflichtfeld ist und habe die obige Beschreibung ergänzt. Vielen Dank an Jürgen für den Hinweis!

Dieser Text ist eine Übersetzung des Blogpostings Why offer an Onion Address rather than just encourage browsing-over-Tor? von Alec Muffett. Alex pflegt auch eine Liste nützlicher Onion-Adressen.

Es gibt eine Reihe von Gründen, eine Onion-Site einzurichten. Ein Reihe von Vorteilen waren für Plattformen wie Facebook, BBC oder NYTimes von Nutzen.

Die ersten Vorteile sind Authentizität und Verfügbarkeit: Wenn du den Tor-Browser benutzt und genau die richtige Onion-Adresse eingibst, bist du garantiert mit der erwarteten Seite verbunden, was du erwartest - oder eben gar nicht.

Das ist für die Menschen sehr einfach zu begreifen und auch einfach zu erklären.

Diese Funktion entschärft Angriffe, die von möglicherweise bösartigen “Tor-Exit-Knoten” ausgehen können. Die Angriffe sind zwar selten, existieren aber dennoch. Die Tatsache, dass du eine “.onion”-Adresse verwendest, setzt voraus, dass du Tor und den Tor-Browser verwendest. Dies entschärft die folgenden möglichen Angriffe:

• landesweite Websperren
• Man-in-the-Middle-Angriffe auf das TLS-Protokoll
• SNI-Filter
• Tracking und Zensur von DNS-Anfragen (betrifft sowohl Clients wie auch Exitknoten)
• Probleme beim Tracking durch Cookies und Fingerprinting-Angriffen
• … sowie eine Reihe weiterer Probleme

Um es anders zu formulieren: Die Werbung für eine Onion-Adresse ist ein implizites Verkaufsargument für die Nutzung von Tor.

Update: Eine Sache, die ich in der ursprünglichen Version dieses Beitrags vergaß zu erwähnen, ist, dass die Nutzung von Onion-Netzwerken für Seiten mit hohem Traffic den Druck auf die Exit-Node-Infrastruktur von Tor reduziert. Denn der Traffic fließt stattdessen durch die größere und reichhaltigere Menge an Middle-Relays, ohne Exit-Nodes und/oder das Klartext-Internet zu nutzen.

Letzteres ist wichtig und bringt uns zum zweiten (dritten?) Satz von Vorteilen:

Der Betrieb einer Onion-Site ist eine Verpflichtung [der Plattform], mit Tor-Benutzer:innen gerecht umzugehen; bei der normalen Benutzung von Tor werden die Benutzer mit allen anderen vermischt, die aus dem Internet kommen, und (seien wir ehrlich) einige Leute benutzen Tor manchmal zum Herunterladen einer kompletten Webpräsenz (Scraping) oder anderem unangenehmen Verhalten.

Das führt zu der Herausforderung, die “Spreu vom Weizen zu trennen”.

Das Einrichten einer Onion-Adresse ist jedoch ein praktischer Schritt, der zeigt, dass die Plattform explizit auf die Bedürfnisse von Tor-Nutzern eingeht, und nun kehrt sich das Problem um: Ein gewisses Maß an schlechtem Verhalten über die Onion-Adresse kann überwacht und als “schlechtes Verhalten” eingestuft werden, was den Tor-Nutzern maximale Freiheit gewährt.

Dies ist eine Angelegenheit, die ich bei Facebook hautnah miterlebt habe und auf einer Tor-Mailingliste beschrieben habe.

Wenn ich die Vorteile in einem Satz zusammenfassen sollte, wäre es folgender: Eine Onion-Adresse ist ein Versprechen und ein Mechanismus, der sicherstellt, dass du die Bedürfnisse der Leute, die Tor benutzen, ernst nimmst.

Anstatt ihnen zum Beispiel eine endlose Reihe von CAPTCHAs auf Basis der IP-Reputation aufzudrängen.