Voici les paramètres les plus sécurisés pour un serveur SSH adaptable à tous les systèmes *NIX. Pour les explications voir les sources:
Aujourd’hui la clé RSA 4096 est le meilleur rapport qualité/compatibilité mais vous pouvez déjà commencer à utiliser ED25519 pour les OS récents.
Régénération du moduli
awk '$5> 2000' /etc/ssh/moduli> “${HOME}/moduli”; wc -l “${HOME}/moduli”; sudo mv “${HOME}/moduli” /etc/ssh/moduli
Création du moduli
sudo ssh-keygen -G /etc/ssh/moduli.all -b 4096; sudo ssh-keygen -T /etc/ssh/moduli.safe -f /etc/ssh/moduli.all; sudo mv /etc/ssh/moduli.safe /etc/ssh/moduli; sudo rm /etc/ssh/moduli.all
Régénération des clés serveur
cd /etc/ssh; sudo rm ssh_host_*key*; sudo ssh-keygen -t ed25519 -f ssh_host_ed25519_key </dev/null; sudo ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key </dev/null
Régénération des clés client
ssh-keygen -t ed25519 -o -a 100; ssh-keygen -t rsa -b 4096 -o -a 100
Copie des clés
ssh-copy-id -i .ssh/id_rsa.pub nomduserveur
ssh-copy-id -i .ssh/id_ed25519.pub nomduserveur
La ligne à mettre dans /etc/ssh/sshd_config :
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
Et dans /etc/ssh/ssh_config :
# Github a parfois besoin de diffie-hellman-group-exchange-sha1, mais pas toujours
#Host github.com
# KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1
Host *
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
Si vous choisissez d’activer le 5, ouvrez /etc/ssh/moduli s’il existe et supprimez les lignes où la cinquième colonne est inférieure à 2000 :
awk '$5> 2000' /etc/ssh/moduli> "${HOME}/moduli"
wc -l "${HOME}/moduli" # Assure-vous que le fichier généré ne soit pas vide
sudo mv "${HOME}/moduli" /etc/ssh/moduli
OKL: awk '$5> 2000' /etc/ssh/moduli> “${HOME}/moduli”; wc -l “${HOME}/moduli”; sudo mv “${HOME}/moduli” /etc/ssh/moduli
Ou s’il n’existe pas, créez-le :
sudo ssh-keygen -G /etc/ssh/moduli.all -b 4096 sudo ssh-keygen -T /etc/ssh/moduli.safe -f /etc/ssh/moduli.all sudo mv /etc/ssh/moduli.safe /etc/ssh/moduli sudo rm /etc/ssh/moduli.all
OKL: sudo ssh-keygen -G /etc/ssh/moduli.all -b 4096; sudo ssh-keygen -T /etc/ssh/moduli.safe -f /etc/ssh/moduli.all; sudo mv /etc/ssh/moduli.safe /etc/ssh/moduli; sudo rm /etc/ssh/moduli.all
Cette étape risque de prendre un peu de temps… Environ 4h sur mun petit Intel Core i3-4010U CPU @ 1.7GHz.
La ligne à mettre dans /etc/ssh/sshd_config
Protocol 2 HostKey /etc/ssh/ssh_host_ed25519_key HostKey /etc/ssh/ssh_host_rsa_key
La configuration ci-dessus désactive aussi la v1 du protocole SSH, troué de partout et qui de toute manière ne devrait JAMAIS être activée. Nous pouvons aussi supprimer les clés inutilisées et générées par OpenSSH lors de son installation afin de regénérer des clés RSA et Ed25519 plus longues et plus robustes.
cd /etc/ssh sudo rm ssh_host_*key* sudo ssh-keygen -t ed25519 -f ssh_host_ed25519_key </dev/null sudo ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key </dev/null
OKL: cd /etc/ssh; sudo rm ssh_host_*key*; sudo ssh-keygen -t ed25519 -f ssh_host_ed25519_key </dev/null; sudo ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key </dev/null
La configuration recommandée pour /etc/ssh/sshd_config :
PasswordAuthentication no ChallengeResponseAuthentication no
La configuration recommandée pour /etc/ssh/ssh_config :
Host *
PasswordAuthentication no
ChallengeResponseAuthentication no
La méthode la plus sûre et la plus répandue passe par l’utilisation d’une clé publique, tout comme l’authentification du serveur évoquée précédemment.
Côté serveur (/etc/ssh/sshd_config) cela donne :
PubkeyAuthentication yes
Et côté client (/etc/ssh/ssh_config) :
Host *
PubkeyAuthentication yes
HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ssh-rsa
Les clés SSH peuvent être générées avec les commandes suivantes :
ssh-keygen -t ed25519 -o -a 100 ssh-keygen -t rsa -b 4096 -o -a 100
OLK: ssh-keygen -t ed25519 -o -a 100; ssh-keygen -t rsa -b 4096 -o -a 100
Et le déploiement de vos nouvelles clés publique via ssh-copy-id.
ssh-copy-id -i .ssh/id_ed25519.pub utilisateur@serveur
La directive AllowUsers dans /etc/ssh/sshd_config vous permet de spécifier quels sont les utilisateurs autorisés à se connecter via SSH. Mais cela peut s’avérer compliqué si vous avez à gérer un nombre important d’utilisateurs. D’autant plus que si vous supprimez l’un d’entre eux, celui-ci ne sera pas retiré de /etc/ssh/sshd_config, ce qui alourdit encore plus la maintenance. Une solution possible est de se tourner vers AllowGroups à la place, et d’ajouter un groupe ssh-users sur votre machine par exemple.
Ce qui donnerait dans /etc/ssh/sshd_config:
AllowGroups ssh-users
Rappels pour créer le groupe et ajouter un utilisateur dedans :
sudo groupadd ssh-users sudo usermod -a -G ssh-users utilisateur
On a donc pour /etc/ssh/sshd_config :
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
Et pour /etc/ssh/ssh_config
Host *
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
L’extrait pour /etc/ssh/sshd_config :
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
Et pour /etc/ssh/ssh_config :
Host *
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
/etc/ssh/ssh_config :
Host *
UseRoaming no
Vous devriez utiliser un mot de passe fort pour la clé privée de votre client. Vous pouvez en plus utiliser ssh-keygen -o -a pour ralentir les tentatives de cassage en itérant la fonction de hash plusieurs fois.