Dieses Dokument behandelt die Verwendung von Schlüsseln in SSH (SCP, SFTP) Verbindungen.

In der Rolle als SSH-Server benötigt ein Rechner Schlüsselpaare, bestehend aus einem geheimen und einem öffentlichen Teil, die in /etc/ssh gespeichert werden:

# ls -la
-rw-------  1 root root    399 Jan 16 21:37 ssh_host_ed25519_key
-rw-r--r--  1 root root     90 Jan 16 21:37 ssh_host_ed25519_key.pub
-rw-------  1 root root    887 Sep  2  2012 ssh_host_rsa_key
-rw-r--r--  1 root root    218 Sep  2  2012 ssh_host_rsa_key.pub

Diese Host-Schlüssel sind sozusagen das Ausweispapier des Servers, die bei Aktivierung des ssh-Servers in der eisfair-Konfigurationsschicht automatisch erzeugt werden, die Erweiterung pub kennzeichnet den öffentlichen Schlüssel.

Diese Schlüssel dürfen niemals für andere Zwecke z. B. als User-Athentifizierungs-Keys missbraucht werden.

Im Zuge der Härtung des eisfair-ssh-Systems durch das Base-Update 2.3.9 werden nur noch ed25519- und rsa-(4096 Bit)-Schlüssel - sofern nicht vorhanden - erzeugt. Eventuell noch vorhandene id_host_dsa, id_host_ecdsa und id_host (rsa1) Schlüssel werden nicht gelöscht, gelten aber als unsicher und sollten daher, wenn es keine gravierenden Gründe für deren Beibehaltung gibt, aus /etc/ssh gelöscht werden. Ein älterer id_host_rsa-Key mit weniger als 4096 Bit sollte aus den gleichen Gründen mit 4096 Bit neu erzeugt werden. Server-Host-Keys können im SSH Administrationsmenü neu erzeugt werden.

Bei einer Kontaktaufnahme per ssh übermittelt der ssh-Server dem Client - nachdem sich die beiden Partner auf einen Schlüsseltyp geeinigt haben - den öffentlichen Schlüssel. Auf Client-Seite wird dieser öffentliche Schlüssel bei erstmaliger Verbindung mit diesem Server, eventuell nach Bestätigungsnachfrage, in ~/.ssh/known_hosts (in /root/.ssh/known_host für den User root) eingetragen und zukünftig als geprüft und genehmigt angesehen:

# ssh max@mein_server.local.lan
The authenticity of host '[mein_server.local.lan] ([192.168.1.100])' can't be established.
ED25519 key fingerprint is ab:9f:65:7c:3e:55:14:42:f3:5d:91:fe:12:a2:b1:3f [MD5].
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[mein_server.local.lan],[192.168.1.100]' (ED25519) to the list of known hosts.
Password:

Bei einer erneuten Verbindungsaufnahme wird bei Übereinstimmung des vom Server übermittelten pub-Schlüssels mit dem in der known_hosts-Datei gespeicherten Schlüssel die Verbindung sofort hergestellt:

# ssh max@mein_server.local.lan
Password: 

Kommt es zu einem Mismatch des gespeicherten mit dem übermittelten Schlüssel wird die Verbindungsaufnahme verweigert:

eis # ssh max@mein_server.local.lan
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
ed:a9:75:8b:d3:44:04:36:e5:7d:68:6f:50:16:a3:e3 [MD5].
Please contact your system administrator.
Add correct host key in /home/max/.ssh/known_hosts to get rid of this message.
Offending ED25519 key in /home/max/.ssh/known_hosts:5
You can use following command to remove all keys for this IP:
ssh-keygen -R mein_server.local.lan -f /home/max/.ssh/known_hosts
ED25519 host key for [mein_server.local.lan] has changed and you have requested strict checking.
Host key verification failed.

Man hat also nun zu prüfen, wieso es zu diesem Mismatch gekommen ist; eine mögliche Erklärung wäre schlicht der Umstand, dass der Administrator des Servers neue Host-Keys erzeugt hat.

Hat man sich also von der Korrektheit des neuen Server-Schlüssels überzeugt, muss der veraltete Schlüssel aus der known_hosts Datei gelöscht werden. Dies kann mit einem Texteditor oder auf einem Linux-Client über den in der Warnmeldung vorgeschlagenen ssh-keygen-Befehl geschehen. Danach kann erneut der Kontakt mit dem Server aufgenommen werden.

Je nach Konfiguration eines ssh-Clients ist es auch möglich, dass dieser nach einer Nachfrage den veralteten Schlüssel selbst in der known_host-Datei gegen den neuen Schlüssel austauscht.

Statt der Eingabe eines Passwortes zur Authentifizierung am Server ist es möglich, sich per Schlüssel am Server zu legitimisieren. Diese Art der Authentifizierung ermöglicht, dass Skripte automatisiert Daten per ssh, sftp oder rsync zwischen zwei Rechnern übertragen können, z. B. zu Backupzwecken oder Synchronisierung von Datenbeständen.

Hierzu ist es notwendig, auf dem Client-PC entsprechende Schlüsselpaare zur erzeugen. Diese Schlüssel bilden sozusagen Ausweispapiere eines Users, vergleichbar den Host-Keys eines Servers. Unter Linux und MobaXTerm dient hierzu das Programm ssh-keygen:

# cd .ssh
# /usr/bin/ssh-keygen -t rsa -a 100 -b 4096 -C "max@client_1" -f id_rsa
# /usr/bin/ssh-keygen -t ed25519 -a 100 -C "max@client_1" -f id_ed25519

Hier wurden nun jeweils ein rsa- und ein ed25519-Schlüsselpaar für den User max auf dem Client_1 erzeugt.

Nun muss der öffentliche Teil (.pub) dieser Schlüsselpaare auf den eisfair-Server übertragen und in die authorized_keys-Datei all der User auf dem Server eingefügt werden, mit deren Account man sich mit ssh verbinden möchte. Diese Datei befindet sich in ~/.ssh, also /home/<username>/.ssh bzw. /root/.ssh.

Es ist nicht ratsam, diese externen Authentifizierungs-Schlüssel in das Verzeichnis ~/.ssh zu kopieren, da die Schlüsselnamen mit denen lokal auf dem eisfair-Server erzeugten User-Schlüssel kollidieren können. Besser ist es im Homeverzeichnis des lokalen eisfair-Users eine eigenes Verzeichnis für externe öffentliche Schlüssel anzulegen z. B. externe_ssh_pub_keys, wovon ich im Weiteren ausgehe.

Für die Einbindung in die authorized_keys-Datei eines beliebigen lokalen eisfair-Users (nicht root) sind folgende Schritte zu unternehmen:

• Kopieren der *.pub-Schlüsseldateien vom Client in das Verzeichnis ~/externe_ssh_pub_keys, wobei statt der auf dem Herkunftsclient genutzten Dateinamen id_<typ>.pub auf dem eisfair-Server aussagekräftigere Namen wie max_an_client_1_<typ>.pub gewählt werden sollten, damit sich Schlüssel verschiedener Client-Rechner nicht gegenseitig in die Quere kommen.
• Auf dem eisfair-Server als User anmelden, in dessen Home die Schlüssel kopiert wurden.
• Anschliessend die Schlüssel der authorized_keys-Datei hinzufügen:
  

  # cat ~/externe_ssh_pub_keys/<schlüsselname>.pub >> ~/.ssh/authorized_keys

• Die importierten Schlüssel können nun wieder aus dem Verzeichnis ~/externe_ssh_pub_keys gelöscht werden.

Für den User root auf dem eisfair-Server darf die Einbindung der Schlüssel in die authorized_keys-Datei jedoch nicht manuell erfolgen, da diese Datei von Systemskripten erzeugt wird. Stattdessen sind die Schlüssel nach dem Übertragen auf den Server in die ssh-Konfiguration einzutragen und dann folgende Schritte ausführen:

Kopieren der *.pub-Schlüsseldateien vom Client in das Verzeichnis /root/externe_ssh_pub_keys, wobei statt der auf dem Herkunftsclient genutzten Dateinamen id_<typ>.pub auf dem eisfair-Server aussagekräftigere Namen wie max_an_client_1_<typ>.pub gewählt werden sollten, damit sich Schlüssel verschiedener Client-Rechner nicht gegenseitig in die Quere kommen.

• Auf dem eisfair-Server als root anmelden.
• Die ssh-Konfiguration öffnen und die Schlüssel eintragen:
  

  \\ SSH_PUBLIC_KEY_N='2'\\ SSH_PUBLIC_KEY_1_NAME='Max ED25519-Schluessel von Client 1'\\ SSH_PUBLIC_KEY_1_ACTIVE='yes'\\ SSH_PUBLIC_KEY_1='/root/externe_ssh_pub_keys/max_an_client_1_ed25519.pub'\\ SSH_PUBLIC_KEY_2_NAME='Max RSA-Schluessel von Client 1'\\ SSH_PUBLIC_KEY_2_ACTIVE='yes'\\ SSH_PUBLIC_KEY_2='/root/externe_ssh_pub_keys/max_an_client_1_rsa.pub'

Hinweis: Diese Optionen der ssh-Konfiguration dienen nur dazu, die pub-Keys von auf Clients erzeugten Schlüsselpaaren zur Authentifizierung am eisfair-Server einzutragen und nicht die pub-Keys in den .ssh-Verzeichnissen lokaler eisfair-User (einschließlich root). Die auf den Server übertragenen Schlüssel dürfen nicht vom eisfair-Server gelöscht werden, da jeder erneute Aufruf der ssh-Konfiguration die authorized_keys für root neu erzeugt und daher jederzeit die in der Konfiguration eingetragenen Schlüssel vorhanden sein müssen.

Sollen sich lokale eisfair-Server-User per Schlüssel automatisch an anderen Servern/PCs per ssh anmelden können, sind User bezogene Schlüssel auf dem eisfair zu erzeugen und auf den Rechner zu übertragen und zu installieren, mit dem man sich verbinden möchte. Lokal auf dem eisfair-Server werden diese Schlüssel einfach id_<typ> genannt und müssen in ~/.ssh bzw. /root/.ssh gespeichert werden.

Auf einem eisfair-1-Server reicht es, das Skript /var/install/bin/system-ssh-create-client-keys aufzurufen, um ein persönliches Schlüsselpaar für root oder einen anderen lokalen eisfair-User zu erzeugen:

# /var/install/bin/system-ssh-create-client-keys --help
Usage: system-ssh-create-client-keys [options]
    --batch                                 - run script in batch mode
    --comment 'my comment'                  - comment to add to new keys
    --key ed25519|rsa|ecdsa|dsa|rsa1        - generate a 'specific' key
    --pass 'my passphrase'                  - set a passphrase for the key
    --path 'destination path for key files' - path to save the new key
    --quiet                                 - suppress screen output
    --rsabits 2048|3072|4096|6142|8192      - bits to generate RSA key
    --user 'valid-username'                 - user name to create key for
    --help                                  - show this help

# /var/install/bin/system-ssh-create-client-keys --user moritz

Das Übertragen und Installieren dieser Schlüssel auf dem Zielrechner geschieht analog zu den Darstellungen im Abschnitt 2a.

Zunächst sind gemäß Abschnitt 2b auf dem eisfair-Server, der die Rolle des Clients spielt, die entsprechenden Schlüssel zu erzeugen und anschließend nach Abschnitt 2a in den zweiten eisfair-Server (Server-Rolle) zu importieren.

Für eine ordnungsgemäße Funktion des ssh/sshd sind restriktive Rechte nur für den besitzenden User zu setzen. Das Verzeichnis ~/.ssh bzw. /root/.ssh muss die Rechte 0700, die Dateien in diesem Verzeichnis 0600 haben.

# cd ~
# chmod 0700 .ssh
# cd .ssh
# chmod 0600 *

Das generelle Abschaltung einer Passwort-Authentifizierung auf einem Server darf erst dann erfolgen, wenn die Authentifizierung mittels Key funktioniert, ansonsten sperrt man sich selbst aus dem Server aus.