Sécuriser son serveur et son client OpenSSH

Bonjour à tous,

La configuration par défaut du client et du serveur SSH (OpenSSH) dispose de problèmes de sécurité assez conséquents, il est donc idéal d’y remédier.

Vous avez besoin d’une version d’OpenSSH très récente pour reproduire cette procédure. J’ai utilisé la version 6.7 incluse dans Debian Jessie pour ce faire :

OpenSSH_6.7p1 Debian-5+deb8u2, OpenSSL 1.0.1t  3 May 2016

Si vous utilisez Windows, vous devrez télécharger Putty DEV et non Putty Stable.

Authentification par clé publique :

Générez une clé privée ed25519 (avec une passphrase!!!) :

ssh-keygen -t ed25519

Ensuite, copiez la clé publique sur tous les serveurs que vous souhaitez gérer depuis votre poste :

ssh-copy-id -i ~/.ssh/id_ed25519.pub sshuser@host

Sécuriser la partie serveur (SSHD) :

Faites une sauvegarde de votre fichier de configuration :

cp /etc/ssh/sshd_config /etc/ssh/sshd_config.rabbit

Et éditez-le :

nano /etc/ssh/sshd_config

Éditez le port d’écoute d’OpenSSH :

Port 22

Choisissez un port au hasard (au-dessus de 1024 de préférence), par exemple  :

Port 10124

Si vous avez plusieurs interfaces, vous pouvez dédier une IPV4/6 au management avec les lignes suivantes :

ListenAddress ::
ListenAddress 0.0.0.0

Désactivez la connexion directe en root avec cette ligne :

PermitRootLogin no

Vous pouvez aussi autoriser des utilisateurs spécifiques en ajoutant la ligne suivante :

AllowUsers user1 user2

Désactivez ensuite l’authentification par mot de passe (uniquement lorsque l’authentification par clé publique est fonctionnelle!)  :

PermitEmptyPasswords no
PasswordAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile      %h/.ssh/authorized_keys

Désactivez l’utilisation des clés DSA, RSA et ECDSA (qui sont faibles et tonchées par le NIST). Commentez juste les lignes suivantes :

#HostKey /etc/ssh/ssh_host_dsa_key
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key

Et soyez sûr d’avoir la ligne suivante :

HostKey /etc/ssh/ssh_host_ed25519_key

Spécifiez ensuite les paramètres d’échanges et d’authentification :

KexAlgorithms curve25519-sha256@libssh.org
Ciphers chacha20-poly1305@openssh.com
MACs umac-128-etm@openssh.com,umac-128@openssh.com

Redémarrez enfin le serveur OpenSSH :

service sshd restart

Sécuriser la partie client (SSH) :

Faites une sauvegarde de votre fichier de configuration :

cp /etc/ssh/ssh_config /etc/ssh/ssh_config.rabbit

Et éditez-le :

nano /etc/ssh/ssh_config

Virez la configuration existante et placez celle-ci :

HashKnownHosts yes
Host *
  ConnectTimeout 30
  KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
  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
  Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
  ServerAliveInterval 10
  ControlMaster auto
  ControlPersist yes
  ControlPath ~/.ssh/socket-%r@%h:%p

Comme vous pouvez le voir, on autorise plus de choses que dans la partie serveur.

Comme ça, ça ne sera pas bloquant avec des versions d’OpenSSH un poil plus anciennes..

Si vous n’utilisez que des serveurs SSH configurés avec cette procédure alors, appliquez la configuration suivante :

HashKnownHosts yes
Host *
  ConnectTimeout 30
  KexAlgorithms curve25519-sha256@libssh.org
  Ciphers chacha20-poly1305@openssh.com
  MACs umac-128-etm@openssh.com,umac-128@openssh.com
  ServerAliveInterval 10
  ControlMaster auto
  ControlPersist yes
  ControlPath ~/.ssh/socket-%r@%h:%p

Configurer SSHFP

Si vous avez DNSSEC activer sur les serveurs DNS de votre domaine, alors il est intéressant d’utiliser des enregistrements SSHFP pour authentifier les signatures SSH de vos serveurs en utilisant le DNS.

Lancez la commande suivante sur chacun de vos serveurs :

ssh-keygen -r domain.com -f /etc/ssh/ssh_host_ed25519_key.pub

Vous aurez un résultat comme celui-ci :

domain.com IN SSHFP 4 1 d305e4851588958f9074356f0a2b6ea7c59708a8
domain.com IN SSHFP 4 2 66b627ea6687d41b80dc5399b5292a3f1488ea0d9c353814d09ffa2ce1192a9b

Vous pouvez garder uniquement la partie SSHFP 4 2 vu que ed25519 n’utilise de toute façon pas SHA1 :

domain.com IN SSHFP 4 2 66b627ea6687d41b80dc5399b5292a3f1488ea0d9c353814d09ffa2ce1192a9b

Ajoutez simplement cet enregistrement dans vos DNS.

Ensuite, lancez la commande suivante pour activer la vérification des enregistrements SSHFP avant la connexion :

echo "VerifyHostKeyDNS yes" >> /etc/ssh/ssh_config && service ssh restart

Cacher le serveur SSH derrière un pare-feu

Dernière chose, vous pouvez également planquer votre port SSH avec UFW (ou Iptables) en autorisant la connexion uniquement depuis votre adresse IP.

Installez UFW :

apt-get install ufw -y

Définissez les règles par défaut (on accepte tout en sortie et on refuse tout en entrée) :

ufw default deny incoming
ufw default allow outgoing

Maintenant, autorisez SSH uniquement depuis votre adresse IP (changez IPV4/6 et 22 avec votre configuration):

ufw allow from IPV4 to any port 22
ufw allow from IPV6 to any port 22

Autorisez les autres ports comme le web en accès publique :

ufw allow 80
ufw allow 443

Et activez la bête :

ufw enable

Source

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