SSH2 mit Public und Private Key einrichten

SSH steht für Secure Shell. Das wiederum ist der Name für sowohl das Protokoll, als auch Programme, mithilfe derer sich verschlüsselte und authentifizierte Verbindungen zu anderen Servern herstellen lassen. SSH wird weitestgehend genutzt, um Kommandozeilen (CLI) auf Servern zu bedienen oder Scripte auf anderen Rechnern auszuführen. Die Kommunikation erfolgt dabei bidirektional.

Das Protokoll kann noch für viele weitere Anwendungsfälle eingesetzt werden als nur den, Terminals auf Servern zu bedienen. Es können auch andere unsichere Verbindungen darüber geleitet, damit verschlüsselt und sicher übertragen werden (Port Forwarding). Bildschirminhalte können transportiert und Dateien übertragen werden.

WANN WIRD SSH NICHT VERWENDET?

SSH benutzt man beispielsweise dann nicht, wenn man eine Kommandozeile für Aufgaben auf dem eigenen Rechner benutzen möchte. Wenn keine verschlüsselte Verbindung notwendig ist - weil die Inhalte zur freien Verfügung stehen wie es beim Online-Radio-Streaming der Fall ist - benötigt man auch einen anderen, geeigneteren Übertragungsweg. Im Falle des Streamings werden vom eigenen Rechner auch keine Daten gesendet. So ist ein Protokoll, das lediglich auf den Empfang ausgerichtet ist, sinnvoller. Für den Besuch von Webseiten eignet sich das HTTP bzw. das verschlüsselte HTTPS.

(Das P steht bereits für Protokoll - so wie das O in SEO für Optimierung steht. Man hüte sich vor HTTP-Protokollen und SEO-Optimierung!)

Einrichtung

Um eine Verbindung von einem lokalen Rechner zu einem Server herzustellen, benötigt man natürlich einen Computer und ein entsprechendes Ziel. Das Ziel muss nicht unbedingt ein teurer Root-Server sein. Der eigene Rechner oder eine Virtuelle Maschine auf dem eigenen Rechner reichen völlig aus. Cloud-Hosting-Pakete kommen, wenn sie SSH beinhalten, meist mit Konfigurationsoberflächen, welche die Einrichtung und Verwaltung deutlich vereinfachen.

REMOTE FIRST

Davon ausgehend, dass kein Cloud-Server vorliegt, sondern eine Virtuelle Maschine mit einem Ubuntu ab der Version 14.04, starten wir die Einrichtung des SSH-Dienstes.

Der Dienst wird benötigt, damit eingehende Verbindungen vom Server akzeptiert werden können. Standardmäßig lauscht der Service auf Port 22. Dies kann in der Konfiguration geändert werden und wird von Sicherheitsexperten auch des Öfteren empfohlen. Im Bereich des Managed Hosting kann man den Port für gewöhnlich nicht ändern.

Installation des Dienstes
sudo apt install openssh-server
Hardening
sudo $EDITOR /etc/ssh/sshd_config
- Sicherstellen, dass die Version 2 verwendet wird:
  Protocol 2
- Deaktivieren des root-Logins:
  PermitRootLogin no
- Whitelisting, um logins für alle anderen Benutzer zu verbieten (MYUSER durch deinen Benutzernamen ersetzen):
  AllowUsers MYUSER
- Optional: SSH-Port ändern:
  (Vorher muss ein freier Port gefunden werden)
  (Anm: 1337 und 2222 sind bekannte Alternativen. Es sollte ein anderer Port als diese und 2185 gewählt werden!):
  Port 2185

Optional: Inaktive Verbindungen trennen:
ClientAliveInterval 300

- ClientAliveCountMax 2

Nun ist auf dem Server bereits alles korrekt eingerichtet, damit wir uns das erste Mal einloggen können.

ssh MYUSER@MYSERVER -p MYPORT

Der Server fragt uns nun nach dem Passwort des Benutzers auf dem Server. Nach erfolgter Eingabe sind wir auf dem Server eingeloggt. Mit dieser aufgebauten Verbindung werden nun alle Daten und Tastenkombinationen, die wir in unser Terminal eingeben haben, an den Server gesendet. Nicht verwunderlich ist es daher, dass auch ein STRG+C die aktuelle Verbindung abbricht. Tatsächlich wird über die Verbindung - die sogenannte Session - ein Programm ausgeführt, das als Login Shell beschrieben und konfiguriert wird. In Normalfällen ist dies meist bash, sh, oder zsh. Erst wenn dieses Programm beendet wird, wird auch die Verbindung zum Server beendet. Mit einem exit beenden wir die shell und landen so auch wieder auf dem lokalen CLI.

LOCAL SECOND

Da es nicht nur mühselig ist bei jedem login über ssh das Passwort einzugeben, gibt es eine schöne und zugleich noch sicherere Alternative. Das private/public Key Pair. Dieses Schlüsselpaar wird im Geheimen auf dem eigenen Rechner generiert. Der geheime Schlüssel wird dabei sicher im Verzeichnis ~/.ssh/ aufbewahrt. Der öffentliche Schlüssel wird auf die Systeme verteilt, auf denen man sich einloggen möchte.

Das Schlüsselpaar wird mit dem Programm ssh-keygen erzeugt. Dabei gibt es ein paar Optionen zu beachten. Diese sind nach dem Befehl auch einzeln erläutert:

ssh-keygen -t rsa -b 4096 -o -a 100

ssh-keygen: Dies ist das Programm zum Erzeugen des Schlüsselpaares.

-t rsa: setzt den Verschlüsselungsmodus explizit auf RSA. Dies ist noch die Standardeinstellung, kann daher eigentlich weggelassen werden.

-b 4096: Verwendet 2^12 Bits für die Verschlüsselung. Daher sind natürlich auch der Private und Public Key länger.

-o: Generiert den Private Key im neuen OpenSSH-Format, welches das Erraten des Private Key Passworts erschwert

-a 100: Generiert den privaten Schlüssel durch 100 Interaktionen der Funktion, die den einzigartigen Schlüssel generiert. Dabei wird das vorherige Ergebnis als Ausgangsbasis für die nächste Iteration verwendet. Das erschwert auch das Erraten des Passwortes des Privaten Schlüssels.

Danach fragt das Programm nach dem Speicherort für das zu erzeugende Schlüsselpaar.

ACHTUNG:

Eine einfache Bestätigung könnte bereits bestehende Schlüssel überschreiben. Man kann einen absoluten oder relativen Pfad inklusive Dateinamen angeben. Außerdem wird noch ein Passwort angefragt. Diese Möglichkeit sollte man im Normalfall auch nutzen und nur in besonderen Fällen davon absehen. Ein besonderer Fall kann sein, dass das Programm keine verschlüsselten privaten Schlüssel unterstützt oder die Passworteingabe bei einem Dienststart unbeaufsichtigter Prozesse notwendig ist. Dann werden der private und der öffentliche Schlüssel dort gespeichert.

Wichtig:

Gib niemals deinen privaten Schlüssel heraus, ebensowenig wie dein Passwort!

Nun kopieren wir den öffentlichen Schlüssel mittels ssh-copy-id auf den Server, um auch tatsächlich die publickey authentication zu verwenden. Dieser Schritt kann natürlich auch manuell vollzogen werden. Aber warum sollten wir uns die Mühe machen, wenn es schon ein Tool dafür gibt?

ssh-copy-id MYUSER@MYSERVER -p MYPORT

Das Programm versucht sich nun per ssh am entfernten Rechner anzumelden und fragt nach dem Passwort für den Benutzer. Wenn wir dies erfolgreich eingegeben haben, wird der öffentliche Schlüssel auf den Zielserver kopiert und die Session beendet.

Voilà! Das war es auch schon.

Nun können wir uns wieder mit ssh auf den Server einloggen ohne nach einem Passwort gefragt zu werden:

ssh MYUSER@MYSERVER -p MYPORT

Any questions?

I'm curious - let me know! Just write me an email or contact me on twitter or linkedin.