Die Geschichte
SSH (SecureSHell) wurde schon 1995 von Tatu Ylönen an der Universität Helsinki entwickelt. Es war als Ersatz für das altehrwürdige rsh gedacht. Angeblich hatte er die ständigen Angriffe aus dem Netz satt und war sogar selbst wohl einmal Opfer eines solchen Angriffs. (Was erklären könnte, warum SSH so gut ist. ) Da es schnell populär wurde, und bald die ersten Flaws entdeckt wurden, kam bereits 1996 die Version2 heraus. Das openSSH Projekt, das heute alle freien Distris einsetzen, spaltete sich von der Mutter 1999 ab. Es ist heute Standard, und die Protokollversion SSH1, der Urvater, ist heute längst deaktiviert und findet keine Verwendung mehr. Wir setzen ausschließlich die Protokollversion SSH2 ein.
Dabei handelt es sich nicht nur um ein Programm, mit dem man sich via Internet auf einem Remotehost einloggt, und dort eine Shell für den User dann bereitsteht. Tatsächlich ist das mittlerweile ein ganz eigenes Universum an Tools. Wir nennen das die openSSH Suite.
Eine Paketsuche dürfte - je nach Distri - gut 100 Tools listen.
Möglich wird das, weil man in SSH sogar eigene Subsysteme definieren kann. Heute liegen schon fünf solcher Subsysteme als RFC vor. (RequestForComment heißen traditionell die "Vorschläge", wie ein interoperables Protokoll, oder Gerät arbeiten muss, damit Maschinen über das Netzwerk zusammenarbeiten können. Quasi die Internetgesetze der technischen Umsetzung für die Netzkommunikation ). Für uns das einzig relevante ist das sftp Submodul (SecureFileTransferProtokol).
Es sollte heute auf KEINEM Rechner mehr irgendein FTP Server laufen! Das ist ein vorsätzliches Sicherheitsloch -egal, was deren Fans zetern.
Später mag noch das ssh-auth Subsystem in den Focus kommen - falls ich dazu später noch Lust habe.
Heute ist die SSH- Suite Standard. Sie ist das Rückgrat in allen Rechenzentren. Eine Unzahl von Tools beruht darauf. So gibt es viele Tools, die gleichzeitig auf zig Hosts Kommandos ausführen mit jeweils komplett verschlüsselten Verbindungen zur Verfügung stellen. Man kann auch z.B. mit einem kurzen SSH- Befehl auf einem Remotehost z.B. Firefox ausführen lassen, dessen Fenster dann auf dem lokalen Desktop dargestellt wird, wobei Keyboard und Mouse dann ebenfalls über die SSH- Verbindung getunnelt werden.
Eben ein Universaltool für jedweden Zweck, das sichere Kommunikationsstrecken sauber verschlüsselt dargestellt wird.
SSH Basics und was da wirklich passiert
Beim Anlegen eines neuen Useraccounts werden von /etc/skel alle Dateien und Verzeichnisse in dieses neue Home kopiert.
Das kann dann so aussehen:
Hier ist noch weit und breit nichts von SSH zu sehen. (Blaue Einträge sind Verzeichnisse.). Man beachte das -ls zur Anzeige aller Dateien, auch der "Dotfiles".
Sobald jedoch zu diesem Account eine SSH- Verbindung hergestellt wurde, oder eine Verbindung versucht wurde, ändert sich das. Bei einem ablehnten Versuche sieht das dann so aus:
Der rote Kasten im oberen grünen Kasten zeigt, dass dieser Verbindungsversuch ein Unterverzeichnis namens .ssh angelegt hat. Darin befindet sich, wie der zweite grüne Kasten zeigt, eine einzige Datei namens known_hosts.
Und das cat .ssh/known_hosts im dritten grünen Kasten zeigt letzlich den Inhalt dieser known_hosts.
Diese Datei wird also automatisch angelegt, ebenso, wie das Verzeichnis. Das Format war früher®™ noch halbwegs lesbar - heute ist es nicht einmal mehr leicht dechiffrierbar. Das brauchen wir auch nicht. Für uns ist nur wichtig, dass wir wissen, dass es automatisch erzeugt wird.
Das Format der .ssh/known_hosts ist einigermaßen kompliziert. Die roten Kästen sollen zeigen, dass die Felder dieser Datei hauptsächlich durch Leerzeichen getrennt sind. Die einzelnen Felder sind aber noch weiter unterteilt - und sind je nach der verwendeten Verschlüsselung anders unterteilt. Wie die blauen Pfeile andeuten gehören dazu +-Zeichen, Slashes und Pipe- Zeichen, wie sie am Zeilenanfang zu sehen sind. Im Prinzip sind das alles Prüfsummen und verschlüsselte Angaben zum verwendeten Verschlüsselungsmechanismus und zum verbindenden Host. Findet sich am Ende eines Feldes ein =-Zeichen, so ist das Teil einer verschlüsselten Sequenz. Da in der modernen, asymmetrischen Verschlüsselung aus Performancegründen hauptsächlich Blockchiffren verwendet werden, kommt es häufig vor, dass der letzte Block des Chiffrats kürzer ist, als die jeweilige Blocklänge vorschreibt. Dadurch weiß der Entschlüsselungsalgorithmus, dass er zuerst am Ende so viele "Endezeichen" einfügen muss, bis der Block "vollständig" ist. Erst danach kann der letzte Block des Chiffrats tatsächlich entschlüsselt werden. Der ganze Kladaradatsch ist übrigens Base64 codiert.
Muss man aber alles nicht wissen. Ich höre förmlich das Gott-sei-Dank-Soifffzen
Es reicht für uns völlig aus, wenn wir uns das folgende merken:
Merke:
- Die known_hosts wird automatisch angelegt.
Man kann sie bedenkenlos löschen. - Sie enthält verschlüsselt den Hostnamen (oder die IP- Adresse), Angaben zur tatsächlich verwendeten Verschlüsselung und andere Kleinigkeiten.
Also fast. Wir werden später noch einmal auf diese Datei zurückkommen.
Wenn einmal irgendetwas nicht so klappt, ist das -verbose Flag von Vorteil. Es taucht im nexten (hübsche Schlechtschreibung) Bild dann als debug1: auf Man kann bis zu drei -vvv schreiben, was dann eben als debug2: oder debug3: erscheint. Viel zu Lesen für kalte Winterabende, wenn der Hacker ohne Netz am Rechner einsam darbt.
Schon im Debuglevel 1 tauchen viele Zeilen auf - bei Debuglevel 3 wird es ein kompletter Ulysses.
Auch hier sind wir bescheiden und beschränken uns auf Debuglevel 1. Dieses Level zeigt uns aber schön, welche Phasen eine solche SSH- Verbindung durchläuft. Noch BEVOR überhaupt eine User Passwortabfrage, oder die "persönlichen Schlüssel" zum Einsatz kommen.
Die ganze Sequenz dient nur der Verschlüsselung zwischen den beiden Rechnern. Die Authentifizierung und das Bereitstellen eines Terminals mit einer Shell erfolgt komplett verschlüsselt. Und hier endlich das Debug Dingens: