secure shell (ssh)

Die erste Version des Protokolls (SSH-1) wurde 1995 von Tatu Ylönen als Ersatz der Berkeley Services unter Unix einschließlich der Befehle rsh (remote shell), rcp (remote copy) und rlogin (remote login) entwickelt. 1996 wurde mit SSH-2 eine überarbeitete Version des Protokolls entwickelt. Sie ist inkompatibel zu SSH-1. Seit 1999 existiert das SSH-Protokoll in zwei Implementationen: Als Open-Source-Software (OpenSSH) des OpenSSH-Projekts und als proprietäre Software (Produktname: SSH Tectia), entwickelt und vertrieben von der Firma SSH Communications Security.
SSH-1 wird NICHT mehr verwendet, weil es als unsicher einzustufen ist.

Public-Key-Authentifizierung

Der Server identifiziert sich dem Client gegenüber mit einem RSA-oder einem DSA-Zertifikat, der Client kann sich per Public-Key-Authentifizierung mit einem privaten Schlüssel, dessen öffentlicher Schlüssel auf dem Server hinterlegt ist, authentifizieren. Die Public-Key-Authentifizierung ermöglicht, dass sich Client-Computer ohne Benutzerinteraktion auf SSH-Servern einloggen können, ohne dass dabei ein Passwort auf dem Client im Klartext gespeichert werden muss.

  1. ssh-keygen
  2. ssh-copy-id
  3. ~/.ssh/authorized_keys
ssh-keygen
Mit Hilfe des Kommandozeilenprogramms ssh-keygen kann man ein Schlüsselpaar erzeugen
tux@linux:~$ ssh-keygen -t rsa -b 2048
Mit der Option -t kann man den Algorithmus der Schlüssel, die erzeugt werden sollen angeben. Gültig wären die Angaben rsa1, rsa , dsa und ecdsa. rsa1 gilt für das SSH1-Protokoll, das NICHT mehr benutzt werden sollte!
Da DSA (Digital Signature Algorithm) und ECDSA (Elliptic Curve Digital Signature Algorithmus) sehr recheninstensiv sind, wird meist RSA (Anfangsbuchstaben der Nachnamen der Entwickler Rivest, Shamir und Adleman) genutzt.
Mit der Option -b kann man die Länge des Schlüssels angeben.
Eine Schlüssellänge von 2048 bit sollte man als Minimum ansehen. Das eigentliche Minimum an Schlüssellänge ist 768 bit, die maximale Schlüsselange beträgt 32768 Bit!
Das Ergebnis der Kommandozeile sind zwei Dateien mit den Schlüsselpaaren:
Für Protokoll 1 (RSA1) ~/.ssh/identity (der private SSH1-Schlüssel) und ~/.ssh/identity.pub (der öffentliche SSH1-Schlüssel),
für Protokoll 2 (RSA, DSA, ECDSA) ~/.ssh/id_{rsa,dsa,ecdsa} (der private SSH2-Schlüssel) und ~/.ssh/id_{rsa,dsa,ecdsa}.pub (der öffentliche SSH2-Schlüssel).
ssh-copy-id
Mit Hilfe des Kommandozeilenprogramms ssh-copy-id kann man den öffentlichen Schlüssel auf den Server kopieren
tux@linux:~$ ssh-copy-id -i ~/.ssh/id_rsa.pub user@server
Mit der Option -i gibt man den Pfad zum öffentlichen Schlüssel an.
Falls ssh-copy-id auf dem System nicht verfügbar ist, kann man auch mit folgender Kommandozeile das gleiche Ziel erreichen
cat ~/.ssh/id_rsa.pub | ssh user@remote-system 'umask 077; \
cat >>.ssh/authorized_keys'
Die umask 077 dient dazu, dass die Datei authorized_keys den Mode 0600 bekommt, weil sonst der SSH-Server (sshd) die Datei nicht akzeptiert.
~/.ssh/authorized_keys
Auf dem Remotesystem wird dann der lokale öffentliche Schlüssel in die Datei ~/.ssh/authorized_keys aufgenommen.
Auch wird in der lokalen Datei ~/.ssh/known_hosts der öffentliche Schlüssel des Remotesystems aufgenommen.

Beispiel zu ssh-keygen
tux@linux:~$ ssh-keygen -t rsa -b 2048
Generating public/private rsa key pair.
Enter file in which to save the key (/home/tux/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/tux/.ssh/id_rsa.
Your public key has been saved in /home/tux/.ssh/id_rsa.pub.
The key fingerprint is:
84:55:ee:67:5a:72:E4:57:5f:b9:b4:45:2a:fe:56:a1 tux@linux
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|                 |
|                 |
|         +    .  |
|        S    E   |
|         .  + +  |
|          .o . o.|
|         o.oo. oo|
|          ==o.BO+|
+-----------------+
tux@linux:~$
Beispiel ssh-copy-id
tux@linux:~$ ssh-copy-id -i ~/.ssh/id_rsa.pub tuxa@linux2
tuxa@linux2's password:
Now try logging into the machine, with "ssh 'tuxa@linux2'", and check in:
  .ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.
tux@linux:~$

Haben Sie noch weiter Fragen?

Kontaktieren Sie mich unter:


info@bohnsack-it.de