SSH & X2GO - Host Key Types, Key Exchange Algorithms, Encryption Ciphers

Discuss
1

Bonjour,

Je m’inquiète de la sécurité ssh de mon yunohost, j’ai beau être qu’un utilisateur sans trop de connaissance, j’ai beaucoup lu ces dernières semaines, et je suis tombé sur un site qui permet de réaliser un test SSH sur les Host Key Types, Key Exchange Algorithms, et Encryption Ciphers.

Le site en question : https://www.ssh-audit.com/

Donc j’ai testé le ssh yunohost avec une modification personnelle, une clé privé-publique et je n’ai obtenu q’un résultat de D- 62/100

A noter que le site explique que :

Because of a bug in OpenSSH, 2048-bit DH moduli will still be used in some limited circumstances. Only a maximum score of 95% is possible.

Attention pour celles et ceux qui utilise X2GO

Source : x2go [Wiki ubuntu-fr]

Ceci n’est pas à proprement parlé d’un bug, mais d’une incompatibilité :slight_smile:

Pour que la connexion se fasse, il faut que le client et le serveur se mettent d’accord sur les algorithmes de chiffrement à utiliser.

Évidemment, cela ne peut se faire qu’entre ceux connus par les deux membres, et par défaut le serveur SSH considère que tous ceux que connaît le client X2Go ne sont plus assez sûr :

Le serveur souhaite utiliser des algorithmes de chiffrement plus sûrs. hmac-sha2-512-etm@openssh.com, hmac-sha2-256-etm@openssh.com, umac-128-etm@openssh.com, hmac-sha2-512,hmac-sha2-256, hmac-ripemd160

Le client X2Go connaît peu de MACs et aucune contenant -etm hmac-sha2-256, hmac-sha2-512, hmac-sha1

The algorithms that contain “-etm” calculate the MAC after encryption (encrypt-then-mac). These are considered safer and their use recommended. 3)

La méthode suivante permet certes d’utiliser X2Go mais en abaissant le niveau de sécurité du serveur.

Est-il possible d’améliorer le score de ce test ou est-ce totalement inutile ?

Merci pour votre précieuse aide.

1 Like
2

Salut,

effectivement on est basé sur la recommendation de Mozilla et je n’avais pas vu la ligne en bas (peut-être qu’elle est nouvelle) :

https://infosec.mozilla.org/guidelines/openssh

All Diffie-Hellman moduli in use should be at least 3072-bit-long (they are used for diffie-hellman-group-exchange-sha256) as per our Key management Guidelines recommendations. See also man moduli.

To deactivate short moduli in two commands: awk '$5 >= 3071' /etc/ssh/moduli > /etc/ssh/moduli.tmp && mv /etc/ssh/moduli.tmp /etc/ssh/moduli

Du coup ce serait bien d’inclure cette commande dans Yunohost.

Si tu veux faire une contrib ~facile, je pense qu’il suffit d’ajouter la commande ici : yunohost/03-ssh at dev · YunoHost/yunohost · GitHub

3

Heu là j’avoue que même si cela te parait facile @Aleks pour moi non, Github ça ressemble à mon éditeur de code mais après j’y comprends absolument rien.

C’est vraiment très gentil de me tendre une perche pareille mais je n’ai pas le niveau :sob: je ne vois même pas où placer la commande :slight_smile:

4

Bonjour,

Merci de la trouvaille, je suis aussi curieux de retours pour améliorer tout ça.
La commande en question ne semble rien changer au score chez moi :thinking:

5

Et si on ajoute cela :
$ echo -e "\nKexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512\nCiphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr\nMACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com" >> /etc/ssh/sshd_config

Je mets par contre des # devant les lignes si après pour la configuration de base du fichier sshd_config

By default use "modern" Mozilla configuration Keys, ciphers and MACS

KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com

et mon score vient de passer à C- 72/100

Reste plus qu’à trouver la bonne formule pour HostKeyAlgorithms

HostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com

Erreur SSH avec cette ligne là

6

Et moi de F à D- :laughing:

edit: je n’avais pas la bonne ligne, C- aussi.

7

Plus d’infos ici → Sécurité | Yunohost Documentation
:exclamation:ATTENTION VALABLE UNIQUEMENT AVEC ED25519
:exclamation:NE changez pas votre sshd_config si vous ne savez pas ce que vous faites
:exclamation:A adapter selon la sécurité que vous utilisez sur votre yunohost

Avec cette ligne en plus :

HostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com

Je suis A+ 100/100 :slight_smile:

Donc résumé :slight_smile:

Modifier le sshd_config (et j’ai celui généré par yunohost avec juste une clé ed25519) avec cette commande :

nano /etc/ssh/ssd_config
puis on met les règles en silencieux en mettant un # devant chaque ligne :

KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com

On ajoute ces lignes là :

KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com

HostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com

On redemarre SSH

systemctl restart ssh
On teste : https://www.ssh-audit.com/ ou ssh-audit disponible dans les dépots debian 10 avec la commande ssh-audit adresseip:port -v

:exclamation: Une autre solution pour celles et ceux qui utilise X2GO
Mon score est de A+ 98/100

KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-256,hmac-sha2-512
HostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com

:exclamation:Augmenter la sécurité :

Vous pouvez ajouter ou modifier →

Si vous utilisez une connexion par clé publique privé (consulter fr/SSH - Debian Wiki)
AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2

LoginGraceTime 30
Le fait de définir une valeur (en secondes) inférieure permet d’éviter certaines attaques par déni de service lorsque plusieurs sessions d’authentification sont maintenues ouvertes pendant une période prolongée.

PermitRootLogin no
Se connecter en ROOT est interdit

StrictModes yes

:volcano:PubkeyAuthentication yes
Authentification par clé publique (uniquement pour connection clé privé-publique)

PermitEmptyPasswords no
pas de mot de passe vide

PasswordAuthentication no
pas d’authentification par mot de passe

ChallengeResponseAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no

UsePAM no
passwd utilise PAM pour authentifier les utilisateurs et modifier leur mot de passe

DebianBanner no
désactiver la bannière SSH verbeuse activée par défaut, car elle montre diverses informations sur votre système, telles que la version du système d’exploitation

  • Restreindre tous les utilisateurs à une adresse IP spécifique :
    AllowUsers *@250.0.125.1

  • Restreindre tous les utilisateurs à une plage d’adresse IP spécifique :
    AllowUsers *@250.0.125.0/24

  • Restreindre tous les utilisateurs à une plage d’adresse IP spécifique (en utilisant des jokers) :
    AllowUsers *@250.0.125.*

  • Restreindre tous les utilisateurs à plusieurs adresses IP et à plusieurs plages spécifiques :
    AllowUsers *@250.0.125.1 *@250.0.125.2 *@192.168.1.0/24 *@172.16.*.1

  • Interdire tous les utilisateurs à l’exception des utilisateurs nommés à partir d’adresses IP spécifiques :
    AllowUsers asterix@250.0.125.1 obelix@250.0.125.2

1 Like
8

Je ne comprends pas ce que tu veux dire par là.

9

Ah bien c’est étrange, chez moi y’a plus de connexion possible dans ce cas là, et idem pour le site d’audit :thinking:
Ça semble trop restrictif… mais pas dans ton cas, pourquoi ? :thinking:

10

Je veux dire que mettre ça #
désactive les lignes correspondantes dans le fichier ainsi ssh ne les prend plus en compte, et ainsi ça évite de les supprimer, si éventuellement on veut les réutiliser

11

Ah oui ok, en voyant ton fichier je vois que t’avais des lignes en plus de moi, je comprends mieux.

12

Du coup y a plus qu’à attendre la validation par @Aleks ou la communauté.

1 Like
13

En fait en début de fichier il me manquait: HostKey /etc/ssh/ssh_host_ed25519_key

14

Hmpf ben ok mais :

  • on suis plus ou moins aveuglément la recommendation de Mozilla leur recommendation n’inclu pas pas cette ligne. (oui “aveuglément” ça fait peur dit comme ça, mais à un moment la sécu c’est compliqué et réinventer soi-même la roue c’est dangereux dans ce cas.)
  • je veux que ton site préféré de check de ta conf SSH te donne un joli A+ tout vert et plein d’arc-en-ciel, mais typiquement ces sites ne t’indique jamais ce que ça a comme coût pour la compatibilité. En l’occurence, désactiver les clefs rsa peut bloquer certains clients SSH (par ex. Putty, enfin je n’en sais rien, je dis ça au pif, mais il peut y’avoir des effets de bords). En l’occurence, dans Yunohost y’a toujours le “legacy” : potentiellement pleins de gens accèdent à leur serveur via l’identité RSA du serveur, et si on désactive ça du jour au lendemain ils vont avoir potentiellement un gros warning flippant à leur prochaine connexion … Ça veut pas dire qu’il faut pas le faire, mais il faut faire gaffe.
1 Like
15

effectivement je raisonne qu’avec ma sécurité ed25519 en oubliant les autres :nerd_face:
Voici ce qu’ils disent sur le site et comme je n’utilise pas RSA ça fonctionne pas chez moi

HostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,rsa-sha2-256,rsa-sha2-512,rsa-sha2-256-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com

https://www.ssh-audit.com/hardening_guides.html

16

Il y a avait un mécanisme de settings il me semble via security.ssh.compatibility pour avoir des configurations plus ‘avancée’. Est-ce qu’on ne pourra pas l’intégrer à ce niveau ?