Sécuriser son serveur et son client OpenSSH

//Sécuriser son serveur et son client OpenSSH
1/52/53/54/55/5 (2 votes, moyenne: 5,00 sur 5)
Loading...

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

By |2016-08-20T13:38:52+00:0020 août 2016|GNU/Linux|8 Comments

About the Author:

Diplômé d'un BTS SIO SISR et travaillant actuellement en Suisse, je suis passionné par tout ce qui touche à l'informatique et la musique hard rock et métal depuis ma plus tendre enfance. Je suis le créateur et l'unique rédacteur d'Abyss Project, ce blog qui me sert de bloc-notes public en quelque sorte.

8
Poster un Commentaire

avatar
4 Comment threads
4 Thread replies
0 Followers
 
Most reacted comment
Hottest comment thread
4 Comment authors
NomadNovakinNicolas SimondLionel Recent comment authors

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

Plus récents Plus anciens Populaires
Nomad
Invité
Nomad

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
Invité
Nomad

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
Invité

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
Invité
Lionel

> 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 ? ?