Beim letzten Beitrag zur SSH-Konfiguration unter Cisco IOS und Cisco ASA fiel mir noch ein, dass man über sinnvolle Anpassungen der Client-Konfiguration auch mal schreiben sollte. Zumindest unter MacOS (und mindestens auch unter Debian und älterem Ubuntu Linux) wird standardmäßig nicht immer die optimale Kryptographie verwendet.
Die SSH-Parameter können an zwei Stellen konfiguriert werden:
- systemweit unter /etc/ssh_config
- per User unter ~/.ssh/config
In der systemweiten SSH-Config befinden sich z.B. die folgenden drei Zeilen, die weite Teile der verwendeten Kryptographie bestimmen (genauer gesagt zeigen sie die Defaults):
#Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour
#KexAlgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
#MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-sha1-96,hmac-md5-96,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96Was kann/sollte man ändern:
Ciphers
Wer keine legacy Systeme zu pflegen hat, der könnte alle nicht-AES ciphers entfernen. Aber Geräte wie 2950 Switche sind halt auch noch ab und an anzutreffen. Daher muss man in so einem Fall 3des-cbc auch konfiguriert haben. Die Cipher-Zeile könnte dann folgendermaßen aussehen:
Ciphers aes256-ctr,aes128-ctr,aes256-cbc,aes128-cbc,3des-cbcLaut Manpage (und basierend auf der sowohl unter Mavericks und Yosemite verwendeten OpenSSH-Version 6.2p2) sollten auch die moderneren GCM-Typen unterstützt sein. Wenn die konfiguriert sind, meldet der SSH-Client aber „Bad SSH2 cipher spec“.
Beim Zugriff auf Cisco Router und Switche kommen typischerweise die CBC-Versionen zum Einsatz, da CTR erst ab IOS 15.4 unterstützt ist.
KexAlgorithms
Hier wird der Key-Exchange gesteuert. Meine Konfig-Zeile auf dem Mac ist die folgende:
KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1Die ElipticCurve Algorithmen habe ich entfernt, da diese im Verdacht stehen Backdoors zu beinhalten. Die vermutlich vertrauenswürdige curve25519 von D.J. Bernstein ist erst in OpenSSH 6.6p1 enthalten. Diese werde ich bei Verfügbarkeit mit aufnehmen. Als letztes in der Zeile ist weiterhin ein Group1-Exchange (768 Bit), der für Legacy-Geräte benötigt wird.
MACs
Am meisten stört mich, dass eine MD5-Methode die höchste Priorität hat, gefolgt von einer SHA1-Methode. Da sollte die Reihenfolge angepasst werden:
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,hmac-sha1Interessant sind die etm-MACs. Dazu ein kleiner Ausflug in Message Authentication Codes. Die Protokolle SSL, IPsec und SSH verwenden standardmäßig verschiedene Methoden um die Daten zu verschlüsseln und die Integrität zu sichern:
- SSL: mac-then encrypt. Dabei wird erst der MAC gebildet, dann werden Daten und MAC verschlüsselt.
- IPsec: encrypt-then-mac. Dabei werden die Daten erst verschlüsselt und dann darüber der MAC gebildet.
- SSH: encyrpt-and-mac. Die Daten werden verschlüsselt, die MAC wird aber über die Klartextdaten gebildet.
Es hat sich herausgestellt, dass von diesen drei Optionen die von IPsec verwendete Methode die sicherste ist. Diese encrypt-then-mac (etm) Verfahren können auch bei SSH verwendet werden.
Update: In RFC 7366 wird eine TLS-Erweiterung definiert, die auch die Verwendung von “encrypt then mac” benutzt.
Was hat sich jetzt beim Zugriff auf ein IOS-Gerät geändert? Ohne diese Anpassungen sieht die SSH-Session so aus (auf einem Cisco 3560 mit IOS 15.0(2)SE5):
c3560#sh ssh
Connection Version Mode Encryption Hmac State Username
1 2.0 IN aes128-cbc hmac-md5 Session started ki
1 2.0 OUT aes128-cbc hmac-md5 Session started kiEs wird aes-128-cbc mit einem MD5-HMAC verwendet. Nach den Änderungen ist die Krypto etwas besser (im Rahmen der Möglichkeiten des IOS):
c3560#sh ssh
Connection Version Mode Encryption Hmac State Username
0 2.0 IN aes256-cbc hmac-sha1 Session started ki
0 2.0 OUT aes256-cbc hmac-sha1 Session started kiHier noch einmal die resultierende ~/.ssh/config:
Ciphers aes256-ctr,aes128-ctr,aes256-cbc,aes128-cbc,3des-cbc
KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,hmac-sha1Update:
Nach einigem Nachdenken kam ich zu dem Ergebnis, dass mir die Aufnahme der Legacy-Verfahren in die Config-Datei irgendwie nicht gefällt. Daher habe ich diese wieder rausgeschmissen und gebe bei der Verbindung zu älteren Geräten die benötigte Crypto direkt an. Hier ein Beispiel für den Zugriff auf einen 2950:
ssh -l ki 10.10.10.200 -o Ciphers="3des-cbc" -o KexAlgorithms="diffie-hellman-group1-sha1"Und hier die angepasste ~/.ssh/config:
Ciphers aes256-ctr,aes128-ctr,aes256-cbc,aes128-cbc
KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,hmac-sha1Weitergehende Verbesserungsvorschläge werden gerne angenommen.