Ah, là tu parles d’une machine multi utilisateurs où tu anticipes les erreurs des utilisateurs et potentiellement leur malveillance. Mais par exemple pour moi, le X11 forwarding, le TCP forwarding (dans les 2 sens d’ailleurs) sont essentiels. Cela dit les failles actuelles de openssh sont surtout des deni de service, sur une machine perso ça ne me stresse pas trop, au contraire d’un serveur
[de mémoire il y a eu surtout les clefs foireuses de debian et une faille type «race condition» permettant un accès root il y a quelques années comme failles dangereuses]
Je considère toute machine de cette façon, même si je suis le seul à l’utiliser.
Je n’en fait jamais en dehors d’un tunnel. X11 n’est pas suffisamment fiable pour passer sur un réseau.
Une simple question sur duckduckgo AI:
Voici les principales attaques possibles liées à une mauvaise configuration d'OpenSSH (Secure Shell) :
1. Attaques par force brute (Brute Force)
Description : Tentative de deviner les mots de passe ou les clés privées en testant systématiquement des combinaisons.
Vulnérabilités :
Utilisation de mots de passe faibles.
Autorisation de l'authentification par mot de passe (PasswordAuthentication yes).
Pas de restriction sur le nombre de tentatives (MaxAuthTries trop élevé).
Solutions :
Désactiver l'authentification par mot de passe (PasswordAuthentication no).
Utiliser des clés SSH (RSA/ECDSA/Ed25519) avec passphrase forte.
Limiter les tentatives (MaxAuthTries 3).
Utiliser des outils comme Fail2Ban pour bloquer les IP suspectes.
2. Attaques par clé SSH faible ou mal configurée
Description : Exploitation de clés SSH mal générées ou obsolètes.
Vulnérabilités :
Utilisation de clés RSA < 2048 bits (vulnérable aux attaques quantiques ou par factorisation).
Clés DSA (obsolètes et non sécurisées).
Clés partagées ou stockées dans des emplacements non sécurisés (~/.ssh/id_rsa sans permissions strictes).
Solutions :
Utiliser des clés Ed25519 (recommandé) ou RSA 4096 bits.
Restreindre les permissions des clés (chmod 600 ~/.ssh/id_ed25519).
Désactiver les algorithmes faibles (HostKeyAlgorithms dans /etc/ssh/sshd_config).
3. Attaques par rebond (SSH Tunneling / Port Forwarding)
Description : Utilisation d'un serveur SSH compromis pour relayer des connexions vers d'autres machines.
Vulnérabilités :
Autorisation du port forwarding (AllowTcpForwarding yes).
Pas de restriction sur les utilisateurs autorisés à créer des tunnels.
Solutions :
Désactiver le port forwarding (AllowTcpForwarding no).
Restreindre les utilisateurs avec AllowUsers ou Match dans sshd_config.
4. Attaques par usurpation (Man-in-the-Middle - MITM)
Description : Interception des communications entre client et serveur SSH.
Vulnérabilités :
Pas de vérification stricte des clés hôtes (StrictHostKeyChecking no).
Utilisation de serveurs SSH avec des clés faibles ou non vérifiées.
Solutions :
Activer StrictHostKeyChecking yes et UserKnownHostsFile pour valider les clés.
Utiliser des clés hôtes fortes (Ed25519 ou RSA 4096 bits).
5. Attaques par déni de service (DoS)
Description : Saturation du service SSH pour le rendre inaccessible.
Vulnérabilités :
Pas de limitation des connexions simultanées (MaxStartups trop élevé).
Pas de protection contre les attaques par flooding.
Solutions :
Limiter les connexions (MaxStartups 10:30:60).
Utiliser un pare-feu (iptables/nftables) pour bloquer les IP suspectes.
Désactiver les versions obsolètes de SSH (Protocol 2 uniquement).
6. Attaques par escalade de privilèges
Description : Exploitation de failles pour obtenir des droits root.
Vulnérabilités :
Autorisation de PermitRootLogin yes.
Pas de restriction sur les commandes exécutables (ForceCommand mal configuré).
Solutions :
Désactiver PermitRootLogin (utiliser sudo à la place).
Restreindre les commandes avec ForceCommand ou Command dans authorized_keys.
7. Attaques par fuite d'informations
Description : Récupération d'informations sensibles via des fuites de configuration.
Vulnérabilités :
Affichage de bannières ou de versions vulnérables (PrintMotd yes).
Fichiers de logs mal sécurisés (/var/log/auth.log accessibles).
Solutions :
Désactiver PrintMotd ou personnaliser la bannière.
Restreindre les permissions des logs (chmod 600 /var/log/auth.log).
8. Attaques par rebond de session (SSH Hijacking)
Description : Prise de contrôle d'une session SSH active.
Vulnérabilités :
Pas de protection contre les sessions persistantes (ClientAliveInterval mal configuré).
Solutions :
Configurer ClientAliveInterval 300 et ClientAliveCountMax 2 pour tuer les sessions inactives.
9. Attaques par injection de commandes
Description : Exécution de commandes arbitraires via des variables d'environnement.
Vulnérabilités :
Autorisation de AcceptEnv pour des variables dangereuses (ex: LD_PRELOAD).
Solutions :
Désactiver AcceptEnv ou limiter les variables autorisées.
10. Attaques par configuration par défaut dangereuse
Description : Utilisation de paramètres OpenSSH par défaut non sécurisés.
Exemples :
PermitEmptyPasswords yes (autorise les mots de passe vides).
X11Forwarding yes (risque de fuite d'affichage graphique).
Solutions :
Toujours vérifier /etc/ssh/sshd_config et appliquer les bonnes pratiques.
Bonnes pratiques pour sécuriser OpenSSH
Désactiver l'authentification par mot de passe :
ini
PasswordAuthentication no
Utiliser des clés SSH fortes :
bash
ssh-keygen -t ed25519 -a 100 # Génération d'une clé Ed25519
Restreindre les utilisateurs :
ini
AllowUsers user1 user2
Désactiver les fonctionnalités inutiles :
ini
PermitRootLogin no
X11Forwarding no
AllowTcpForwarding no
Configurer les timeouts :
ini
ClientAliveInterval 300
ClientAliveCountMax 2
Mettre à jour OpenSSH :
bash
sudo apt update && sudo apt upgrade openssh-server
Outils pour auditer la configuration
sshd -T : Affiche la configuration active.
ssh-audit : Outil pour tester la sécurité d'OpenSSH.
`lynis : Audit de sécurité système.
En appliquant ces mesures, vous réduisez significativement les risques liés à une mauvaise configuration d'OpenSSH.
Et au passage avec ssh_audit sur une machine chez moi (pas la mieux protégé, mais ssh n’est pas activé par défaut):
~# ssh-audit -4 -p 22022 localhost
# general
(gen) banner: SSH-2.0-OpenSSH_10.0p2 Debian-7+deb13u4
(gen) software: OpenSSH 10.0p2
(gen) compatibility: OpenSSH 9.9+, Dropbear SSH 2020.79+
(gen) compression: enabled (zlib@openssh.com)
# key exchange algorithms
(kex) mlkem768x25519-sha256 -- [info] available since OpenSSH 9.9
`- [info] hybrid key exchange based on post-quantum resistant algorithm and proven conventional X25519 algorithm
(kex) sntrup761x25519-sha512 -- [info] available since OpenSSH 9.9
`- [info] default key exchange since OpenSSH 9.9
`- [info] hybrid key exchange based on post-quantum resistant algorithm and proven conventional X25519 algorithm
(kex) sntrup761x25519-sha512@openssh.com -- [info] available since OpenSSH 8.5
`- [info] default key exchange from OpenSSH 9.0 to 9.8
`- [info] hybrid key exchange based on post-quantum resistant algorithm and proven conventional X25519 algorithm
(kex) curve25519-sha256 -- [info] available since OpenSSH 7.4, Dropbear SSH 2018.76
`- [info] default key exchange from OpenSSH 7.4 to 8.9
(kex) curve25519-sha256@libssh.org -- [info] available since OpenSSH 6.4, Dropbear SSH 2013.62
`- [info] default key exchange from OpenSSH 6.5 to 7.3
(kex) ecdh-sha2-nistp256 -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency
`- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp384 -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency
`- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp521 -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency
`- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) ext-info-s -- [info] available since OpenSSH 9.6
`- [info] pseudo-algorithm that denotes the peer supports RFC8308 extensions
(kex) kex-strict-s-v00@openssh.com -- [info] pseudo-algorithm that denotes the peer supports a stricter key exchange method as a counter-measure to the Terrapin attack (CVE-2023-48795)
# host-key algorithms
(key) rsa-sha2-512 (3072-bit) -- [info] available since OpenSSH 7.2
(key) rsa-sha2-256 (3072-bit) -- [info] available since OpenSSH 7.2, Dropbear SSH 2020.79
(key) ecdsa-sha2-nistp256 -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency
`- [warn] using weak random number generator could reveal the key
`- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(key) ssh-ed25519 -- [info] available since OpenSSH 6.5, Dropbear SSH 2020.79
# encryption algorithms (ciphers)
(enc) chacha20-poly1305@openssh.com -- [info] available since OpenSSH 6.5, Dropbear SSH 2020.79
`- [info] default cipher since OpenSSH 6.9
(enc) aes256-gcm@openssh.com -- [info] available since OpenSSH 6.2
(enc) aes128-gcm@openssh.com -- [info] available since OpenSSH 6.2
(enc) aes256-ctr -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52
(enc) aes192-ctr -- [info] available since OpenSSH 3.7
(enc) aes128-ctr -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52
# message authentication code algorithms
(mac) hmac-sha2-256-etm@openssh.com -- [info] available since OpenSSH 6.2
(mac) hmac-sha2-512-etm@openssh.com -- [info] available since OpenSSH 6.2
(mac) hmac-sha1-etm@openssh.com -- [fail] using broken SHA-1 hash algorithm
`- [info] available since OpenSSH 6.2
(mac) umac-128@openssh.com -- [warn] using encrypt-and-MAC mode
`- [info] available since OpenSSH 6.2
(mac) hmac-sha2-256 -- [warn] using encrypt-and-MAC mode
`- [info] available since OpenSSH 5.9, Dropbear SSH 2013.56
(mac) hmac-sha2-512 -- [warn] using encrypt-and-MAC mode
`- [info] available since OpenSSH 5.9, Dropbear SSH 2013.56
(mac) hmac-sha1 -- [fail] using broken SHA-1 hash algorithm
`- [warn] using encrypt-and-MAC mode
`- [info] available since OpenSSH 2.1.0, Dropbear SSH 0.28
# fingerprints
(fin) ssh-ed25519: SHA256:Eou/UP9vVXgP7XCPExBWaDhpOgxbMNIqI1zpxTHJR9E
(fin) ssh-rsa: SHA256:2Mtzzzo+rZMxJ07ldB3AbUeiDb3WukotXkct5VTUJxY
# additional info
(nfo) Be aware that, while this target properly supports the strict key exchange method (via the kex-strict-?-v00@openssh.com marker) needed to protect against the Terrapin vulnerability (CVE-2023-48795), all peers must also support this feature as well, otherwise the vulnerability will still be present. The following algorithms would allow an unpatched peer to create vulnerable SSH channels with this target: chacha20-poly1305@openssh.com. If any CBC ciphers are in this list, you may remove them while leaving the *-etm@openssh.com MACs in place; these MACs are fine while paired with non-CBC cipher types.