alh Posté(e) 18 avril 2017 Share Posté(e) 18 avril 2017 Bonjour à toute l'équipe, Je reposte ici une demande d'évolution concernant la config SSH (côté serveur) de ssh.web4all.fr (et qui concerne aussi sans doute tous les serveurs w4a utilisant SSH) qui était sur l'ancien forum. Première chose le bout de code à ajouter à /etc/ssh/sshd_config : HostKey /etc/ssh/ssh_host_ed25519_key HostKey /etc/ssh/ssh_host_ecdsa_key HostKey /etc/ssh/ssh_host_rsa_key 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,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com UsePrivilegeSeparation sandbox AuthenticationMethods publickey,keyboard-interactive:pam UsePAM yes Seconde, le constat : https://tls.imirhil.fr/ssh/ssh.web4all.fr:22 Comme le montre très bien CryptCheck, la config SSH est un peu faiblarde (particulièrement au niveau chiffrement et MAC). Maintenant le pourquoi du bout de code : pour renforcer sensiblement la sécurité et l'intégrité des données échangées avec les clients modernes qui supportent des chiffrements forts et laisser cependant les clients obsolètes se connecter tout de même sans souci. L'utilisation de clefs serveurs ed25519 et ecdsa ne devrait pas trop surcharger les serveurs, alors que RSA reste présent pour la compatibilité. Edit : c'est également dans les recommandations de Mozilla concernant la sécurité : https://wiki.mozilla.org/Security/Guidelines/OpenSSH Merci d'étudier la demande a l'occasion. Et je rajoute -- pour ceux que cela intéresse -- le pendant pour la config SSH client (Protocol 2 uniquement, évidement) : # Pour chaque Host, des règlages spécifiques, qui peuvent écrasés ceux défini de manière générale (cf. section Host *) : Host 10.0.0.1 IdentityFile ~/.ssh/id_ecdsa_key_example.org X11Forwarding no ForwardX11Trusted yes IdentitiesOnly yes Host myvnc.example.org User root IdentityFile ~/.ssh/id_ecdsa_key_example.org X11Forwarding no ForwardX11Trusted yes IdentitiesOnly yes Host ssh.example.net User xxx-w4a IdentityFile ~/.ssh/id_ecdsa_key_ssh.example.net IdentitiesOnly yes Host www.example.net User web IdentityFile ~/.ssh/id_ecdsa_key_web.example.net IdentitiesOnly yes Host xyz.example.com User username IdentityFile ~/.ssh/id_ed25519_example.com IdentitiesOnly yes Host 192.168.* IdentityFile ~/.ssh/id_ed25519_local_lan IdentitiesOnly yes Host *.biz User username IdentityFile ~/.ssh/id_ed25519_local_business_lan ForwardAgent yes IdentitiesOnly yes Host github.com User username MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-128-etm@openssh.com,hmac-sha2-512 IdentityFile ~/.ssh/id_ed25519_github IdentitiesOnly yes # Config général pour tous les hosts et ceux non définis ci-dessus : Host * Protocol 2 # SSH v1 est à éviter absolument ! SendEnv LANG LC_* IdentitiesOnly yes HashKnownHosts yes StrictHostKeyChecking ask CheckHostIP yes RhostsAuthentication no RhostsRSAAuthentication no RSAAuthentication yes PubkeyAuthentication yes PasswordAuthentication yes X11Forwarding no ConnectTimeout 30 HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ssh-rsa,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256 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 # Cipher ... est commenté puisse que ne concerne que SSH v1 # IdentityFile ~/.ssh/id_rsa aucune clef n'est proposée par défaut, elle doit être définie spécifiquement pour chaque serveur. 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 L'utilisation de IdentitiesOnly yes permet de limiter les clefs SSH envoyées pour l'identification aux seules clefs spécifiées pour le serveur en question. Cela évite à un serveur de récupérer le fingerprint de toutes les clefs (coucou le tracking des utilisateurs) alors qu'il existe une clef spécifiquement dédiée pour celui-ci 2 Lien vers le commentaire Partager sur d’autres sites More sharing options...
Administrateurs Benoît G Posté(e) 18 avril 2017 Administrateurs Share Posté(e) 18 avril 2017 Bonjour, je vous remercie d'avoir (de nouveau) posté cette demande. Je vais l'étudier et valider sur les serveurs SSH publique pour l'accès client. C'est effectivement très pertinent . Merci ! 1 Lien vers le commentaire Partager sur d’autres sites More sharing options...
alh Posté(e) 20 avril 2017 Auteur Share Posté(e) 20 avril 2017 On peu aussi faire du 2 facteurs avec SSH, mais c'est peut-être un poil trop geek ? https://wiki.mozilla.org/Security/Guidelines/OpenSSH#Multi-Factor_Authentication_.28OpenSSH_6.3.2B.29 1 Lien vers le commentaire Partager sur d’autres sites More sharing options...
Recommended Posts
Créer un compte ou se connecter pour commenter
Vous devez être membre afin de pouvoir déposer un commentaire
Créer un compte
Créez un compte sur notre communauté. C’est facile !
Créer un nouveau compteSe connecter
Vous avez déjà un compte ? Connectez-vous ici.
Connectez-vous maintenant