Rien, comme dit tout dépend de ton usage, même avec un firewall si tu fais n’importe quoi tu risques de te faire OWNED et si tu respecte une hygiène de moine un firewall peut très bien être facultatif.
1 J'aime
Un portable tu peux te promener avec et te connecter à des réseaux publics, donc tu n’est plus derrière le pare feu de ta box. Et donc un assaillant peut tenter de se connecter a ton pc puisqu’il n’y a pas de pare-feu. Si tu ferme ton pare feu aux requêtes extérieures tu peux sortir mais personne ne peut rentrer par une connection que tu n’as pas ouvert toi. Évidemment si tu ouvre une connections vers un site douteux ben c’est risqué
Après qu’est ce que peut faire exactement le dit pirate je n’ai pas la notion.
Non, un pare-feu n 'est jamais facultatif. Croire qu’on peu éviter des compromission juste parce qu’on aurait une « hytgiène » quelconque, c’est comme croire qu’on est pas atteint de l’herpès. Tout le monde le pense, mais 99% de la population mondiale est porteuse.
Cesses donc de rabâcher tes propos à tord et à travers … tu fais une réelle fixette sur la sécurité.
Je peux te ramener au moins trois postes en Windows sans aucune firewall et tu ne trouvera aucun signe de compromission dessus, idem avec au moins 2 postes sous Ubuntu et Debian.
Bien entendu je sais ce que je fais et je pousses personnes à faire de même sans réflexion de sa part.
PS : Un firewall n’empêchera pas non plus l’exploitation de faille de sécurité ou un manque de sécurité.
Comment tu t’en assures?la plupart des système compromis ca ne se voit pas en mode normal.
Ce n’est pas une fixette, c’est une réalité qui fait parti de mon travail.
Il y a des compromission que tu ne verras jamais sans un audit sérieux.
je suis d’accord sur ce qui est ouvert.
Le parefeu ne fait pas tout le travail, mais sans lui, le reste risque de ne servir à rien.
Je travaille sur des dizaines d’incidents de sécurité ou la base de la réponse est celle que tu viens de donner.
De la même manière que tu t’assures qu’il soit compromis 
bref …
J’utilise différents outils d’audit, comme OpenVAS, Lynis, et quelques autres 
Le parefeu ce n’est pas la panacée, mais c’est comme la capote, c’est le minimum.
Merci pour ces éléments de réponse.
En résumé, je laisse comme c’est . . .
J’ai fini par installer un pare-feu, celui du tutoriel de mistermat Configurer son pare-feu sous Debian 13 avec GUFW, en toute simplicité
Zargos, arrête de faire peur aux gens . . . 
ça c’est rien, si tu veux que je te fasse peur j’ai mieux.
Non c’est de la prévenance, car il y a plein de cas où ça se passe mal alors que c’est très facile à régler pour 99% des cas. Comme tu l’as fait, installer gufw, et activer à minima le profil domestique et public.
Le profil public est à activer uniquement si connexion à des réseaux publiques (wifi, trucs comme ça) ?
en fait les trois profils de base, et ceux que tu peux créer, sont ceux que tu active en fonction de l’utilisation. Mais en termes de contenu des règles, celles de base sont les même.
Par exemple, en domestique tu peux autoriser SSH pour ton administration.
mais en profil public tu le bloques.
Tu bloques dans quel sens et pourquoi?
En public j’interdis toute connexion vers la machine en SSH. Alors qu’en domestique ou même en entreprise tu peux laisser l’accès vers le port 22 ouvert pour des raisons d’administration par exemple.
Ou pour être plus exact j’ai une règle d’ouverture du SSH que dans mon profil domestique. Je blackliste tout, sauf ce qui est dans ma white list, en quelque sorte.
En gros:
Domestique:
ACCEPT(SSH) net:lan fw
DROP any any any
(fw est la machine elle même)
Public:
DROP net any any
net est la zone dans laquelle est l’interface réseau de la machine.
Tu parles de la machine sur laquelle tu travailles donc. Mais j’avoue que je ne comprends pas trop pourquoi. Pour les machines sensibles, je ne met que l’authentification par clef mais je n’ai jamais interdit une connexion vers ma machine en ssh.Ça pollue les logs au pire. Je suis plus réservé sur d’autres services en revanche, mais pas ssh
Si ton SSH est configuré par défaut, il n’est pas fiable, même avec des clefs. Il y a pas mal d’éléments de configuration par défaut qui rendent un serveur SSH vulnérable.
Comme n’importe quel programme openssh a aussi des vulnérabilités avec ou sans clefs. IL y a celle qui sont liées à la programmation et qui sont patchées; mais celles qui sont du à une mauvaise configuration, elles, restent ouvertes jusqu’à modification de la configuration.
La bonne règle quand s’agit d’un pare-feu c’est de tout bloqué en provenance de l’extérieur sauf ce que tu as expressément besoin.
En clair ne pas travailler en blacklist mais en whitelist.
Tu as des exemples?
Les suivantes, bien que ce ne soit plus à jour:m
#######################
# SSHD configuration
#######################
#
logger -p syslog.info -i " $FNAME: SSHD Configuration"
# Ensure permissions on /etc/ssh/sshd_config are configured
logger -p syslog.info -i " $FNAME: Ensure permissions on /etc/ssh/sshd_config are configured"
chown root:root /etc/ssh/sshd_config
chmod og-rwx /etc/ssh/sshd_config
# Configure protocol and listen parameters
sed -Ei 's/^[#]*\s*Port.*/Port 22/' /etc/ssh/sshd_config
sed -Ei 's/^[#]*\s*AddressFamily.*/AddressFamily any/' /etc/ssh/sshd_config
sed -Ei 's/^[#]*\s*ListenAddress\s0\.0\.0\.0/ListenAddress 192.168.1.200:19682/' /etc/ssh/sshd_config
sed -Ei '/^ListenAddress\s192\.168\.2\.254/a ListenAddress 192.168.11.254' /etc/ssh/sshd_config
sed -Ei '/^ListenAddress\s192\.168\.5\.254/a ListenAddress 192.168.14.254' /etc/ssh/sshd_config
sed -Ei 's/^[#]*\s*ListenAddress\s\:\:/ListenAddress fdc0:12b:ff55:1921:6810::fe/' /etc/ssh/sshd_config
sed -Ei '/^ListenAddress\s fcc0:12b:ff55:1921:6820::fe/a ListenAddress fdc0:12b:ff55:1921:6840::fe' /etc/ssh/sshd_config
# Ensure permissions on SSH private host key files are configured
#logger -p syslog.info -i " $FNAME: Ensure permissions on SSH private host key files are configured"
l_skgn="ssh_keys" # Group designated to own openSSH keys
l_skgid="$(awk -F: '($1 == "'"$l_skgn"'"){print $3}' /etc/group)"
awk '{print}' <<< "$(find /etc/ssh -xdev -type f -name 'ssh_host_*_key' -exec stat -L -c "%n %#a %U %G %g" {} +)" | (while read -r l_file l_mode l_owner l_group l_gid; do
[ -n "$l_skgid" ] && l_cga="$l_skgn" || l_cga="root"
[ "$l_gid" = "$l_skgid" ] && l_pmask="0137" || l_pmask="0177"
l_maxperm="$( printf '%o' $(( 0777 & ~$l_pmask )) )"
if [ $(( $l_mode & $l_pmask )) -gt 0 ]; then
echo -e " - File: \"$l_file\" is mode \"$l_mode\" changing to mode: \"$l_maxperm\""
if [ -n "$l_skgid" ]; then
chmod u-x,g-wx,o-rwx "$l_file"
else
chmod u-x,go-rwx "$l_file"
fi
fi
if [ "$l_owner" != "root" ]; then
echo -e " - File: \"$l_file\" is owned by: \"$l_owner\" changing owner to \"root\""
chown root "$l_file"
fi
if [ "$l_group" != "root" ] && [ "$l_gid" != "$l_skgid" ]; then
echo -e " - File: \"$l_file\" is owned by group \"$l_group\" should belong to group \"$l_cga\""
chgrp "$l_cga" "$l_file"
fi
done)
# Ensure permissions on SSH public host key files are configured
logger -p syslog.info -i " $FNAME: Ensure permissions on SSH public host key files are configured"
find /etc/ssh -xdev -type f -name 'ssh_host_*_key.pub' -exec chmod u-x,go-wx {} \;
find /etc/ssh -xdev -type f -name 'ssh_host_*_key.pub' -exec chown root:root {} \;
# Ensure SSH access is limited
logger -p syslog.info -i " $FNAME: Ensure SSH access is limited"
addgroup sshgroup
usermod -a -G sshgroup zargos
#sed -Ei 's/^(sshgroup.*)/\1zargos/' /etc/group
printf "
# Ensure SSH access is limited
AllowGroups sshgroup
" > /etc/ssh/sshd_config.d/sshd_cis.conf
logger -p syslog.info -i " $FNAME: /etc/ssh/sshd_config configuration modification"
# Ensure SSH root login is disabled
logger -p syslog.info -i " $FNAME: Ensure SSH root login is disabled"
sed -Ei 's/^[#]*\s*PermitRootLogin\s+.*/PermitRootLogin no/' /etc/ssh/sshd_config
# Ensure SSH HostbasedAuthentication is disabled
logger -p syslog.info -i " $FNAME: Ensure SSH HostbasedAuthentication is disabled"
sed -Ei 's/^[#]*\s*HostbasedAuthentication\s+.*/HostbasedAuthentication no/' /etc/ssh/sshd_config
# Ensure SSH IgnoreRhosts is enabled
logger -p syslog.info -i " $FNAME: Ensure SSH IgnoreRhosts is enabled"
sed -Ei 's/^[#]*\s*IgnoreRhosts\s+.*/IgnoreRhosts yes/' /etc/ssh/sshd_config
# Ensure SSH PermitEmptyPasswords is disabled
logger -p syslog.info -i " $FNAME: Ensure SSH PermitEmptyPasswords is disabled"
sed -Ei 's/^[#]*\s*PermitEmptyPasswords\s+.*/PermitEmptyPasswords no/' /etc/ssh/sshd_config
# Ensure SSH PermitUserEnvironment is disabled
logger -p syslog.info -i " $FNAME: Ensure SSH PermitUserEnvironment is disabled"
sed -Ei 's/^[#]*\s*PermitUserEnvironment\s+.*/PermitUserEnvironment no/' /etc/ssh/sshd_config
# Ensure SSH X11 forwarding is disabled
logger -p syslog.info -i " $FNAME: Ensure SSH X11 forwarding is disabled"
sed -i '0,/^[#]*\s*X11Forwarding/s/^\([#]*\s*X11Forwarding\s+.*\)/X11Forwarding no/' /etc/ssh/sshd_config
# Ensure SSH AllowTcpForwarding is disabled
logger -p syslog.info -i " $FNAME: Ensure SSH AllowTcpForwarding is disabled"
sed -i '0,/^[#]*\s*AllowTcpForwarding/s/^\([#]*\s*AllowTcpForwarding\s+.*\)/AllowTcpForwarding no/' /etc/ssh/sshd_config
# Ensure only strong Ciphers are used
logger -p syslog.info -i " $FNAME: Ensure only strong Ciphers are used"
sed -Ei '/^[#]\s*Ciphers and keying/a Ciphers chacha20-poly1305\@openssh.com,aes256-gcm\@openssh.com,aes128-gcm\@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr' /etc/ssh/sshd_config
# Ensure only strong Key Exchange algorithms are used
logger -p syslog.info -i " $FNAME: Ensure only strong Key Exchange algorithms are used"
sed -Ei '/^Ciphers\s+/a KexAlgorithms curve25519-sha256,curve25519-sha256\@libssh.org,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256' /etc/ssh/sshd_config
# Ensure only strong MAC algorithms are used
logger -p syslog.info -i " $FNAME: Ensure only strong MAC algorithms are used"
sed -Ei '/^KexAlgorithms\s+/a MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm\@openssh.com,hmac-sha2-512,hmac-sha2-256' /etc/ssh/sshd_config
# Ensure SSH warning banner is configured
logger -p syslog.info -i " $FNAME: Ensure SSH warning banner is configured"
sed -Ei 's/^[#]*\s*Banner none/Banner \/etc\/issue.net/' /etc/ssh/sshd_config
# Ensure SSH MaxAuthTries is set to 4 or less
logger -p syslog.info -i " $FNAME: Ensure SSH MaxAuthTries is set to 4 or less"
sed -Ei 's/^[#]*\s*MaxAuthTries.*/MaxAuthTries 4/' /etc/ssh/sshd_config
# Ensure SSH MaxStartups is configured
logger -p syslog.info -i " $FNAME: Ensure SSH MaxStartups is configured"
sed -Ei 's/^[#]*\s*MaxStartups.*/MaxStartups 10:30:60/' /etc/ssh/sshd_config
# Ensure SSH MaxSessions is set to 10 or less
logger -p syslog.info -i " $FNAME: Ensure SSH MaxSessions is set to 10 or less"
sed -Ei 's/^[#]*\s*MaxSessions.*/MaxSessions 10/' /etc/ssh/sshd_config
# Ensure SSH LoginGraceTime is set to one minute or less
logger -p syslog.info -i " $FNAME: Ensure SSH LoginGraceTime is set to one minute or less"
sed -Ei 's/^[#]*\s*LoginGraceTime.*/LoginGraceTime 60/' /etc/ssh/sshd_config
# Ensure SSH Idle Timeout Interval is configured
logger -p syslog.info -i " $FNAME: Ensure SSH Idle Timeout Interval is configured"
sed -Ei 's/^[#]*\s*ClientAliveInterval.*/ClientAliveInterval 15/' /etc/ssh/sshd_config
sed -Ei 's/^[#]*\s*ClientAliveCountMax.*/ClientAliveCountMax 3/' /etc/ssh/sshd_config
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.
et c’est juste avec les mauvaises configurations.