Configuring SSH to use only trusted encryption algorithms” bigfatcc review

A free translation of Secure Secure Shell has been published, analyzing problematic encryption algorithms that could potentially be used by the NSA to launch attacks against SSH, as well as providing practical advice on how to improve SSH security. This includes showing how to run an SSH server as a hidden Tor service.

In light of reports that the NSA is launching attacks aimed at gaining control of SSH connections, guidance has been prepared with recommendations for strengthening SSH security. The NSA can gain control of an SSH connection by using vulnerable encryption methods or by hijacking private keys. Below are tips for disabling potentially problematic algorithms and strengthening security.

Key exchange.

The DH (Diffie-Hellman) and ECDH (Elliptic Curve Diffie-Hellman) key exchange methods used in SSH can be considered secure. Among 8 SSH-supported key exchange protocols, three based on NIST recommendations are suspicious: ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521. Protocols using potentially problematic SHA1 can also be considered not trustworthy. The curve25519-sha256 and diffie-hellman-group-exchange-sha256 protocols are so far not questionable for security.

To use only trusted key exchange protocols, specify the following in /etc/ssh/sshd_config for the server:

KexAlgorithms [emailprotected],diffie-hellman-group-exchange-sha256

Similar settings for the client, in /etc/ssh/ssh_config:

Host * KexAlgorithms [emailprotected],diffie-hellman-group-exchange-sha256

In /etc/ssh/moduli you can specify (or delete lines with a key size smaller than 2048):

ssh-keygen -G /tmp/moduli -b 4096 ssh-keygen -T /etc/ssh/moduli -f /tmp/moduli

Authentication.

SSH supports four public key authentication algorithms: DSA, ECDSA, Ed25519 and RSA. ECDSA is tied to NIST technologies and must be disabled. Unfortunately, if you simply remove an ECDSA key, it will be re-generated, so you can use a workaround by creating a known non-functional symbolic link that prevents the key from being generated and used:

cd /etc/ssh rm ssh_host_ecdsa_key* rm ssh_host_key* ln -s ssh_host_ecdsa_key ssh_host_ecdsa_key ln -s ssh_host_key ssh_host_key

As DSA key size cannot exceed 1024, it too should be disabled in the same way:

cd /etc/ssh rm ssh_host_dsa_key* ln -s ssh_host_dsa_key ssh_host_dsa_key

Next, take care of RSA by generating a larger key:

cd /etc/ssh rm ssh_host_rsa_key* ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key /dev/null

To create client keys it is better to use the following commands:

ssh-keygen -t ed25519 ssh-keygen -t rsa -b 4096

Symmetric ciphers.

Of the 15 symmetric encryption algorithms supported by SSH used to secure the established communication channel, chacha20-poly1305, aes*-ctr and aes*-gcm can be considered secure. The 3des-cbc and arcfour ciphers are potentially vulnerable due to the use of DES and RC4, cast128-cbc applies too short a block size (64 bits).

As a result, it is recommended to add the following to /etc/ssh/sshd_config:

Ciphers [emailprotected],[emailprotected],[emailprotected],aes256-ctr,aes192-ctr,aes128-ctr

В /etc/ssh/ssh_config:

Host * Ciphers [emailprotected],[emailprotected],[emailprotected],aes256-ctr,aes192-ctr,aes128-ctr

Message Authenticity Code (MAC).

For CTR ciphers, only the Encrypt-then-MAC method (*-etm, MAC is added to an already encrypted block) is trustworthy for guaranteeing the integrity of transmitted blocks. The MAC-then-encrypt and Encrypt-and-MAC methods are potentially vulnerable to attacks. Out of 18 MAC algorithms available for SSH one should immediately discard those based on MD5 and SHA1 hashes which are not collision-proof, as well as those using key sizes under 128 bits and tag sizes under 256 bits. As a result, hmac-sha2-512-etm and hmac-sha2-256-etm can be considered the most secure MACs.

В /etc/ssh/sshd_config:

MACs [emailprotected],[emailprotected]

В /etc/ssh/ssh_config:

Host * MACs [emailprotected],[emailprotected]

Key leak protection.

The easiest way to gain control of an SSH connection is to capture keys on the client or server side. Recommendations boil down to following typical rules for maintaining system security:

promptly install updates, install software from trusted sources only, install only software and services that you really need, use software for which the source code is available, enable additional security mechanisms (Grsecurity, build with the -fstack-protector flag).

.

To protect keys, you should choose a strong password to access the client key files. When generating a key, the ssh-keygen -o -a number option can be used to increase the number of hashing iterations, making the password more difficult to guess. It is also possible to store keys only on an external medium, connecting it only during an SSH connection.

Protection from transit traffic analysis.

An SSH server can be configured as a hidden Tor service, which hides the IP and also adds an extra layer of encryption and authentication.

You can use the following settings to accept connections only through the hidden Tor service:

In /etc/ssh/sshd_config (to accept connections from LAN, use mesh screen instead of binding to 127.0.0.1 to restrict access):

ListenAddress 127.0.0.1:22

In /etc/tor/torrc add:

HiddenServiceDir /var/lib/tor/hidden_service/ssh HiddenServicePort 22 127.0.0.1:22

The hidden host name to connect to can be found in /var/lib/tor/hidden_service/ssh/hostname.

To configure the client connection to the hidden Tor service, you can add:

to /etc/ssh/ssh_config

Host *.onion ProxyCommand socat SOCKS4A:localhost:%h:%p,socksport=9050

Source: stribika.github.io/2015/01/04/secure-secure-shell.html

Addendum: comments on the recommendations given in the article : cypherpunks.ru/articles/securing_ssh.html

bigfatcc review

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *