Sichere SSH-Authentifizierung mit einem Schlüsselpaar

Einleitung

SSH steht für “Secure Shell” und ist ein Netzwerkprotokoll, welches es ermöglicht, eine sichere, authentifizierte und verschlüsselte Verbindung über ein Netzwerk zu einem Server herzustellen. Ursprünglich wurde es für einen sicheren Zugriff auf entfernte Kommandozeilen entwickelt. Es existieren auch Erweiterungen, wie z.B. “SFTP” zur sicheren Übertragung von Dateien und Verzeichnissen. In diesem Artikel wird gezeigt, wie an Stelle eines Passworts ein kryptographisches Schlüsselpaar zur Authentifizierung verwendet werden kann. Hierbei wird ein Schlüsselpaar erzeugt, das deutlich länger als ein Passwort ist. Durch SSH-Public-Key Authentifizierung kann auch auf eine einfach Art ein Single Sign-on realisiert werden, indem der öffentliche Schlüssel auf mehreren Servern hinterlegt wird.

SSH wird auch gerne als Übertragungsmedium für die verteilte Quellcode Versionswerwaltung git verwendet.

Wie funktioniert die Authentifizierung mit Schlüsselpaar?

Zur Authentifizierung werden von Server und Client jeweils zwei Schlüssel erzeugt: ein öffentlicher und ein privater Schlüssel. Der private Schlüssel muss zu allen Zeiten geheim gehalten werden, während der öffentliche Schlüssel veröffentlicht werden kann. Aus dem öffentlichen Schlüssel lässt sich der private Schlüssel nicht herleiten. Wohl aber lässt sich ohne Kenntnis des privaten Schlüssels einer Person mit Hilfe des öffentlichen Schlüssels der Person überprüfen ob Daten mit dem privaten Schlüssel signiert wurden. Dieser Mechanismus bildet die Grundlage der Authentifizierung beim Aufbau einer SSH Verbindung.

Der Ablauf des Aufbaus der Verbindung vom Client zum Server unter Verwendung der Public-Key-Authentifizerung ist vereinfacht wie folgt:

1. Der Client baut eine Verbindung zum Server auf.
2. Der Server sendet seinen öffentlichen Schlüssel an den Client.
3. Der Client vergleicht den vom Server gesendeten öffentlichen Schlüssel mit dem ihm für diesen Server bekannten öffentlichen Schlüssel. Unterscheidet sich der öffentliche Schlüssel von dem, welcher dem Client bekannt ist, wird die Verbindung abgebrochen. Ist dem Client kein öffentlicher Schlüssel des Servers bekannt, fragt er den Benutzer, ob der Fingerabdruck des Servers beim ersten Verbindungsaufbau gespeichert werden soll.
4. Der Server überprüft anhand des auf ihm hinterlegten Schlüssels des Clients, ob der Client im Besitz des privaten Schlüssels ist.

Der private Schlüssel wird auf dem eigenen Rechner in der Regel zusätzlich mit einer Passphrase verschlüsselt. Vor Benutzung muss der private Schlüssel also zunächst entschlüsselt werden. Um das nicht bei jedem Login auf einem Server tun zu müssen, kann der entschlüsselte private Schlüssel in einem “SSH-Agent” hinterlegt werden, sodass lokale SSH-Clients bei Bedarf darauf zugreifen können. Die Eingabe eines Passworts bei jedem Login auf einem Server entfällt somit.

Hinterlegen des öffentlichen Schlüssels auf dem Zielsystem

Der übliche unter Linux verwendete OpenSSH Server sucht beim Login des Clients in der Regel nach dem öffentlichen Schlüssel in der Datei ~/.ssh/authorized_keys. Die Abkürzung ~steht hierbei für ihr Home-Verzeichnis auf der Server, also z.B. /home/bob/. Wenn dort der passende Schlüssel gefunden wurde, so wird der Login des Benutzers genehmigt.

Sie müssen Ihren öffentlichen Schlüssel also in die Datei ~/.ssh/authorized_keys auf dem Server kopieren. Ihren öffentlichen Schlüssel finden Sie in der Regel in der Datei ~/.ssh/id_rsa.pub auf dem Rechner, auf welchem Sie Ihr Schlüsselpaar erzeugt haben.

Linux Clients

Erzeugen eines Schlüsselpaares

Ein Schlüsselpaar kann unter Linux mit dem Befehl

ssh-keygen -t rsa

erzeugt werden. Hierbei werden Sie nach einer Passphrase gefragt. Dies ist ein Passwort, welches den in einer Datei auf Ihrem Rechner gespeicherten privaten Schlüssel verschlüsselt um ihn vor unberechtigten Zugriffen zu schützen.

Damit Sie das Kopieren des öffentlichen Schlüssels nicht von Hand durchführen müssen existiert in Linux das Tool ssh-copy-id. Das Tool kann wie folgt, z.B. für den Benutzer “bob” verwendet werden:

ssh-copy-id bob@server.example.com

Sie werden nach dem Passwort für den SSH-Login gefragt und das Tool hinterlegt den öffentlichen Schlüssel auf dem Server. Danach können Sie den Login auf dem Zielsystem testen:

ssh bob@server.example.com

Verwendung des SSH-Agents

Da Sie in der Regel ihren privaten Schlüssel mit einer Passphrase geschützt haben, müssten Sie diese bei jedem Verbindungsaufbau zum SSH-Server erneut eingeben. Um dies zu vermeiden wurde ein Daemon erfunden, der im Hintergrund auf Ihrem Rechner läuft und die Passphrase vorübergehend im Arbeitsspeicher speichert. Auf den meisten Linux Desktop Rechnern wird ein solcher Daemon automatisch gestartet, sodass durch Ausführung des Befehls

ssh-add

der vorhandene private Schlüssel entsperrt zum Agenten hinzugefügt werden kann.

Sollte es zu einem Fehler kommen, weil der Daemon nicht läuft, so kann er mit dem Befehl

eval `ssh-agent`

gestaret werden, wobei die entsprechenden Umgebungsvariablen in der aktuellen Shell automatisch gesetzt werden.

Windows Clients

Seit Version 1709 ist in Windows 10 auch ein SSH Client ab Werk enthalten. Es muss also - wie auch auf den meisten Linux Systemen - keine zusätzliche Software installiert werden. Auf älteren Windows Systemen kann z.B. das Tool Putty verwendet werden.

Starten Sie zur Verwendung des Clients bitte die Microsoft PowerShell.

Hier können Sie mit Hilfe des Befehls ssh-keygen -t rsa ein neues Schlüsselpaar erzeugen, wobei Sie auch nach einer Passphrase gefragt werden:

Ihren öffentlichen Schlüssel können Sie dann mit cat ~/.ssh/id_rsa.pub anzeigen:

Ihr öffentlicher Schlüssel muss nun noch auf dem Server hinterlegt werden. Hierzug loggen Sie sich bitte mit dem Befehl ssh bob@example.com auf dem Server ein und bearbeiten z.B. mit dem Texteditor “nano” die Datei: ~/.ssh/authorized_keys:

nano ~/.ssh/authorized_keys

Nachdem Sie den öffentlichen Schlüssel auf dem Server eingetragen haben, solle bei dem Verbindungsaufbau zum Server nicht mehr nach einem Passwort gefragt werden.

Absicherung des Zielsystems

Nachdem die öffentlichen Schlüssel auf dem Linux Server hinterlegt sind, sollte zur Erhöhung der Sicherheit die Passwort-Authentifizierung auf dem Server deaktiviert werden. Bevor Sie die Passwort-Authentifizierung deaktivieren, testen Sie bitte, ob der Login per SSH-Publiy-Key-Authentifizierung ohne Eingabe des Passworts für den Server funktioniert.

Das kann in der Datei /etc/ssh/sshd_config auf dem Server durch folgende Zeile konfiguriert werden:

PasswordAuthentication no

Nachdem in dieser Datei Änderungen durchgeführt werden, muss der SSH-Server neugestartet werden. Dies kan auf Linux-Systemen, die “systemd” verwenden, durch Eingabe des folgenden Befehls geschehen:

systemctl restart ssh.service

Die aktuell bestehende SSH-Verbindung wird hierbei in der Regel nicht unterbrochen.

SSH-Agent Forwarding

Gelegentlich kommt es vor dass man sich per SSH von einem Server auf einen anderen Server verbinden möchte, also z.B. vom Client A aus über Server B eine Verbindung zu Server C aufbauen möchte. Hierzu müsste eigentlich der private SSH-Schlüssel auf den Server B kopiert werden. Um dies zu vermeiden existiert das Konzept des SSH-Agent Forwardings. Hierbei erlaubt man Server B den Zugriff auf den auf dem Client A laufenden SSH-Agent. Das geschieht beim Aufbau der Verbindung zum Server B durch setzen der -A Flag:

ssh -A serverB.example.com

SSH-Agent Forwarding sollte nur für Verbindungen zu vertrauenswürdigen Servern genutzt werden. Der Server kann zwar den privaten Schlüssel des Clients nicht direkt auslesen, wohl aber kann er prinzipiell für die Zeit der bestehenden Verbindung zwischen Client und Server den SSH-Agent für den Aufbau von SSH-Verbindungen zu weiteren Servern nutzen.

Übertragung von Dateien mit SCP

Das auf SSH aufbauende “Secure Copy” Protokoll SCP ermöglicht die Übertragung von Dateien und Verzeichnissen, was z.B. für ein Verzeichnis mit Hilfe des folgenden Befehls geschehen kann:

scp -r /home/bob/Dokumente/  bob@server.exmaple.com:/home/bob/Backup/

Weiterhin existiert das SFTP-Protokoll, welches im Gegensatz zu SCP auch die Übertragung von Verzeichnisrechten ermöglicht. Es arbeitet jedoch interaktiv, wodurch durch die Übertragung der Dateien etwas langsamer geschieht. Für SFTP kann z.B. der Client FileZilla genutzt werden.

Clients für beide Protokolle können i.d.R. auf einen SSH-Agent zugreifen.

Fazit

In diesem Artikel wurde aufgezeigt, wie Sie ein Schlüsselpaar erzeugen und hiermit auf entfernte Server zugreifen können. Diese Art der Authentifizierung bietet nicht nur mehr Sicherheit, sondern erspart auch die Eingabe eines Passworts für jede neue SSH-Verbindung.

Referenzen

• RFC Standard Nr. 4252: “The Secure Shell (SSH) Authentication Protocol”, Internet Engineering Task Force
• ssh.com, SSH Communications Security, Inc.
• SSH - Secure Shell, HTW Chur