Je dois avouer qu’au départ à première lecture du titre j’ai pas bien vu le rapport du SSH qui remplace sudo.
Après en lisant l’article je comprends mieux où tu veux en venir.
En même temps, je ne comprends pas trop le problème.
J’ai toujours interdit la connexion root par SSH. Je n’ai quasiment jamais utilisé ou prou sudo, sauf dans un environnement particulier. Je me connecte par SSH à une session, et si j’ai besoin d’administrer le système, je bascule en root, par l’usage de “su -”. Et puis, basta…
Et, quand je dois vraiment utiliser “sudo”, je le configure d’une seule et même manière :
Defaults targetpw
ALL ALL=(ALL) ALL
Qui appelle strictement le compte root… sans avoir la nécessité d’utiliser un utilisateur privilégié.
Le fonctionnement de su et sudo sont abordés dans la première partie. L’idée est d’éviter de recourir à des binaires setuid+root qui sont en général une importante surface d’attaque, peu importe s’ils sont configurés pour autoriser ou non certains comptes utilisateurs.
Le gros défaut de “su -” en plus de fonctionner ainsi est de distribuer de façon centralisée le compte root. Vous avez besoin du mot de passe du compte root pour vous y connecter. Avec des clés on évite ce problème.
L’article explique justement qu’interdire la connexion root par SSH est une comédie sécuritaire souvent répandue et fait plus de mal que de bien quand au final on utilise su/sudo.
Je pense aborder un récapitulatif à la fin de l’article pour que ce soit plus clair car peut-être que les informations sont trop dispersées.
Désolé mais je ne suis pas convaincu :/ Je ne vois pas ce que cela apporte de se connecter au compte root via ssh plutôt que sudo si ce n’est de la lourdeur.
Un des intérêt d’utiliser sudo est de ne pas communiquer le mot de passe root et d’éviter que celui-ci soit perdu ou qu’il doive être modifier en plus de permettre de faire un suivi des opérations utilisées via sudo. Je ne me connecte jamais en root sauf lorsque sudo ne fonctionne pas et uniquement pour l’opération concernée.
Il est indiqué dans le titre, partie 2, mais je trouve pas la partie 1.
La première partie est le premier article qui est en lien dans l’article. Elle expliquera justement en quoi sudo est davantage une lourdeur plutôt que simplement utiliser SSH.
Il me semble avoir abordé tous ces points, notamment :
sudo demande un mot de passe en clair, que ce soit celui de l’utilisateur ou de root peu importe
Les évènements peuvent être journalisés avec des outils plus robustes comme auditd
Sur la majorité des distributions le binaire n’est pas restreint à un groupe donc il peut être exploité facilement par un service compromis
Le but de l’article est surtout de faire comprendre que la connexion à root via SSH n’a rien de problématique d’autant plus quand la pratique d’utiliser des binaires setuid+root avec un historique d’exploitation est déjà répandue. Mais aussi qu’il y a, de toute façon, des problèmes bien plus sérieux suivant le modèle de sécurité abordé.
Cependant je pense modifier l’article pour préciser que l’article du début est la première partie, et aussi ajouter une meilleure comparaison entre su/sudo/SSH pour l’utilisation de root.
Je dois avouer qu’au départ à première lecture du titre j’ai pas bien vu le rapport du SSH qui remplace sudo. Après en lisant l’article je comprends mieux où tu veux en venir.
Oui je m’étais fait la remarque également. :P
En même temps, je ne comprends pas trop le problème.
J’ai toujours interdit la connexion root par SSH. Je n’ai quasiment jamais utilisé ou prou sudo, sauf dans un environnement particulier. Je me connecte par SSH à une session, et si j’ai besoin d’administrer le système, je bascule en root, par l’usage de “su -”. Et puis, basta…
Et, quand je dois vraiment utiliser “sudo”, je le configure d’une seule et même manière :
Qui appelle strictement le compte root… sans avoir la nécessité d’utiliser un utilisateur privilégié.
Le fonctionnement de su et sudo sont abordés dans la première partie. L’idée est d’éviter de recourir à des binaires setuid+root qui sont en général une importante surface d’attaque, peu importe s’ils sont configurés pour autoriser ou non certains comptes utilisateurs.
Le gros défaut de “su -” en plus de fonctionner ainsi est de distribuer de façon centralisée le compte root. Vous avez besoin du mot de passe du compte root pour vous y connecter. Avec des clés on évite ce problème.
L’article explique justement qu’interdire la connexion root par SSH est une comédie sécuritaire souvent répandue et fait plus de mal que de bien quand au final on utilise su/sudo.
Je pense aborder un récapitulatif à la fin de l’article pour que ce soit plus clair car peut-être que les informations sont trop dispersées.
Désolé mais je ne suis pas convaincu :/ Je ne vois pas ce que cela apporte de se connecter au compte root via ssh plutôt que sudo si ce n’est de la lourdeur.
Un des intérêt d’utiliser sudo est de ne pas communiquer le mot de passe root et d’éviter que celui-ci soit perdu ou qu’il doive être modifier en plus de permettre de faire un suivi des opérations utilisées via sudo. Je ne me connecte jamais en root sauf lorsque sudo ne fonctionne pas et uniquement pour l’opération concernée.
Il est indiqué dans le titre, partie 2, mais je trouve pas la partie 1.
La première partie est le premier article qui est en lien dans l’article. Elle expliquera justement en quoi sudo est davantage une lourdeur plutôt que simplement utiliser SSH.
Il me semble avoir abordé tous ces points, notamment :
Le but de l’article est surtout de faire comprendre que la connexion à root via SSH n’a rien de problématique d’autant plus quand la pratique d’utiliser des binaires setuid+root avec un historique d’exploitation est déjà répandue. Mais aussi qu’il y a, de toute façon, des problèmes bien plus sérieux suivant le modèle de sécurité abordé.
Cependant je pense modifier l’article pour préciser que l’article du début est la première partie, et aussi ajouter une meilleure comparaison entre su/sudo/SSH pour l’utilisation de root.
Merci pour les précisions !
J’ai apporté des modifications en espérant que ce soit plus clair comme ça !