Kuck mal, wer da hört - OpenSSH 6.8
Nachdem wir nun drei Monate lang OpenSSH 6.7 getestet haben, sind wir jetzt so mutig und tauschen sshd, der auf Port 22 lauscht, gegen eine aktuelle Version aus: OpenSSH 6.8.
Wir verwenden dabei die folgende Konfiguration:
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com
Netter Nebeneffekt: Wir unterstützten nun ed25519. Alle Hosts haben bereits entsprechende Keys:
HostKey /etc/ssh/ssh_host_ed25519_key
Weiterhin unterstützen wir natürlich noch RSA:
HostKey /etc/ssh/ssh_host_rsa_key
Wir unterstützen kein DSA (mehr) und kein ECDSA. Das Datenblatt ist entsprechend angepasst, hier findet ihr wie gewohnt die Fingerprints. Ebenso werden wir das Host Manifest um die ed25519-Keys erweitern (hier gibt’s dann ein Update im Artikel).
Warum diese Cipher?
OpenSSH unterstützt derzeit (Version 6.8) fünfzehn Cipher:
1. 3des-cbc
2. aes128-cbc
3. aes192-cbc
4. aes256-cbc
5. aes128-ctr
6. aes192-ctr
7. aes256-ctr
8. aes128-gcm@openssh.com
9. aes256-gcm@openssh.com
10. arcfour (RC4 mit 128 Bit Schlüssel)
11. arcfour128 (RC4 mit 128 Bit Schlüssel und Verwerfen der ersten 1536 Byte des Schlüsselstroms)
12. arcfour256 (RC4 mit 256 Bit Schlüssel und Verwerfen der ersten 1536 Byte des Schlüsselstroms)
13. blowfish-cbc
14. cast128-cbc
15. chacha20-poly1305@openssh.com
3DES und RC4 gelten als so gut wie gebrochen. Das eliminiert die Optionen 1, 10, 11 und 12.
CAST128 14 verwendet zwar einen 128 Bit langen Schlüssel, hat intern aber eine Blockgröße von 64 Bit und ist damit unsicher. Das eliminiert Option 14.
Blowfish schwächelt, sein Autor Bruce Schneier empfiehlt Twofish (das OpenSSH leider nicht unterstützt, andere SSH-Implementationen schon). Das eliminiert Option 13.
AES ist ein aktueller Blockcipher, wird hier aber im CBC-Modus verwendet. CBC ist problematisch, es gibt praktische Attacken dagegen. Das eliminiert eigentlich die Optionen 2, 3, 4, und 14. (Siehe Update #1)
AES im CTR- oder GCM-Modus (einem speziellen CTR-Modus) gilt derzeit als sicher. Die Optionen 5, 6, 7, 8 und 9 sind akzeptabel.
ChaCha20 ist ein aktueller Streamcipher und gilt derzeit als sicher. Option 15 ist auch akzeptabel.
Warum diese MAC-Verfahren?
OpenSSH unterstützt derzeit (Version 6.8) achtzehn MAC-Verfahren:
1. hmac-md5
2. hmac-md5-96
3. hmac-ripemd160
4. hmac-sha1
5. hmac-sha1-96
6. hmac-sha2-256
7. hmac-sha2-512
8. umac-64
9. umac-128
10. hmac-md5-etm@openssh.com
11. hmac-md5-96-etm@openssh.com
12. hmac-ripemd160-etm@openssh.com
13. hmac-sha1-etm@openssh.com
14. hmac-sha1-96-etm@openssh.com
15. hmac-sha2-256-etm@openssh.com
16. hmac-sha2-512-etm@openssh.com
17. umac-64-etm@openssh.com
18. umac-128-etm@openssh.com
MD5 ist gebrochen. Es gibt bisher zwar noch keine praktischen Attacken gegen die spezifische Kombination von HMAC mit MD5, aber warum warten? Das eliminiert die Optionen 1, 2, 10 und 11.
SHA1 schwächelt, es wird empfohlen auf SHA2 oder SHA3 zu migrieren. Es gibt bisher zwar noch keine praktischen Attacken gegen die spezifische Kombination von HMAC mit SHA1, aber warum warten? Wir eliminieren also eigentlich die Optionen 4, 5, 13 und 14. (Siehe Update #2)
Es gibt auch einige Verfahren die schlicht zu kurze Schlüssel oder erzeugen zu kurze Hashes. Das eliminiert die Optionen 8 und 17, sowie zusätzlich die Optionen 1, 2, 5, 10, 11 und 14, die aber bereits eliminiert sind.
Es bleiben uns also die Verfahren 16, 15, 12, 18, 7, 6, 3 und 9.
Warum kein DSA?
DSA Keys sind nur 1024 Bit groß und damit inzwischen unsicher und sollten daher nicht mehr verwendet werden. Größere DSA-Keys wären theoretisch möglich, sind aber für SSH nicht spezifiziert (in RFCs) und das hat auch niemand mehr vor, weil DSA langsam ist und auch sonst von Experten nicht geschätzt wird.
Warum kein ECDSA?
ECDSA-Keys können abhängig von der verwendeten Elliptischen Kurve unterschiedlich groß sein, das Problem sind die spezifischen Elliptischen Kurven die hier verwendet werden. Außerdem erben ECDSA-Keys die Probleme von DSA.
Warum RSA und ED25519?
Bleiben also RSA, bei dem wir 4096 Bit lange Keys verwenden (länger geht derzeit nicht, 4096 Bit sollte hoffentlich noch für die nächsten 10 bis 20 Jahre gut sein) und ed25519, was derzeit als sicher gilt.
Schicke Neuerungen in OpenSSH 6.8
host key rotation support
Mit der neu hinzugekommenen Option UpdateHostkeys kann sich der Client nun alle host keys vom Server holen und in die known_hosts eintragen. UpdateHostkeysist eine Einstellung, die in der Konfiguration des Clients gesetzt werden muss und standardmäßig aus ist.
Probleme
Natürlich (wie sollte es auch anders sein) gibt es Clients, die Probleme mit der Konfiguration (die wir uns wünschen) haben:
Wir mussten daher wohl oder übel diffie-hellman-group14-sha1 mit in die KexAlgorithms aufnehmen, obwohl wir das eigentlich nicht geplant hatten und wir behalten uns vor, den Eintrag in Zukunft zu entfernen.
Falls gar nichts geht: Auf Port 4022 bis auf Weiteres ein sshd ohne die angepasste Konfiguration. Mittelfristig werden wir diesen aber abschalten, wenn es Probleme mit bestimmten Clients auf Port 22 gibt: Bitte gebt uns Bescheid.
Credits
Ehre wem Ehre gebührt: Wir haben uns das nicht alles selbst überlegt sondern haben einen Großteil der Konfiguration von stribika übernommen, der hier hervorragende Arbeit geleistet hat. Vielen Dank an dieser Stelle.
Update #1 (08.05.2015)
Aus Kompatibilitätsgründen haben wir aes256-cbc,aes192-cbc,aes128-cbc trotz Bedenken erst mal wieder aktiviert.
Update #2 (11.05.2015)
Aus Kompatibilitätsgründen haben wir hmac-sha1 trotz Bedenken erst mal wieder aktiviert.