Sécuriser son serveur et son client OpenSSH

1/52/53/54/55/5 (2 votes, moyenne: 5,00 sur 5)
Loading...
S

Attention, cet article a plus d'une année d'ancienneté. Il est possible que les informations présentées ne soient plus à jour, spécialement dans le cadre d'un article technique.


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

A propos de l'auteur

Nicolas Simond

Ingénieur Systèmes et Réseaux et guitariste hard rock et metal à mes heures perdues.
Je suis le créateur et l'unique rédacteur d'Abyss Project, c'est ici que je note la plupart de mes procédures et quelques divagations.

Si vous l'article vous a aidé, pensez à me payer un café :)

Subscribe
Notify of
guest

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

8 Commentaires
Plus récents
Plus anciens Populaires
Inline Feedbacks
View all comments
Nomad
Nomad
7 années plus tôt

Générez une clé privée ed25519 (avec une passphrase!!!) : En SSH local (sur ordinateur) ou sur le serveur ?

(au-dessus de 1024 de préférence) ou au dessus de 10124 ?

Nomad
Nomad
7 années plus tôt

Salut,
une clé ed25519 est plus forte qu’une clé rsa 4096 ?

Toi qui connais un peu Scaleway, toute les étapes de ce tuto sont bonnes à prendre ?
(j’ai déjà des intrusions sur mon nouveau serveur mail…)

Novakin
7 années plus tôt

Salut Nico,

Le mieux est d’utiliser AllowGroups plutot qu’AllowUsers. Ca évite de modifier la configuration ssh à chaque fois qu’on veut autoriser un utilisateur.

Lionel
Lionel
7 années plus tôt

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

Ce n’est pas plutôt l’inverse ? ?