voir un accès root gratuit si le souci de config est au niveau de sshd lui-même.
(je suis l'auteur de Thrussh, et un des auteurs de Pijul)
Ça a été ma principale motivation pour écrire Thrussh. Avant, Pijul marchait à travers le client OpenSSH. Et même en temps qu'utilisateur de NixOS et NixOps, je ne sentais pas trop la configuration d'un serveur OpenSSH qui fasse appel à une base de données pour vérifier les clefs des utilisateurs, et serve en même temps pour ouvrir un shell.
Nest.pijul.com a un serveur Thrussh qui écoute les clients demander une ouverture de session, l'exécution d'un programme, mais ne fait rien de tout ça, et se contente de faire croire au client qu'il l'a fait. Quand un client présente une clef, le serveur vérifie qu'elle est dans la base de données. Ensuite, quand il demande une commande shell, le serveur la parse avec une regexp, appelle la fonction correspondante, et renvoie un code d'erreur.
La principale idée est que le code qui a le moins de failles de sécurité est celui qui n'est pas écrit.
Après, quand tu as écrit un serveur, écrire un client n'est pas bien difficile, et ça permet de tester plus en détail. J'ai récemment été assez content de voir que j'avais raison de me méfier des solutions existantes (https://www.cvedetails.com/cve/CVE-2018-10933/). Écrire de l'asynchrone en Rust te force à définir proprement l'automate du protocole, ça évite ce genre de blagues par construction (il y a sans doute plein de trous de sécurité que ça n'évite pas, hein).
[^] # Re: On peut troller ou faut attendre vendredi ?
Posté par pmeunier . En réponse au journal Pijul 0.11. Évalué à 2.
(je suis l'auteur de Thrussh, et un des auteurs de Pijul)
Ça a été ma principale motivation pour écrire Thrussh. Avant, Pijul marchait à travers le client OpenSSH. Et même en temps qu'utilisateur de NixOS et NixOps, je ne sentais pas trop la configuration d'un serveur OpenSSH qui fasse appel à une base de données pour vérifier les clefs des utilisateurs, et serve en même temps pour ouvrir un shell.
Nest.pijul.com a un serveur Thrussh qui écoute les clients demander une ouverture de session, l'exécution d'un programme, mais ne fait rien de tout ça, et se contente de faire croire au client qu'il l'a fait. Quand un client présente une clef, le serveur vérifie qu'elle est dans la base de données. Ensuite, quand il demande une commande shell, le serveur la parse avec une regexp, appelle la fonction correspondante, et renvoie un code d'erreur.
La principale idée est que le code qui a le moins de failles de sécurité est celui qui n'est pas écrit.
Après, quand tu as écrit un serveur, écrire un client n'est pas bien difficile, et ça permet de tester plus en détail. J'ai récemment été assez content de voir que j'avais raison de me méfier des solutions existantes (https://www.cvedetails.com/cve/CVE-2018-10933/). Écrire de l'asynchrone en Rust te force à définir proprement l'automate du protocole, ça évite ce genre de blagues par construction (il y a sans doute plein de trous de sécurité que ça n'évite pas, hein).