Ein extrem detaillierter Leitfaden zu SSH (aber nur mit den Dingen, die für mich nützlich sind)

 (grahamhelton.com)
6 Punkte von GN⁺ 2023-08-24 | 1 Kommentare | Auf WhatsApp teilen
  • SSH ist mehr als nur Remote-Zugriff: Es vereint auch Port-Forwarding, Jump Hosts, Konfigurationsdateien und Schlüsselverwaltung; die Webserver-Beispiele lassen sich direkt auf andere Dienste wie RDP oder SQL übertragen
  • Lokales, entferntes und dynamisches Port-Forwarding werden jeweils mit -L, -R und -D eingerichtet; der zentrale Unterschied ist, auf welcher Seite der Port geöffnet wird und wohin der Traffic fließt
  • In Netzwerken ohne direkten Zugriff kann man mit -J Jump Hosts und ProxyJump mehrere SSH-Zwischenstationen verketten, um das Ziel zu erreichen
  • ssh-agent und -A Agent Forwarding erlauben die Nutzung lokaler Schlüssel auch auf entfernten Hosts, sind praktisch, aber die Sicherheitsrisiken durch Missbrauch des Agenten sollten vorher geprüft werden
  • Mit ~/.ssh/config, ssh-copy-id, ssh-keygen und der SSH-Konsole ~?·~C lassen sich wiederholte Optionen vermeiden, Weiterleitungen während der Sitzung hinzufügen sowie Public Keys verteilen und Schlüssel erzeugen oder prüfen

Voraussetzungen zum Verständnis von SSH-Port-Forwarding

  • Den Ablauf von SSH-Port-Forwarding nur anhand von Diagrammen zu verstehen ist schwierig; mit echten Befehlen und Netzwerkszenarien wird es deutlich greifbarer
  • Die Beispiele basieren auf dem Zugriff auf einen Webserver, dieselbe Methode funktioniert aber auch für RDP, SQL und nahezu alle anderen Dienste
  • Häufig verwendete Optionen haben folgende Bedeutung
    • -N: Führt auf dem entfernten Server keinen Befehl aus und öffnet auch keine Shell
    • -f: Schickt SSH in den Hintergrund
    • root@host: Meldet sich als dieser Benutzer auf diesem Host an, um den Tunnel zu erstellen

Lokales Port-Forwarding -L

  • Lokales Port-Forwarding leitet einen Port auf dem lokalen Rechner an einen Port auf dem entfernten Server weiter
  • Beispielszenario
    • internal-web.int hostet eine Webseite, die nur über das Loopback-Interface erreichbar ist
    • Von campfire.int aus ist ein SSH-Zugriff auf internal-web.int möglich
    • Über einen lokalen Port auf campfire.int soll auf den Webserver von internal-web.int zugegriffen werden
  • Verwendeter Befehl
    • ssh -N -f -L 1337:127.0.0.1:80 root@internal-web.int
  • Erklärung der Optionen
    • -L: Gibt lokales Forwarding an
    • 1337:127.0.0.1:80: Bindet den lokalen Port 1337 an 127.0.0.1:80 auf dem entfernten Host
  • Nachdem der Tunnel erstellt wurde, können auf campfire.int Anfragen an den lokalen Port 1337 gesendet werden, um mit Port 80 auf internal-web.int zu interagieren
  • Wichtig ist: Bei -L steht der lokale Port links in der Adressangabe

Entferntes Port-Forwarding -R

  • Entferntes Port-Forwarding macht einen lokal erreichbaren Port über einen Port auf dem entfernten Server verfügbar
  • Beispielszenario
    • internal-web.int hostet eine Webseite, die nur über Loopback erreichbar ist
    • campfire.int kann wegen der Firewall nicht direkt auf internal-web.int zugreifen
    • vuln-server.int ist sowohl von campfire.int als auch von internal-web.int erreichbar
  • Verwendeter Befehl
    • ssh -N -f -R 3000:127.0.0.1:80 root@vuln-server.int
  • Erklärung der Optionen
    • -R: Gibt entferntes Forwarding an
    • 3000:127.0.0.1:80: Bindet Port 3000 auf vuln-server.int an den lokalen Port 127.0.0.1:80
  • Danach kann mit einer curl-Anfrage an vuln-server.int:3000 auf die interne Webseite zugegriffen werden, die auf Port 80 von internal-web.int läuft
  • Wichtig ist: Bei -R steht der lokale Port rechts in der Adressangabe

Dynamisches Port-Forwarding -D und SOCKS-Proxy

  • Dynamisches Port-Forwarding erstellt mit der Option -D einen SOCKS-Proxy und leitet den Traffic über den SSH-Hop
  • Beispielszenario
    • internal-web.int hostet eine Webanwendung, die nur aus dem internen Netzwerk erreichbar ist
    • vuln-server.int befindet sich im selben internen Netzwerk und kann internal-web.int erreichen
    • Von campfire.int aus soll der Traffic über vuln-server.int geproxyt werden
  • Die Konfiguration in /etc/proxychains.conf muss zum Port aus dem SSH-Befehl passen
    • socks5: Lässt proxychains SOCKS5 verwenden
    • 127.0.0.1: Verwendet localhost
    • 8080: Muss mit dem in SSH -D angegebenen Port übereinstimmen
  • Verwendeter Befehl
    • ssh -N -f -D 8080 root@vuln-server.int
  • Nach dem Einrichten des Forwardings kann mit der Einstellung socks5 127.0.0.1 8080 über proxychains curl 192.168.1.185 auf die interne Webseite zugegriffen werden
  • DNS über SOCKS funktioniert je nach Umgebung nicht immer zuverlässig, deshalb wird im Beispiel eine IP-Adresse statt eines Hostnamens verwendet
  • Auch in Firefox lässt sich der SOCKS-Proxy manuell einrichten
    • Pfad: Settings → Privacy & Security → Network Settings
    • Manual proxy configuration auswählen
    • „Proxy DNS when using SOCKS V5“ aktivieren
    • SOCKS host auf 127.0.0.1 und port auf 8080 setzen

Jump Host -J

  • Ein Jump Host ermöglicht die Verbindung zu einem Ziel, das vom aktuellen Host aus nicht direkt erreichbar ist, über mehrere SSH-Zwischenstationen
  • Die Beispielkette lautet campfire.int → vuln-server.int → internal-web.int → dns.int
  • Verwendeter Befehl
    • ssh -J root@vuln-server.int,root@internal-web.int root@dns.int
  • Mehrere Jump-Ziele werden durch Kommas getrennt

Agent Forwarding -A

  • Mit ssh-agent lassen sich auf dem lokalen Rechner per ssh-add <private_key_file> private Schlüssel oder Identitäten hinzufügen
  • Hinzugefügte Schlüssel lassen sich mit ssh-add -l überprüfen
  • Wenn ein Schlüssel zu ssh-agent hinzugefügt wurde, kann SSH diesen verwenden, ohne dass das Passwort erneut eingegeben werden muss; das ist sowohl für Personen als auch für Service-Accounts nützlich
  • -A Agent Forwarding erlaubt auch auf dem verbundenen entfernten Rechner die Nutzung der Schlüssel im lokalen Agenten
  • Vor der Nutzung sollten die Sicherheitsrisiken unter Zero Effort Private Key Compromise: Abusing SSH-Agent for Lateral Movement geprüft werden
  • Beispielbefehl
    • ssh -A -J root@vuln-server.int root@internal-web.int
  • Dieser Befehl verbindet über vuln-server.int zu internal-web.int und erlaubt dabei die Nutzung der Schlüssel aus dem SSH-Agent des lokalen campfire.int
  • Anschließend kann auf internal-web.int ssh root@dns.int ausgeführt werden, ohne einen privaten Schlüssel anzugeben oder Zugangsdaten einzugeben

TTY-Zuweisung -t

  • Die Option -t ist nützlich, wenn auf dem entfernten Server schnell ein Befehl mit interaktivem TTY ausgeführt werden soll
  • Das Beispiel betrifft Befehle wie Vim oder top, die ein TTY benötigen
  • Verwendeter Befehl
    • ssh root@internal-web.int -t top
  • Nach dem Ausführen erhält man auf dem entfernten Server ein TTY mit dem Befehl top

Mit -g auch externe Hosts an lokal weitergeleitete Ports lassen

  • Die Option -g erlaubt es entfernten Hosts, sich mit lokal weitergeleiteten Ports zu verbinden
  • Das ist ähnlich wie lokales Port-Forwarding mit -L, mit dem Unterschied, dass auch externe Rechner diesen „lokalen“ Port verwenden können
  • Beispielszenario
    • Shell-Zugriff auf vuln-server.int ist vorhanden
    • Verbindungen an Port 2222 auf vuln-server.int sollen an Port 22 von internal-web.int geproxyt werden
  • Verwendeter Befehl
    • ssh -N -f -g -L 2222:localhost:22 root@internal-web.int
  • Erklärung der Optionen
    • -g: Erlaubt entfernten Hosts die Verbindung mit lokal weitergeleiteten Ports
    • -L: Gibt lokales Forwarding an
  • Selbst wenn die SSH-Verbindung an Port 2222 von vuln-server.int erfolgt, befindet sich die eigentliche Shell auf internal-web.int

SSH-Konsole ~? und Forwarding während der Sitzung

  • Die SSH-Konsole ist eine versteckte Funktion, mit der sich SSH selbst steuern lässt, ohne direkt mit dem entfernten System zu interagieren
  • Das ist nützlich, wenn die Shell kaputt ist oder die SSH-Sitzung selbst kontrolliert werden muss
  • Die Hilfe-Konsole lässt sich mit ~? öffnen
  • Nützliche Optionen
    • ~.: Beendet die aktuelle SSH-Sitzung
    • ~C: Öffnet die SSH-Konsole, um Forwarding-Optionen hinzuzufügen
  • Auch wenn bereits mit einem normalen ssh-Befehl eine Verbindung zu vuln-server.int besteht, kann durch Eingabe von ~C und anschließend -D 8080 diese Sitzung wie eine dynamische Forwarding-Sitzung genutzt werden
  • Wenn auf campfire.int in /etc/proxychains.conf Port 8080 konfiguriert ist, kann proxychains genutzt werden, als wäre die Sitzung von Anfang an mit ssh -D gestartet worden

SSH-Konfigurationsdatei ~/.ssh/config

  • Die SSH-Konfigurationsdatei befindet sich unter ~/.ssh/config und spart Zeit, indem sie häufig wiederholte SSH-Optionen speichert
  • SSH wertet diese Datei beim Verbindungsaufbau aus und verwendet die passende host-Konfiguration für das Ziel
  • Argumente auf der Kommandozeile haben Vorrang vor der Konfigurationsdatei
    • Wenn in der Konfigurationsdatei beispielsweise für internal-web.int der Benutzer root festgelegt ist, bei ssh graham@internal-web.int aber graham angegeben wird, versucht SSH die Anmeldung als graham
  • Beispiel einer Grundkonfiguration
# You can put comments with a `#` at the beginning of the line only.
host internal-web.int
    User root
    IdentityFile /home/smores/ssh_agent/internal-web-no-pw
    Port 2222
  • Verarbeitungsablauf bei ssh internal-web.int
    • SSH gleicht internal-web.int aus der Kommandozeile mit host internal-web.int in ~/.ssh/config ab
    • Bei einem Treffer werden Optionen, die nicht in der Kommandozeile angegeben wurden, aus der Konfigurationsdatei übernommen
    • Gibt es keinen Treffer, werden nur die in der Kommandozeile definierten Optionen verwendet

Häufig verwendete SSH-config-Schlüsselwörter

  • IdentityFile /path/to/private_key
    • Gibt den privaten Schlüssel an, der für den Host verwendet werden soll
    • Entspricht ssh -i
  • ForwardAgent
  • ProxyJump root@internal-web.int
    • Gibt den Server an, über den der Traffic geproxyt werden soll
    • Entspricht der Option -J
    • Im Beispiel wird gezeigt, dass zuerst eine Authentifizierung an vuln-server.int erforderlich ist und der Traffic dadurch über diesen Host läuft
  • Match
    • Wendet SSH-config-Schlüsselwörter abhängig von Bedingungen an
    • Im Beispiel wird ProxyJump im Match-Block verwendet, wenn der Exit-Code von export | grep PROXYME=TRUE gleich 0 ist
    • Wenn die Umgebungsvariable PROXYME nicht vorhanden ist, wird nur der normale Block host internal-web.int verwendet
    • Nach export PROXYME=TRUE führt derselbe Befehl ssh internal-web.int erst zur Authentifizierung an vuln-server.int und anschließend zu einer Shell auf internal-web.int
  • scp und einige SSH-basierte Utilities können in der Regel ebenfalls die SSH-Konfigurationsdatei verwenden
    • In Umgebungen, die sie nicht automatisch verwenden, kann sie mit -F ~/.ssh/config explizit angegeben werden

Public Key kopieren ssh-copy-id

  • ssh-copy-id ist ein kleines Utility, um einen Public Key schnell auf einen Server hochzuladen
  • Verwendeter Befehl
    • ssh-copy-id -i internal-web root@internal-web.int
  • Erklärung der Optionen
    • -i internal-web: Gibt den Namen des privaten Schlüssels an, der zur Serverauthentifizierung verwendet wird
    • root@internal-web.int: Gibt den Server an, auf den der Public Key hochgeladen werden soll

Schlüssel erzeugen und prüfen ssh-keygen

  • ssh-keygen ist ein Utility zum Erzeugen eines Paars aus privatem und öffentlichem Schlüssel
  • Es wird im Allgemeinen empfohlen, mit der Option -b eine größere Schlüssellänge anzugeben
  • In der Beispielumgebung betrug die Standard-Schlüssellänge 3072
  • Der Standardalgorithmus ist RSA, mit dem Flag -t kann aber ein anderer Algorithmus gewählt werden
    • Beispiel: ssh-keygen -t ecdsa -b 521
  • Fingerabdruck und Byte-Größe eines Schlüssels lassen sich mit folgendem Befehl prüfen
    • ssh-keygen -lf <file-name>

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-08-24
Meinungen auf Hacker News

  • Hier fehlt eine überraschend einfache Direktive: In sshd_config setzt man zum Beispiel AuthorizedKeysCommand /usr/bin/php /etc/ssh/auth.php %u und lässt das Skript dann https://github.com/{$user}.keys von GitHub abrufen.
    Natürlich ist das kein Code in Produktionsqualität, aber es zeigt den Kern der Idee.
    Nachdem geprüft wurde, ob die Person zu einer GitHub-Organisation/-Gruppe gehört, kann man den Server-Login erlauben, sofern der Benutzer existiert und etwa mit nss-ato gemappt ist.
    Beim Onboarding/Offboarding von Personen reicht es dann, sie einer GitHub-Gruppe hinzuzufügen oder daraus zu entfernen, um den Zugriff auf Maschinen zu gewähren oder zu entziehen – das reduziert den Aufwand.

    • Amazon Linux macht etwas Ähnliches, ist aber vermutlich wegen der Produktionsqualität deutlich komplizierter.
      In Amazon Linux 2 und älter wird die openssl-Kommandozeile aufgerufen, um das Format einzelner Schlüssel in der Datei authorized_keys zu prüfen; das ist fest auf RSA verdrahtet, sodass man sich auf Amazon-Linux-2-Hosts nicht mit ed25519 authentifizieren konnte, obwohl die OpenSSH-Version ed25519 unterstützt.
      Theoretisch ist das gut, weil es ein nettes Feature¹ ermöglicht; praktisch macht es aber auch für Leute, die dieses Feature gar nicht nutzen, die Grundfunktion kaputt und lässt Amazon Linux weniger vertrauenswürdig wirken.
      Als ich zum ersten Mal auf dieses Problem stieß, wollte ich per SSH auf eine Maschine zugreifen, die einem Cloud-first-DevOps-Kollegen gehörte, und weil ich sie nicht direkt anfassen konnte, war die Diagnose schwierig.
      Er kannte sich mit AWS gut aus, aber weniger mit Linux, wusste also nicht, wo er nachsehen sollte; er hatte Amazon Linux gewählt, weil es eine Distribution des Cloud-Plattformbetreibers ist und daher „kompatibler“ sein müsse – aber „kompatibler“ bedeutete hier in Wirklichkeit „mehr dumme Überraschungen“.
      ¹ https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-...
    • Wenn ich so etwas sehe, finde ich es schade, auf der Netzwerkseite zu sitzen.
      Weil „das Netzwerk funktioniert nicht richtig“ mein Zuständigkeitsbereich ist, verpasse ich solche coolen Features.
    • Für diesen Zweck sollte man stattdessen besser SSH-Zertifikate verwenden.

  • Viele wissen vermutlich nicht, dass der OpenSSH-Konfigurationsparser doppelte Direktiven ignoriert und von identischen Direktiven nur die erste wirksam ist.
    In den meisten Konfigurationsparsern oder Rule Engines überschreiben später kommende Direktiven frühere, daher ist das ziemlich kontraintuitiv.
    Das mag nach einer Kleinigkeit klingen, aber wenn Menschen oder Software Defaults wie in /etc/ssh/sshd_config ändern, neigen sie dazu, Änderungen ans Ende der Datei oder eines Direktivenblocks anzuhängen – und erwarten, dass sie angewendet werden.
    Auch Sicherheitsfirmen und -organisationen sowie mehrere SSH-Bastion-Produkte machen das falsch; ebenso berücksichtigen die CIS-Benchmarks-Empfehlungen und die meisten CIS-Audit-Tools von Drittanbietern die Priorität nicht oder behandeln sie falsch.
    Um zu prüfen, ob OpenSSH-Konfigurationsdirektiven wie erwartet definiert sind, sollte man nicht die Konfigurationsdatei von Hand durchsehen, sondern mit sshd -T oder ssh -G die abgeleitete interne Konfiguration ausgeben lassen.

    • Die Datei sudoers verhält sich genauso.
      Bei Software für Benutzerauthentifizierung/-autorisierung halte ich dieses Verhalten für wünschenswert.
      Denn so lassen sich leicht Einstellungen erstellen, die nicht überschrieben werden können, indem jemand eine neue Datei in einem whatever.conf.d-Verzeichnis hinzufügt.
      Man definiert diese Einstellung in der Hauptkonfigurationsdatei, bevor whatever.conf.d/* eingebunden wird, und versieht diese Datei mit einem besonderen Schutz.
      Selbst wenn niemand versucht, Kontrollen zu umgehen, ist das für Konfigurationsmanagement vorteilhaft: Wenn ein Neuling ohne den Gesamtkontext eine neue Datei hinzufügt oder irgendein Paket seltsame Defaults für seinen Dienst installiert, behalten die Basiseinstellungen ihre Priorität.
      Der Grund, warum man in anderen Kontexten häufiger das gegenteilige Verhalten sieht, ist, dass dort nicht „Basiseinstellungen“ gewünscht sind, sondern Defaults im strengen Sinn, die verwendet werden, wenn Benutzer/Entwickler/Administratoren nichts explizit gesetzt haben.
    • Einige Direktiven gelten als mehrfach zulässig. Zum Beispiel AllowUsers.
      Allerdings hat NixOS gestern plötzlich die Merge-Reihenfolge geändert, wodurch mein AllowUsers unter ein Match in einer anderen Datei gerutscht ist und wirkungslos wurde.

  • Die Erklärung im Artikel, dass bei -L fürs lokale Forwarding „lokal“ links in der Adresse steht und bei -R fürs Remote-Forwarding der lokale Port rechts in der Adresse steht, ist der wichtigste und prägnanteste Satz.
    -L und -R haben mich von Anfang an verwirrt, und es ist ziemlich lästig, dass sich je nach L/R ändert, welche Port-Instanz lokal ist.
    Ich verstehe, dass -L und -R die beabsichtigte Richtung ändern, also wo Initiator und Responder sitzen; aber man hätte port:address:port auch immer local:binding:remote bedeuten lassen und mit -L/-R festlegen können, welche Seite empfängt und welche sendet.

    • Am einfachsten merkt man sich: -L lauscht auf dem lokalen Port, dessen Nummer direkt danach kommt, und -R lauscht auf dem Remote-Port, dessen Nummer direkt danach kommt.
      Das restliche host:port ist nur das übliche Format, das angibt, wohin verbunden werden soll.
      Da es sich um Port-Forwarding durch einen SSH-Tunnel handelt, ergibt sich auch natürlich, dass der Host von der Seite gegenüber dem lauschenden Port durch den Tunnel kontaktiert wird.

  • Eine weniger bekannte, aber nützliche Funktion von SSH ist Connection Multiplexing
    Statt eine neue TCP-Verbindung aufzubauen und die Authentifizierung erneut zu durchlaufen, kann man eine bestehende Verbindung wiederverwenden
    Das Protokoll selbst kennt das Konzept von Channels, und jeder Datenframe enthält Metadaten zur Unterscheidung der verschiedenen Streams; diese Funktion nutzt genau das
    Der große Vorteil ist, dass spätere Sessions nicht erneut die komplette Authentifizierung durchführen müssen
    Besonders praktisch ist das, wenn auf der Gegenseite kein tmux o. Ä. läuft und man mehrere Panels über mehrere Terminalfenster nutzt; noch deutlicher spürt man es, wenn die Authentifizierung ein paar Sekunden dauert, etwa wegen einer Passphrase oder eines HSM-Touches
    Es gibt auch eine Einstellung zum „Verbindung offen halten“, sodass man sich nicht jedes Mal neu authentifizieren muss, wenn man zwischen ein paar Servern wechselt
    Insgesamt sehe ich es als nette Funktion, aber nicht als etwas, das einem das Leben verändert
    Bei manchen Servern ist diese Funktion deaktiviert; ihr Fehlen fällt stärker auf, wenn sie aus ist, als ihre Präsenz, wenn sie an ist
    Mehr dazu: https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Multiplexing

    • Wenn die Latenz zwischen Client und Server hoch ist, ist der Unterschied enorm
      SSH ist, anders als TLS, das darauf optimiert ist, Roundtrips zu reduzieren, ein ziemlich „gesprächiges“ Protokoll, und diese Multiplexing-Option ist fast die einzige Ausnahme
    • Beim Einsatz eines ProxyJump-Bastion-Hosts kann es Ansible deutlich angenehmer machen

  • Wenn man viele Hosts in ~/.ssh/config hat, kann man mit der Include-Direktive, die Wildcards unterstützt, verhindern, dass die Datei zu unübersichtlich wird
    Zum Beispiel kann in ~/.ssh/config Include config.d/*.conf stehen, während man die jeweiligen host-, hostname- und user-Einstellungen auf Dateien wie ~/.ssh/config.d/work.conf oder client1.conf verteilt

    • Auch die Host-Direktive unterstützt Wildcards
      Man kann zum Beispiel host *_work hinzufügen und dort gemeinsame Einstellungen für alle Arbeits-Hosts wie host1_work hinterlegen
    • Ein weiterer Tipp: Include kann innerhalb von Host-/Match-Direktiven stehen
      Wenn man etwa in ~/.ssh/config Host proj1.*.corp und Include ~/.ssh/proj1.conf setzt, kann man projektspezifische Matches weit oben in der Nähe halten und muss beim Review weniger einzelne Dateien durchsuchen

  • Beim Forwarding verwende ich fast nie -f
    Es kann zu einer Fußangel werden, weil es schwerer macht zu erkennen, welche Forwardings noch offen sind und laufen
    -t ist ein schöner Trick und war für mich eine unbekannte Funktion
    Ein wichtiger Punkt in der Liste der ~-Escape-Kommandos, den man leicht übersieht: Auch innerhalb verschachtelter Sessions kann man Escapes verschachteln
    Das ist nützlich, wenn man aus irgendeinem Grund -J nicht verwendet
    Die Liste passt gut zu den nützlichen Dingen, und ich habe zusätzlich noch ein paar Sachen gelernt

    • -t ist großartig. Ich verwende es etwa so: ssh -t my-dev-vps 'tmux new-session -A -s main', damit ich bei jedem Start direkt an die vorherige Stelle meiner tmux-Session zurückkehre
    • Wenn auf dem Zielserver mehrere Shells offen sind, hat man weiterhin dasselbe Problem
      Es wäre schön, wenn SSH den Forwarding-Status auf vernünftige Weise ausgeben könnte, statt dass man selbst die Prozessliste durchwühlen muss

  • Es gibt aktuell einen Pull Request, der Unterstützung für AF_UNIX hinzufügt; wenn das landet, werden alle möglichen interessanten Forwardings möglich
    Denn dadurch wird es einfacher, SSH-Verbindungen über beliebige lokale Prozesse zu proxien, und dieser Prozess kann dann frei entscheiden, wie er die Daten bis zum Remote-Ende weiterleitet
    https://github.com/openssh/openssh-portable/pull/431

    • Was mich interessiert, ist -D mit AF_UNIX, aber es ist gut, wenn alles auf AF_UNIX laufen kann
      Seit etwa einem Jahr scheint curl über die ALL_PROXY-Syntax socks5://localhost/path bzw. socks5h AF_UNIX-SOCKS nutzen zu können
      Das scheint hinzugefügt worden zu sein, weil Tor AF_UNIX-SOCKS-Proxys verwendet
      Es wäre gut, Netzwerkzugriff über normale Unix-Berechtigungen konfigurieren zu können; persönlich fände ich es sogar noch besser, TCP/IP komplett aus dem Kernel verdrängen zu können

  • Als ich die SSH-Konsole zum ersten Mal gesehen habe, war ich schockiert
    Ein Kollege zeigte mir ~#, und es fühlte sich an, als hätte ich ein geheimes Cheat-Menü entdeckt, wie aus einem SEGA-Genesis-Spiel

  • Warum die Tilde? Weil rlogin und rsh sie verwendeten
    Warum verwendeten rlogin und rsh die Tilde? Weil cu sie verwendete
    Warum cu? Wenn man ein Modem oder eine serielle Leitung hatte, kommunizierte man darüber mit cu, und man musste Hayes-Codes senden; wenn man aber die Escape-Sequenz der Hayes-Codes verwendete, landete man im Modem, also brauchte man ein eigenes Signal, um aus cu herauszukommen
    Warum nicht ^[? Weil das Telnet ist
    Wenn man sich also per Telnet mit einem Host verband und dann mit cu ein Modem ansprach, brauchte man eine separate Escape-Syntax, um zu cu zurückzukehren, ohne aus Telnet auszusteigen
    Am Ende ist das eine Struktur aus endlos gestapelten Escape-Syntaxen
    Und tatsächlich ist es keine Tilde, sondern: Tilde

    • Ich dachte, es sei die Reihenfolge CR, Tilde, .; habe ich das die ganze Zeit falsch benutzt?

  • Der Abschnitt zu ssh-copy-id erklärt erst, dass der Befehl den öffentlichen Schlüssel hochlädt, wechselt dann aber plötzlich dazu, dass er den privaten Schlüssel hochlädt; das wirkt wie ein Tippfehler
    Außerdem lädt dieser Befehl den Schlüssel nicht einfach nur hoch, sondern hängt ihn an ~/.ssh/authorized_keys an, was deutlich nützlicher ist
    Abschließend: Im Abschnitt zu ssh-keygen gilt nach dem, was ich in letzter Zeit gelesen habe, heute ed25519 gegenüber ecdsa als bevorzugt