C’est marrant les habitudes. J’utilise toujours git show pour ça, et je m’aperçois aujourd’hui que ce n’est pas ce qui est proposé par la doc de Git ^^

J’aime bien link-value.fr, parce qu’ils font régulièrement des articles avec des bonnes sources. Mais leur site n’est pas très performant (ça se ressent avec ma connexion assez faible), et l’utilisation de medium je trouve perso que c’est pas ouf.

Je pars du principe que mon ip change quand la box redémarre. Elle redémarre quand il y a une coupure de courant. Si elle redémarre, alors mon serveur redémarre aussi (ou alors je le redémarre manuellement). Du coup j’ai un cron qui exécute un script (https://gitlab.com/sodimel/gandynV5) quelques minutes après le démarrage de l’ordinateur.

Si à un moment je me rends compte que mon site n’est plus en ligne, alors je lance le script à la mano quand je suis à la maison depuis une connexion ssh (soit via mon tel avec l’aide de Termux, soit via mon ordi perso) :)

C’est un peu à l’arrache mais ya peu de visites sur mon site et ya relativement peu de coupures de courant à la maison.

Je confirme, dans le cas où cela partirait par exemple sur github, il faut tout détruite et tout refaire.

Une astuce toujours pratique, mais attention à bien définir les objectifs ;)

Si comme supposé par l’introduction, des secrets ont été poussés dans le dépôt git, la seule bonne solution est de les renouveler.

• Quelqu’un peut avoir déjà téléchargé les commits contenant des secrets
• Sans exécuter de git gc coté serveur, les commits seront déréférencés, mais resteront accessibles

J’ai apporté des modifications en espérant que ce soit plus clair comme ça !

T’as une référence de routeur à conseiller ? Si possible avec un modop pour remplacer la livebox
edit: Je viens de voir qu’il fallait un boitier ONT que je n’ai plus avec la livebox 5

Alors oui et non. Si tu vires la Livebox et que ton routeur à toi n’est pas coupé (enfin le temps d’un reboot ça passe), tu ne changes pas d’adresse IP. En six ans je n’ai changé qu’une fois d’ip.

Oui c’est sûrement plus léger qu’une image docker.
De tête, Orange est le seul fournisseur en France à proposer des IP dynamiques pour les particuliers

J’ai une ip fixe ^__^ plus simple.

Mais avant j’utilisais un ptit script shell qui trouvais l’ip et qui en cas de changement faisait un ptit coup de nsupdate vers le serveur. Une dizaine de ligne et juste curl et nsupdate en dépendance. Le tout dans un cron chaque minute.

Belle initiative - même si je n’ai pas la possibilité d’investissement nécessaire :p

Un p’tit retour d’expérience sur ce que vous utilisez pour gérer vos DNS avec une IP dynamique la communauté ?

Merci pour les précisions !

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.

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.

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.

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é.

Oui je m’étais fait la remarque également. :P

sinon non-officiels mais maintenus par des membres réguliers du Journal : Sur Twitter et sur Reddit

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.