Wiki:SSH

SSH steht für Secure Shell und ist ein verschlüsselndes Netzwerkprotokoll. Dieses kann insbesondere dazu genutzt werden, auf einem lokalen Computer mit einer Shell zu interagieren, welche einem fernen (remote) Computer bzw. Server zugehörig ist, d.h. alle Operationen, abgesehen von den visuellen der Shell dort tätigt.

Sie ist vor allem im Umfeld unixoider Betriebssysteme, etwa *BSD oder GNU/Linux, insbesondere zur Serveradministration, gebräuchlich.

Sie ist aber auch abseits der Serveradministration sehr nützlich, etwa um einen #SOCKS Proxy bereitzustellen.

Verwendung

Unixoide Systeme als Client

Unter unixoiden Betriebssystemen (einschließlich macOS) ist in aller Regel ein SSH client namens ssh vorinstalliert, falls nicht, sollte mensch wissen, wie ein solcher (etwa OpenSSH) nachzuinstallieren ist.

Windows als Client

Für Windows gibt es ein Programm namens PuTTY. Im Folgenden wird vor allem die Benutzung unter unixoiden Betriebssystemen, d.h. insbesondere von der Kommandozeile aus, beschrieben. PuTTY unterscheidet sich vor allem darin, daß die Maus benutzt werden muß.

Interaktive Shell

Um eine interaktive Shell (üblichster Anwendungsfall) auf einem entfernten Rechner zu erhalten, wird in der Regel das Programm ssh von der Kommandozeile aus ausgeführt.

Auf einem unixoiden System, öffne dazu zunächst eine virtuelle Konsole (CTRL+ALT+F<N>) oder ein graphisches Terminal (etwa xterm oder gnome-terminal). Dann tippe folgenden Befehl ein und führe ihn mit einem abschließenden Enter aus.

ssh user@server

Hierbei ist server die IP oder der FQDN (etwa my.example.org) des Zielservers und user ein Username der auf diesem Server existiert und für welchen Authentifizierungsdaten (etwa ein Passwort) vorliegen. Der Präfix user@ kann weggelassen werden, mit der Konsequenz, daß der lokale Nutzername verwandt wird. Dieser muß dann natürlich auch auf dem Zielserver existieren.

Beim ersten Verbinden zu einem neuen Server ist der HostKey zu akzeptieren. Im Idealfall wird die erste Verbindung durchgeführt, wenn der Server sich im lokalen Netzwerk des Clients befindet, um einen MITM-Angriff auszuschließen.

Bei weiteren Verbindungen wird dieser HostKey genutzt, um die Identität des Servers zu überprüfen. Schlägt diese Prüfung fehl, wird ein Fehler angezeigt und die Verbindung wird unterbrochen bzw. nicht zu Ende aufgebaut.

Private / Public keys

SSH erlaubt neben der Passwort-basierten Authentifikation auch eine Authentifikation durch ein Schlüsselpaar (etwa RSA oder ed25519). Die Nutzung solcher Schlüsselpaare zur Authentifikation ist i.A. weitaus sicherer und wird so auch von vielen Servern erzwungen (bzw. zumindest Passwort-basierte Authentifikation unterbunden).

Ein Schlüsselpaar sollte immer auf dem Client erstellt werden. Der Befehl dazu lautet ssh-keygen. Z.B. kann ein ed25519 Schlüsselpaar, welches vielleicht für kram.example.org gedacht ist, wie folgt erstellt werden.

ssh-keygen -t ed25519 -f ~/.ssh/kram_key

Dies erzeugt einen privaten Schlüssel in der Datei ~/.ssh/kram_key und einen öffentlichen in der Datei ~/.ssh/kram_key.pub (SSH Schlüssel werden üblicherweise unter ~/.ssh abgelegt). Bei der Erstellung kann optional ein Passwort gewählt werden, was den privaten Schlüssel auf der Client-Maschine vor unberechtigtem Zugriff schützt.

Um das Schlüsselpaar zu nutzen, ist nun auf dem Server unter dem entsprechenden Nutzerverzeichnis der Datei ~/.ssh/authorized_keys eine Zeile mit dem öffentlichen Schlüssel, d.h. dem Inhalt der Datei kram_key.pub, hinzuzufügen. Eventuell existiert die Datei noch nicht, muß also neu erstellt werden. Wurde die Datei auf den Server kopiert, so genügt es in jedem Fall, dort den Befehl

cat kram_key.pub >> ~/.ssh/authorized_keys

in einer Shell auszuführen.

Eine Verbindung kann dann mittels

ssh -i ~/.ssh/kram_key kraemerin@kram.example.org

aufgebaut werden.

Client Konfiguration

Auf Seiten des Client kann eine Konfiguration insbesondere über die Datei ~/.ssh/config (auf unixoiden Systemen) vorgenommen werden. Hier können etwa Aliase für Servernamen oder IPs vergeben werden, private keys und Nutzernamen zugeordnet werden. Ein Beispiel:

Host kram
  HostName kram.example.org
  User kraemerin
  IdentityFile ~/.ssh/kram_key
Host tomate
  HostName tomatensuppe.kram.example.org
Host eisberg.salat.example.org
  IdentityFile ~/.ssh/eisberg_salat_key

Nun genügen etwa

ssh kram
ssh -i ~/.ssh/tomatenschluessel frische@tomate
ssh gruener@eisberg.salat.example.org

um sich mit den jeweiligen Servern zu verbinden, vorausgesetzt die öffentlichen Schlüssel stehen in der jeweiligen authorized_hosts Datei und auch sonst stimmt alles.

SOCKS Proxy

Ein Proxy (dt. Vermittler*in) erlaubt es, Netzwerkverbindungen, statt auf direktem Wege zum Ziel, über einen Proxy-Server zu schicken. Der Proxy-Server ist hierbei abzugrenzen von einem normalen Netzwerkknoten (Hop). Im Gegensatz zu diesem verrät ein Proxy-Server nichts über den eigentlichen Ursprung der Anfrage (wobei deren Inhalt auf höherer Schicht das natürlich durchaus tun kann), der eigentliche Zielserver hat den Eindruck eine Anfrage direkt von dem Proxy-Server zu erhalten. Die Verbindung zwischen Client und Proxy-Server ist üblicherweise verschlüsselt.

Dies kann etwa dann nützlich sein, wenn mensch auf ein nicht vertrauenswürdiges WLAN-Netzwerk angewiesen ist. Dann erlaubt ein verschlüsselter Proxy, mit dem Internet zu interagieren, ohne daß etwa der Operator des lokalen WLAN Netzes mehr mitbekäme als wohin der Proxy-Tunnel führt (und wann wieviele Daten übertragen werden - Metadaten sind nicht zu unterschätzen [1]).

Achtung: Wenn mensch sich wirklich um Anonymität sorgt, ist Tor sowie der Tor Browser anzuraten.

SOCKS ist ein Proxy-Protokoll (in verschiedenen Versionen). OpenSSH, der Standard SSH Client auf den meisten unixoiden Betriebssystemen, kann einen lokalen SOCKS (5 oder 6) Proxy Server zur Verfügung stellen, der alle Anfragen über SSH an einen anderen Server weiterreicht. Aus Nutzer*innensicht stellt dann also jener andere Server den Proxy dar. Aus Anwendungssicht jedoch ist der Proxy-Server lokal.

Eine entsprechende Verbindung läßt sich aufbauen wie folgt:

ssh -TND local_port kraemerin@kram.example.org

local_port ist hierbei ein frei wählbarer lokaler Port an welchen Anwendungen sich zwecks Nutzung des Proxy via SOCKS wenden können. Als normaler Nutzer können nur nicht privilegierte Ports, also nur höhere, genutzt werden.

SOCKS Proxies werden von sehr vielen Programmen direkt unterstützt, darunter curl, Firefox und Thunderbird. Dort ist dann als Server localhost und als Port local_port anzugeben.

Siehe auch

• ssh(1) -- man page
• ssh_config(5) -- man page
• Wiki:Shell