Nach neuesten Erkenntnissen [2] und [3] ist die NSA nicht nur an HTTPS-Verkehr, sondern auch an SSH interessiert. Es ist aber nicht so, dass SSH grundsätzlich geknackt ist, sondern dass SSH-Verkehr nur unter gewissen Umständen entziffert werden kann. Werden entsprechend gute Cipher verwendet, ist auch für die NSA eine Entschlüsselung derzeit nicht möglich. Wie bei HTTPS sollten bei SSH nur die Cipher eingestellt werden, die derzeit als sicher gelten. Das ist auch nötig, da selbst in aktuellen Betriebssystemversionen (z.B. Ubuntu 12.04 LTS und 14.04 LTS) unter anderem auch RC4 möglich ist, was inzwischen als hinreichend unsicher gilt.
Bei OpenSSH werden die Ciphers nicht mit einem Kommando festgelegt. Es werden der Schlüsselaustausch, das symmetrische Kryptoverfahren und die Authenzität mit drei getrennten Kommandos eingestellt. Diese Werte können für den Server (/etc/ssh/sshd_config) und für den Client (/etc/ssh/ssh_config) auf demselben Weg konfiguriert werden. SSH beherrscht unter neueren Linux-Versionen mehr Cipher. Welche unterstützt werden, sind in der Man Page unter den entsprechenden Schlüsselwörtern einsehbar.
Key Exchange
Die Schlüsselaustausch-Algorithmen für den symmetrischen Verschlüsselungsalgorithmus wird mit dem Schlüsselwort KexAlgorithms konfiguriert. Grundsätzlich sollte hier Perfect Forward Secracy verwendet werden. Das hat den Vorteil, dass selbst für mitgeschnittenen Traffic der Schlüssel nur durch Brute Force ermittelt werden muss. Hier sind je nach Version folgende Algorithmen in ihrer Reihenfolge sinnvoll:
- curve25519-sha256@libssh.org
- diffie-hellman-group-exchange-sha256
- diffie-hellman-group-exchange-sha1
- diffie-hellman-group14-sha1
- diffie-hellman-group1-sha1
Clientseitig kann noch folgende Option ergänzt werden, damit nach 64 MByte Traffic ein neuer symmetrischer Schlüssel ausgehandelt wird. Das erschwert zusätzlich noch das Knacken der Daten.
RekeyLimit 64M
Symmetrische Verschlüsselung
Die symmetrische Verschlüsselung wird mit dem Schlüsselwort Ciphers konfiguriert. Auch hier eine Liste der entsprechenden Ciphers:
- chacha20-poly1305@openssh.com
- aes256-gcm@openssh.com
- aes256-ctr
- aes256-cbc
- aes128-ctr
- aes128-cbc
Message authentication codes
Hierfür wird das Schlüsselwort MACs verwendet. Grundsätzlich sollte kein MD5 oder SHA1 verwendet werden, da sie inzwischen als weich gelten. Leider können einige SSH-Varianten keine besseren MACs als SHA1, sodass man hierauf leider noch nicht vollständig verzichten kann. Auch sollten mindestens 128 Bit verwendet werden. In den neuesten SSH-Varianten gibt es noch die Encrypt-then-Mac-Varianten, die als noch sicherer gelten. Hier die Liste der möglichen MACs:
- hmac-sha2-512-etm@openssh.com
- hmac-sha2-256-etm@openssh.com
- hmac-sha2-512
- hmac-sha2-256
- hmac-sha1
Für ein Ubuntu 12.04 LTS sähe eine entsprechende Konfiguration folgendermaßen aus:
sshd_config
Ciphers aes256-ctr,aes128-ctr,aes256-cbc,aes128-cbc KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 MACs hmac-sha2-512,hmac-sha1
Außer den Ciphers gibt es noch weitere Einstellungen, auf die Wert gelegt werden sollte. So sollte grundsätzlich Public Key Authentication eingesetzt werden und die Passwort-Authentifizierung abgeschaltet werden:
PubkeyAuthentication yes PasswordAuthentication no
Welche Algorithmen ein Client verwenden darf, kann zentral in der Datei /etc/ssh/ssh_config eingestellt werden. Es gibt aber noch zusätzlich die Möglichkeit, in der Datei $HOME/.ssh/config Ausnahmen zu konfigurieren, da meist ältere Hosts nicht ganz so sichere Algorithmen benutzen können. So muss man nicht die Algorithmen auf den kleinsten gemeinsamen Nenner bringen, sondern kann die besten Algorithmen als Default einsetzen.
Will man sich auf einem anderen Host einloggen, können die ausgehandelten Algorithmen und Werte mit ssh -vv eingesehen werden:
... debug1: kex: server->client chacha20-poly1305@openssh.com none debug1: kex: client->server chacha20-poly1305@openssh.com none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<8192<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: bits set: 4052/8192 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY ... debug1: Host 'trusty' is known and matches the ECDSA host key. ... debug2: bits set: 4089/8192 debug1: ssh_ecdsa_verify: signature correct ...
Abschließende Bemerkungen
Wie bei allen asymmetrischen Verfahren ist es auch bei SSH wichtig, dass der Private Key nicht verloren geht und mit einer ausreichend harten Passphrase gesichert ist. Aus den Snowden-Dokumenten geht hervor, dass die NSA stark an den Private Keys interessiert ist und unter Umständen mit allen Mitteln versucht, an diese zu kommen. Gerade wenn keine Perfect Forward Secrecy eingesetzt wird ist das ein Problem, weil damit rückwirkend aufgezeichneter Traffic im Nachhinein entschlüsselt werden kann.
Referenzen:
- https://stribika.github.io/2015/01/04/secure-secure-shell.html
- http://www.spiegel.de/netzwelt/netzpolitik/snowden-dokument-so-unterminiert-die-nsa-die-sicherheit-des-internets-a-1010588.html
- http://www.heise.de/security/artikel/SSH-SSL-IPsec-alles-kaputt-kann-das-weg-2514013.html
- http://www.openssh.com/