Actions











Blogs No. 19 - 23

Crème d'administrateur

Écrit le 15/04/2019 @ 17:29 par Drizzt

Entertainement - Humour Nous l'avons enfin trouvé! La crème d'administrateur! Lorsque tes serveurs te donne de l'urticaire, il ne suffit qu'à appliquer cette crème et l'urticaire disparaît, ainsi que les problèmes de serveur!
Image

P.S.: J'ai réglé le téléversement de fichiers Smile

Clé SSH refusée... et si c'était dans les droits du fichier

Écrit le 01/04/2019 @ 13:43 par Alexandre

Informatique - Sécurité Un drôle de titre pour certains, mais peut-être que d'autres se reconnaîtront. Si vous utilisez des clés publiques/privées pour vous authentifier sur des services en ligne comme Github, AUR (Archlinux), etc. et que vous vous confrontez à un serveur qui refuse obstinément votre clé [Permission denied (publickey)], ceci peut avoir plusieurs causes.

L'une d'elles correspond peut-être à ce scénario : vous travaillez sur plus d'un ordinateur et vous avez copié votre clé de l'ordinateur sur lequel elle a été générée vers un second ordinateur. Votre clé fonctionne toujours sur l'ordinateur d'origine, mais elle est refusée sur le second ordinateur. Le problème n'est donc pas avec la clé puisqu'elle est identique aux deux endroits. En fait, il faut savoir que seulement vous, comme utilisateur, devriez avoir accès au fichier de votre clé privée. Ah! Donc, si vous regardez les droits de lecture, d'écriture et d'exécution, vous seul devez avoir des droits (rw), personne d'autre.

Lancez donc un chmod 600 $dossierverscléprivée/$nomcléprivée, exemple

chmod 600 ~/johndoe/.ssh/id_rsa


Tentez de vous identifier à nouveau.

Voilà quelques semaines que je rencontrais cette erreur sur un second ordinateur et je n'avais pas pris le temps de chercher. J'ai maintenant réglé mon problème et appris que les clés privées doivent être privées jusqu'au bout. Wink

MenzoNet maintenant en HTTPS!

Écrit le 28/03/2019 @ 21:32 par Drizzt

Site - Entretien/Tweak Un petit message pour vous dire que j'ai passé le site web en HTTPS partout.

La raison est simple, les navigateurs commencent à avertir lorsque les sites ne sont pas en HTTPS. Comme j'ai déjà mon certificat et que la configuration est fonctionnelle, j'ai décidé de migrer tout le site sur cette configuration!

J'ai eu quelques modifications à faire au code du site pour m'assurer que tout était beau. Comme toujours, si vous trouvez des problèmes, faites-le savoir!

Correction d'une faille de sécurité

Écrit le 25/11/2018 @ 16:42 par Drizzt

Informatique - Sécurité Après toutes ces années, c'est la première fois que quelque chose comme ça m'arrive!

Quelqu'un a remplis un rapport sur OpenBugBounty.org pour me signaler qu'il y avait un faille XSS sur mon site web. J'ai contacté la personne qui a fait ce rapport, pour me rendre compte que la faille était effectivement présente.

J'ai sorti mes skills (plutôt absents) de RedExp pour corriger le bug et conserver seulement que les valeurs qui nous sont utiles. Je crois bien l'avoir corrigé correctement.

La sécurité n'est pas une destination, mais un processus...

Les temps sont durs pour les rêveurs!

Écrit le 02/08/2018 @ 16:48 par Drizzt

Informatique Et je continue sur mon projet...

J'ai de belles étapes de franchies. Les 2 serveurs sont en LACP sur le commutateur Cisco, un serveur NUT est configuré pour avertir les serveurs d'éteindre en cas de panne électrique, les données sont migrées.

C'est ici que le fun commence.. ou encore que tout se complique!

Ce qu'il me reste à faire :

  • Remplacer Calendar & Contacts Server d'Apple
  • Migrer le courrier électronique sur une autre solution
  • Remplacer mon serveur DLNA par quelque chose de moins... problématique?



Pour le reste de l'article, cliquez sur Détails



Voir les 5 blogs précédents
Voir les 5 prochains blogs