• github (comme gitlab, non mentionné par l'auteur) permet de lister les clés SSH publiques d'un utilisateur
• quelqu'un a compilé la table de toutes les clés, permettant de retrouver un utilisateur github à partir de n'importe laquelle de ses clés présentes sur github
• en pratique, les clients SSH annoncent la clé publique au serveur pour lui demander si elle est acceptée par celui-ci avant d'utiliser la clé privée

Tout ça mis bour à bout permet de :

• pour un serveur SSH : tenter de trouver l'identifiant github du quidam qui se connecte
• pour un curieux : en essayant toutes les clés publiques de la table (très long!), trouver l'identifiant github de personnes ayant accès à un serveur en particulier
• (non mentionné par l'auteur) établir la correspondance entre les comptes d'un même développeur sur plusieurs plateformes (savoir que HaxORR_du_91 sur github est Robert Dupont sur gitlab)

Il s'agit donc d'une belle fuite involontaire de données personnelles.

Pour se prémunir de telles attaques, il convient d'utiliser des clés SSH dédiées aux connexions sur les forges. Par exemple en générant une clé dédiée :

$ ssh-keygen -f ~/.ssh/id_git_ed25519 -t ed25519

Puis en indiquant uniquement ces clés à github/gitlab et en indiquant dans votre .ssh/config :

Host github.com gitlab.com [ou tout autre forge]
    IdentityFile ~/.ssh/id_git_ed25519.pub

Notez aussi que si vous utilisez une clé GPG publique comme back-end d'authentification SSH (ce qui est une bonne idée en soi !), on peut recalculer votre clé SSH publique avec l'option --generate-ssh-key (merci au collègue qui m'a transmis l'astuce).

L'OSINT a de beaux jours devant elle!

En 2019 Matrix a subi une intrusion sur ses serveurs. Ils en retirent plusieurs recommandations.

Sur le plan technique :

• Ne PAS utiliser l'agent forwarding avec SSH, privilégier le ProxyJump (-J)
• placer le fichier authorized_keys sous le contrôle de root plutôt que sous celui de l'utilisateur
• avoir des procédés automatisés pour détecter les mises à jour à lettre en œuvre
• segmenter le réseau, limiter les privilèges au minimum nécessaire

Sur le plan organisationnel:

• ils notent le danger des infrastructures (ou outils) "legacy", maintenus en fonctionnement et laissés en l'état quand les efforts se concentrent sur une nouvelle architecture/version plus sûre: il faut impérativement avoir une personne en responsabilité de lettre fin à cette situation.
• il faut des check-lists pour la remise en route des services et la rotation des secrets
• lors d'un incident, il faut quelqu'un pour coordonner les travaux, gérer la communication interne et la communication externe: si peuvent être remplies par la même personne, il s'agit bien de 3 missions distincted

Le proxy SSH fonctionne de façon similaire au proxy HTTP avec CONNECT :

• le client C ouvre une session SSH (http) vers le proxy P
• dans cette session, il demande l'ouverture d'une connexion TCP par le proxy vers le serveur S de destination
• le serveur ouvre la connexion et la redirige vers le client (il encapsule la session TCP dans la session SSH ou HTTP)
• via cette nouvelle connexion TCP, le client démarre une nouvelle session SSH ou HTTP vers S.

Plusieurs conséquences:

• si les conditions de sécurité sont réunies, le proxy ne peut ni déchiffrer ni altérer la communication entre le client et le serveur de destination (conditions réunies = usage de TLS et de certificat valide pour HTTP et préconnaissance mutuelle du serveur et du client pour SSH ou usage de SSHFP ou usage de PKI SSH)
• le proxy P connait l'adresse du client et l'adresse et le nom du serveur de destination (si le client demande un serveur par son nom plutôt que par IP), sauf si plusieurs proxies sont utilisés pour atteindre la destination.
• le serveur S de destination ne voit plus l'adresse du client, mais seulement celle du proxy.

C'est donc une forme de connexion bien plus sécurisée que par l'usage du SSH agent forwarding, qui permet au serveur proxy P d'usurper l'identité du client C auprès de n'importe quel serveur.

Voir aussi man ssh_config#ProxyJump

Un petit pas en matière de sécurité, facile à faire : sécuriser ses clés SSH (que ce soit des clés pour l'administration système, pour git, ou whatever) : en plus de les protéger par mot de passe, il faut que la protection par mot de passe soit bien fichue, avec une fonction lente de dérivation de clé (pbkdf). Pour générer une nouvelle clé avec des options correctes :

ssh-keygen -o

Pour protéger une clé déjà existante avec ce nouveau chiffrement :

ssh-keygen -o -p -f ~/.ssh/fichier_de_cle_privee