In den genannten Base-Updates wurde eine SSH-Härtung gemäß folgender Empfehlung durchgeführt: https://stribika.github.io/2015/01/04/secure-secure-shell.html

Hier die wichtigsten Änderungen die es zu beachten gilt:

Standardmäßig wurde die Unterstützung für das als unsicher eingestufte SSH-Protokoll 1 eingestellt. D.h. die folgenden Parameter wurden aus der Konfiguration entfernt: SSH_USE_SSH1 und SSH_SVR_KEYBITS

Die folgenden drei neuen Parameter wurden in die SSH-Konfiguration eingefügt, um eine Feinjustage der Sicherheitseinstellungen vornehmen zu können. Diese Parameter sollten nur dann eine von 'default' abweichende Einstellungen erhalten, wenn dies wegen der Verwendung eines alten SSH-Klienten oder einer SSH-App, die die neuen Einstellungen nicht unterstützt, unumgänglich ist: SSH_SERVER_CIPHERS, SSH_SERVER_KEXS und SSH_SERVER_MACS. Dies geschieht dann in der Form 'default,<weiterer Parameter>' also z. B. 'default,hmac-sha1', wenn der eigene SSH-Client die MAC 'hmac-sha1' erfordert.

Konfigurationsoptionen für Base ab 2.3.9

Konfigurationsoptionen für Base ab 2.8.4

Nach dem Update auf Base 2.8.4 kann der Wegfall der CIPHERs arcfour256, arcfour128, arcfour, cast128-cbc und blowfish-cbc sowie MACs hmac-ripemd160-etm@openssh.com, hmac-ripemd160 und hmac-ripemd160@openssh.com zum Problem werden, wenn diese aktuell für ssh Verbindungen zum Server genutzt werden. Die MACs hmac-ripemd160-etm@openssh.com und hmac-ripemd160 gehörten bislang zu den Defaultwerten.

Es werden nun standardmäßig nur noch zwei Schlüssel für den Systemzugriff erzeugt, ein ed25519- und ein rsa-Schlüssel (4096 bit).

Es werden nun standardmäßig restriktivere Einstellungen für die folgenden SSH-Parameter verwendet: Ciphers, MACs, KexAlgorithms (siehe Tabelle unter 2. in der Zeile default).

Es wird nun auch standardmäßig eine Datei ssh_config mit den restriktiveren Parametern erstellt, was von Belang ist, wenn von der Konsole aus auf andere Server zugegriffen wird. Da eine persönliche Konfigurationsdatei ~/.ssh/config jedoch Vorrang vor der Standarddatei hat, sollte es keinen Grund geben diese Datei selbst zu bearbeiten. Ich musste z. B. bei mir die ~/.ssh/config wie folgt aufbauen, damit ich weiterhin auf ein Synology NAS mit geringerer Verschlüsselung zugreifen konnte:

Base ab Version 2.3.9:

Host die-diskstation.lokal.lan
     Ciphers aes128-cbc
     MACs hmac-sha2-512-etm@openssh.com

Base ab Version 2.8.4:

Host die-diskstation.lokal.lan
     Ciphers aes128-cbc
     MACs hmac-sha2-512-etm@openssh.com

Existiert die Datei ~/.ssh/config schon, ist obiger Host-Block hinzuzufügen. Sollen diese Einstellungen für mehrere Hosts gelten, können diese durch Leerzeichen getrennt hintereinander angegeben werden.

Falls man ein Zugriffsproblem auf einen Server hat, kann man z. B. den ssh-Klienten mittels 'ssh -v <servername>' starten um mehr Meldungen angezeigt zu bekommen. Folgende Zeilen geben Auskunft über die verwendeten Parameter:

                            Cipher     MAC           KEX
                            ---------- ------------  ----
...
debug1: kex: server->client aes256-ctr hmac-sha2-512 none
debug1: kex: client->server aes256-ctr hmac-sha2-512 none
...

Es wird nun standardmäßig das Skript /var/install/bin/system-ssh-create-client-keys mitgeliefert, über welches es möglich ist, neue Anwenderschlüssel zu erzeugen und diese z.B. in ~/.ssh abzulegen. Die Liste der verfügbaren Kommandozeilenparameter findet ihr im Skriptkopf. Falls nichts angegeben wird, kann man interaktiv persönliche Schlüssel erstellen.

Über den neuen Menüpunkt 'View log messages' können nun die Logmeldungen des sshd angezeigt werden.

Werden mittels ssh/scp (auch rsync bei Nutzung des Parameters „-e ssh“) Daten von/zu einem eisfair-1-Server innerhalb automatisierter Skripte (z. B. cron-Job) übertragen, ist unbedingt zu prüfen, ob diese Skripte noch fehlerfrei funktionieren z. B. durch Aufruf auf der Konsole.

Während der für die Härtung der SSH-Konfiguration durchgeführten Anpassungen traten verschiedenste Problemstellungen auf, auf welche im folgenden im Detail eingegangen wird. Eventuell helfen diese Informationen anderen Anwender bei der Problemlösung.

Um sich die von einem OpenSSH-Server bzw. -Klienten unterstützten Ciphers, MACs und KEXs ausgeben zu lassen, kann man folgende Befehle verwenden:

# ssh -Q cipher
# ssh -Q mac
# ssh -Q kex

Ein FLI4L-Server verwendet einen Dropbear SSH-Server, wodurch hier die Befehle etwas anders aussehen:

# ssh -c help
# ssh -m help

Die KEX-Werte scheinen sich nicht abfragen zu lassen. Laut FLI4L-Team werden von einem Dropbear SSH-Server zur Zeit folgende Werte unterstützt (Die KEX-Werte sind dem Source-Code entnommen):

Wer mit PuTTY auf dein eisfair-Server zugreifen und dazu eine Schlüsseldatei verwenden möchte, muss dafür weiterhin den rsa (4096 bit) Schlüssel verwenden, da von PuTTY zur Zeit noch keine ed25519-Schlüssel unterstützt werden.

Damit puttygen.exe einen OpenSSH2-Schlüssel importieren kann, muss dieser mit einem Kennwort versehen sein. Dies bewerkstelligt man mittels des folgenden Befehls:

# ssh-keygen -p
Enter file in which the key is (/root/.ssh/id_rsa): /root/.ssh/id_rsa
Key has comment '/root/.ssh/id_rsa'
Enter new passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved with the new passphrase.

Beim Speichern kann man dann auf Wunsch das Kennwort wieder entfernen. Dazu sind einfach die beiden Passphrase-Felder zu leeren und die Schlüsseldateien zu speichern. Will man das Kennwort zu einem späteren Zeitpunkt wieder setzen oder entfernen, so ruft man einfach puttygen.exe <privater-schluessel>.ppk erneut auf.

Um sich mittels der generierten SSH-Schlüssel ohne zusätzliche Eingabe eines Kennwortes am eisfair-Server anzumelden, kopiert man die auf dem/den Client-PCs generierten pub-Keys auf den eisfair-Server und setzt anschliessend folgende Parameter in der ssh-Konfiguration (setup→System administration→SSH administration→Edit configuration), z. B.:

SSH_PUBLIC_KEY_N='3'  
SSH_PUBLIC_KEY_1_NAME='Mein ED25519-Schluessel von Client X'
SSH_PUBLIC_KEY_1_ACTIVE='yes'
SSH_PUBLIC_KEY_1='/root/id_ed25519_vom_client_X.pub'
SSH_PUBLIC_KEY_2_NAME='Mein RSA-Schluessel von Client X'
SSH_PUBLIC_KEY_2_ACTIVE='yes'
SSH_PUBLIC_KEY_2='/root/id_rsa_vom_client_X.pub'
SSH_PUBLIC_KEY_3_NAME='Mein RSA-Schluessel von Client Y'
SSH_PUBLIC_KEY_3_ACTIVE='yes'
SSH_PUBLIC_KEY_3='/root/id_rsa_vom_client_Y.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 von anderen Clients kopierten pub-Schlüssel sollten besser nicht nach ~/.ssh kopiert werden, da sich deren Namen mit Schlüssel des lokalen eisfair-Users überschneiden können! Statt - wie im obigen Codeblock - die Schlüssel direkt im Home (hier root) abzulegen, kann natürlich ein beliebiges Verzeichnis z. B. ssh-externe-keys im Home-Verzeichnis angelegt und dort die Keys abgelegt werden.

Desweiteren ist es sinnvoll, die von anderen Clients kopierten Authentifizierungskeys nicht einfach id_rsa.pub zu benennen, sondern im Namen die Zuordnung zum zugehörigen Client deutlich zu machen. Dies wird dann wichtig, wenn von verschiedenen Clients auf den eisfair-Server zugegriffen wird und von jedem dieser Clients ein eigener Authentifizierungsschlüssel auf dem Server abgelegt wird.

Falls ein Verbindungsaufbau zum SSH-Server scheitert, so setzt man temporär am besten den Parameter SSH_LOGLEVEL='DEBUG2' und greift auf den Server zu. Abhängig von der angezeigten Fehlermeldung in /var/log/messages modifiziert man dann einzelne Parameter. Möglich ist aber auch, den DEBUG2-Modus auf dem Client zu nutzen, indem der ssh-Aufruf um „-vv“ ergänzt wird.

Wird z. B. die Meldung 'Key exchange nicht möglich' o. ä. angezeigt, so setzt man erst einmal SSH_SERVER_KEXS='all'. Anschliessend baut man mit dem Client-Programm bzw. der App eine Verbindung zum Server auf und schaut nach folgenden Meldungen:

...debug2: kex_parse_kexinit: first_kex_follows 0
...debug2: kex_parse_kexinit: reserved 0
...debug2: kex_parse_kexinit: diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1

Der erste Wert wird dann durch Setzen von SSH_SERVER_KEXS='default, diffie-hellman-group14-sha1' in die Konfiguration übernommen und anschliessend ein erneuter Verbindungsversuch unternommen. Üblicherweise sollte dann eigentlich eine Verbindung möglich sein.

Die Android ConnectBot-App ab Version 1.8.1 unterstützt aes256-ctr und hmac-sha2-256 und funktioniert somit mit den Standardeinstellungen der neuen SSH-Konfiguration.

Eine ssh-Sitzung mit dem Windows-Fernsteuerprogramm MobaXTerm funktioniert mit den Standardeinstellungen der neuen SSH-Konfiguration.

Die Windows-SSH-Clients PuTTY (ab Version 0.70)und KiTTY (ab Version 0.65) funktionieren mit den Standardeinstellungen der neuen SSH-Konfiguration

WinSCP ab Version 5.5 funktioniert mit den Standardeinstellungen der neuen ssh-Konfiguration.

Die iPhone Serverauditor-App in der Version 1.5.4 erfordert, dass der folgende Parameter modifiziert wird:

SSH_SERVER_KEXS='default,diffie-hellman-group14-sha1'

Die iPhone Reflection for UNIX-App in der Version 1.1.0.40 (einzige App im Test, die den Server-Key zur Prüfung angeboten hat) erfordert, dass der folgender Parameter modifiziert wird:

SSH_SERVER_KEXS='default,diffie-hellman-group14-sha1'

Die iPhone iTerminal-App in der Version 2.0.2 (freie Version mit Werbeeinblendungen) erfordert, dass der folgende Parameter modifiziert wird:

SSH_SERVER_KEXS='default,diffie-hellman-group14-sha1'

Die iPhone vSSH Lite-App in der Version 1.8 (freie Version mit Werbeeinblendungen) erfordert, dass ein Parameter modifiziert wird:

SSH_SERVER_MACS='default,hmac-sha1'

iPhone Mocha Telnet Lite-App in der Version 2.7 erfordert, dass die folgenden Parameter modifiziert werden:

SSH_SERVER_CIPHERS='default,3des-cbc'
SSH_SERVER_KEXS='default,diffie-hellman-group1-sha1'
SSH_SERVER_MACS='default,hmac-sha1'

Unter SSH-Schlüsselfragen befindet ein erläuternder Text zu SSH-Schlüsseln und deren Erstellung und Verwendung.