Toute l’activité

Ce flux se met à jour automatiquement   

  1. Yesterday
  2. Et je rajoute -- pour ceux que cela intéresse -- le pendant pour la config SSH client (Protocol 2 uniquement, évidement) : # Pour chaque Host, des règlages spécifiques, qui peuvent écrasés ceux défini de manière générale (cf. section Host *) : Host 10.0.0.1 IdentityFile ~/.ssh/id_ecdsa_key_example.org X11Forwarding no ForwardX11Trusted yes IdentitiesOnly yes Host myvnc.example.org User root IdentityFile ~/.ssh/id_ecdsa_key_example.org X11Forwarding no ForwardX11Trusted yes IdentitiesOnly yes Host ssh.example.net User xxx-w4a IdentityFile ~/.ssh/id_ecdsa_key_ssh.example.net IdentitiesOnly yes Host www.example.net User web IdentityFile ~/.ssh/id_ecdsa_key_web.example.net IdentitiesOnly yes Host xyz.example.com User username IdentityFile ~/.ssh/id_ed25519_example.com IdentitiesOnly yes Host 192.168.* IdentityFile ~/.ssh/id_ed25519_local_lan IdentitiesOnly yes Host *.biz User username IdentityFile ~/.ssh/id_ed25519_local_business_lan ForwardAgent yes IdentitiesOnly yes Host github.com User username MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-128-etm@openssh.com,hmac-sha2-512 IdentityFile ~/.ssh/id_ed25519_github IdentitiesOnly yes # Config général pour tous les hosts et ceux non définis ci-dessus : Host * Protocol 2 # SSH v1 est à éviter absolument ! SendEnv LANG LC_* IdentitiesOnly yes HashKnownHosts yes StrictHostKeyChecking ask CheckHostIP yes RhostsAuthentication no RhostsRSAAuthentication no RSAAuthentication yes PubkeyAuthentication yes PasswordAuthentication yes X11Forwarding no ConnectTimeout 30 HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ssh-rsa,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256 KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256 MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com # Cipher ... est commenté puisse que ne concerne que SSH v1 # IdentityFile ~/.ssh/id_rsa aucune clef n'est proposée par défaut, elle doit être définie spécifiquement pour chaque serveur. Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr ServerAliveInterval 10 ControlMaster auto ControlPersist yes ControlPath ~/.ssh/socket-%r@%h:%p L'utilisation de IdentitiesOnly yes permet de limiter les clefs SSH envoyées pour l'identification aux seules clefs spécifiées pour le serveur en question. Cela évite à un serveur de récupérer le fingerprint de toutes les clefs (coucou le tracking des utilisateurs) alors qu'il existe une clef spécifiquement dédiée pour celui-ci
  3. La dernière semaine
  4. Bonjour, je fais de la spéléologie dans le forum mais je voulais causer authent à 2 facteurs. Selon Zimbra, ils l'ont implémenté : https://blog.zimbra.com/2016/02/zimbra-collaboration-8-7-two-factor-authentication-2fa-technical-preview/ Une info côté W4A ? Merci!
  5. Merci pour ton aide ! Cependant, après avoir fait l'étape 1, impossible de réaliser l'étape 2 (l'option Verrouillage du domaine n'existe pas) En réalité cela ne semble pas aussi simple. J'ai finalement réussi à trouver. Il faut envoyer un mail à une adresse spéciale avec quelques informations afin d'obtenir ce code. Rien d'automatique ni de facile donc. Je vous dirai si cela a fonctionné. Merci Google de ne pas nous aider dans ce genre de démarche !
  6. Bonjour, Tout est indiqué chez eux https://support.google.com/domains/answer/3251178?hl=fr
  7. Bonjour à tous, Je cherche à transférer un nom de domaine pris chez google qui a choisi comme registrar "enom". Cependant impossible de trouver l'option pour demander le code de transfert. Mon domaine doit être renouvelé avant le 23 mars. Quelqu'un a t-il déjà eu ce cas là ? Merci pour votre aide
  8. Nous mettons à jour la plateforme gérant vos connexions FTP & SSH Pas de coupure à prévoir Merci pour votre compréhension Voir l'intégralité de l'article
  9. Dans ce cas, vous pourriez peut-être faire remonter l'info à qui de droit ? Edit : et quid des serveurs SMTP smtp.web4all.fr (certes, ils proposent le chiffrements, mais faudrait peut-être faire un cleanup des suites supportées : https://tls.imirhil.fr/tls/smtp.web4all.fr:465
  10. Ok, je note, mais gardez l'idée sous le coude quand même...
  11. Ok, merci de l'info
  12. Bonsoir, cela n'est pas possible nous n'avons pas la main là dessus pour la partie mail sortants.
  13. Bonsoir, pour le moment ce n'est pas prévu. Beaucoup de serveurs seront refait pour la migration début avril donc on ne se lance pas dans des modifications d'ici là.
  14. Bonjour, actuellement ce n'est pas du tout d'actualité. Il faudra le prévoir mais c'est loin d'être une priorité pour le moment
  15. Bonjour, J'ai lu dans le post ci dessous qu'une réflexion semblait lancée sur le support de IPv6. C'est toujours d'actualité ? et si oui, une ETA (même très vague) pour la mise en prod ? Merci.
  16. Pour une asso, quand tu approches les 50%, c'est déjà un très très bon chiffre. Pour ma part aussi je suis dans plusieurs asso, sur des AG on dépasser péniblement les 25%. Je vous parle pas des assos sportives où là si on a 10% de présents c'est bien
  17. je crois que c'est un peu pareil dans toutes les asso...sur le sondage qu'on a fait en janvier dans la notre : 110 invitations et seulement 45 questionnaires complets :-( Vous faites mieux pour le moment !
  18. Y'a pas à dire, magnifique le côté associatif chez Web4all... Nombre total d'enregistrements 203 Nombre total sans code unique 0 Nombre total d'invitation(s) envoyée(s) 203 Nombre total de désinscriptions 1 Nombre total de sortie sur quota 0 Nombre total de questionnaire(s) terminé(s) 99
  19. Ceux qui sont présentés sur cette page fonctionne pas trop mal a ce qui parait sur les pages perso de Free, donc ca devrait pas trop poser de problème chez W4A
  20. Avant
  21. Hello, Une idée de la date de disparition de SSLv3 sur les hébergements mutualisés ? Tous les sites mutualisés en HTTPS utilise SNI, cependant SSLv3 ne le supporte pas, donc un client qui ne supporte que SSLv3 ne pourra de toute façon pas se connecter... Dans la même logique, supprimer les ciphers vulnérables (RC4, 3DES &Co) serait aussi un plus, puisse qu'ils ne sont utiles qu'avec les clients qui supportent uniquement des protocoles obsolètes. Idées pour la chaine de ciphers de mod_ssl SSLCipherSuite EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+AESGCM:EDH+AESGCM:EECDH+AES:EDH+AES:!CAMELLIA:!3DES:!aNULL:!MD5:!PSK:!SRP:!LOW:!ADH:!DSS:!RC4:!EXPORT:!eNULL:!DES SSLHonorCipherOrder on SSLProtocol all -SSLv2 -SSLv3 SSLStrictSNIVHostCheck On SSLCompression off Merci d'étudier la question.
  22. Je remonte le sujet pour demander une petite évolution de config. J'ai l'impression que smtp_tls_security_level = may n'est pas actif sur les serveurs smtp relais pour l'envoi de mail depuis les sites web. Je me trompe peut être mais c'est ce que j'ai cru lire en regardant les en-têtes des emails envoyés depuis les sites web. Dans main.cf # TLS parameters smtpd_tls_cert_file=/etc/ssl/cert.cert smtpd_tls_key_file=/etc/ssl/private.key # log TLS connection info smtpd_tls_loglevel = 1 smtp_tls_loglevel = 1 # enable opportunistic TLS support in the SMTP server and client smtpd_tls_security_level = may smtp_tls_security_level = may # if you have authentication enabled, only offer it after STARTTLS smtpd_tls_auth_only = yes tls_ssl_options = NO_COMPRESSION # TLS config smtp_tls_mandatory_protocols = !SSLv2, !SSLv3 smtp_tls_protocols = !SSLv2, !SSLv3 lmtp_tls_mandatory_protocols = !SSLv2, !SSLv3 lmtp_tls_protocols = !SSLv2, !SSLv3 smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3 smtpd_tls_protocols = !SSLv2, !SSLv3 smtpd_tls_mandatory_ciphers=high smtpd_tls_eecdh_grade=ultra,strong tls_high_cipherlist=EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+AESGCM:DHE+AESGCM:EECDH+AES:DHE+AES:AESGCM:AES:!CAMELLIA:!3DES:!aNULL:!MD5:!PSK:!SRP:!LOW:!ADH:!DSS:!RC4:!EXPORT:!eNULL:!DES:!SEED:!IDEA Dans master.cf submission inet n - n - - smtpd -o smtpd_tls_security_level=may -o tls_preempt_cipherlist=yes Je ne sais pas si lmtp est également utilisé, mais dans ce cas, il faut dupliquer les lignes de code et utiliser lmtpd_ ou lmtp_ (mais faut lire la doc si la communication passe par un socket unix).
  23. Bonjour à toute l'équipe, Je poste ici une demande d'évolution concernant la config SSH (côté serveur) de ssh.web4all.fr (et qui concerne aussi sans doute tous les serveurs w4a utilisant SSH) : Première chose le bout de code à ajouter à /etc/ssh/sshd_config : HostKey /etc/ssh/ssh_host_ed25519_key HostKey /etc/ssh/ssh_host_ecdsa_key HostKey /etc/ssh/ssh_host_rsa_key KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256 Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com UsePrivilegeSeparation sandbox AuthenticationMethods publickey,keyboard-interactive:pam UsePAM yes Seconde, le constat : https://tls.imirhil.fr/ssh/ssh.web4all.fr:22 Comme le montre très bien CryptCheck, la config SSH est un peu faiblarde (particulièrement au niveau chiffrement et MAC). Maintenant le pourquoi du bout de code : pour renforcer sensiblement la sécurité et l'intégrité des données échangées avec les clients modernes qui supportent des chiffrements forts et laisser cependant les clients obsolètes se connecter tout de même sans souci. L'utilisation de clefs serveurs ed25519 et ecdsa ne devrait pas trop surcharger les serveurs, alors que RSA reste présent pour la compatibilité. Edit : c'est également dans les recommandations de Mozilla concernant la sécurité : https://wiki.mozilla.org/Security/Guidelines/OpenSSH Merci d'étudier la demande a l'occasion.
  24. ça marche, merci pour l'info
  25. Le SSL est dispo, suffit de le demander on en met en place gratuitement pour ceux qui en ont besoin en attendant la v2 de iWal Pour les autres membres de l'équipe la seule solution sera l'auto-entrepreneuriat vu qu'ils ont tous un job à côté / études. Et si un jour on peut les embaucher, et qu'ils le souhaitent bah ce sera un autre statut et ce serait super
  26. Il y aura toujours quelques énergumènes adeptes du yakafokon (http://yakafokon.detected.fr). Bizarrement lors des AG où on attendait justement tout ces échanges, c'était le calme plat. Bien dommage que certains se réveillent uniquement maintenant... Perso je vais être franc, je ne sais pas encore si je vais suivre chez yulPa, non pas que je n'ai pas confiance en eux (au contraire même), mais je n'est actuellement pas autant de besoins en terme d'hébergement qu'avant (et ce que j'ai besoin en prio, SSL, n'est pas dispo). Mais je sais que Web4all a tenu jusque là grâce à la qualité du travail de bénévole présents dans l'équipe, et je suis persuadé que toutes les petites merdouilles qu'on pouvait avoir jusque là (soucis de com', quelques pépins serveurs/vitesse, etc.) ne seront plus que du passé, car Aurélien et Benoit (et d'autres peut être à terme ?) pourront y passer beaucoup plus de temps qu'avant. Sinon rien à voir mais une question qui n'a je pense pas été abordée. Quel va être le statut des autres membres de l'équipe qui ne seront pas salariés de yulPa ? ça marche aussi le statut de bénévole pour une entreprise ?
  27. Je comprends les récitences qu'on peut lire dans les propos de certains d'entre vous, je comprends toutes les questions posées, et en tant que membre de l'équipe je suis content de voir autant de réactions, de l'intérêt que vous avez pour Web4all. Pour ceux qui se posent des questions quant à la reprise des clients de Web4all, aux offres de yulPa, à la confidentialité des données, etc, j'espère que pour chacune de vos questions, nous avons ou nous aurons apporté une réponse claire et précise. yulPa va être une structure privée, oui mais dites vous qu'elle est créée par ceux qui depuis 10 ans, et encore aujourd'hui, bossent comme des malades pour que les serveurs tournent, pour pas qu'il y ait de bouchons, que vos mails soient délivrés et que vos sites soient publiés. La philosophie de yulPa c'est Web4all, on reprend la même équipe, la même passion, les mêmes objectifs. yulPa va offrir des services aux professionnels qui aujourd'hui n'ont pas confiance en Web4all pour la seule raison que c'est une structure associative, et c'est normal, en pleine journée y'a personne ! Et oui, c'est pas si simple de négocier avec son manager pour corriger les incidents de l'asso sur ses horaires professionnels... yulPa va permettre à Aurélien et Benoit de se consacrer à cette activité à plein temps. De sortir iWal v2, de commercialiser les offres VPS, d'être plus efficace au support, d'améliorer les performances de la plateforme HTTP, de proposer un support téléphonique. Tout ce que vous êtes en droit d'attendre de Web4all mais qu'aujourd'hui nous ne sommes pas en capacité de vous proposer pour l'unique raison qu'on manque cruellement de temps. De mon point de vue, les services vont s'étoffer et la qualité va s'améliorer pour 0€, je suis vraiment convaincu que ça va être bénéfique pour tous nos utilisateurs. Quoi qu'il en soit, merci à tous ceux qui ont réagi à cette annonce, qui nous ont fait part de leurs inquiétudes ou de leur confiance et qui nous aident à avancer. Nous ferons tout pour que les services offerts par yulPa vous satisfaisent, tout comme ceux de Web4all.
  28. Bonsoir, Vive la liberté d'expression, mais à un moment je crois qu'il faut arrêter de jouer les contestataires et chercher à créer des polémiques avec tout et n'importe quoi... Hé ben ouais, il y a des serveurs dans l'infra qui ont déjà des noms en .yulpa.io... et alors ?! Web4All vit ses derniers mois, il est normal qu'Aurélien et Benoit (et leurs acolytes bénévoles ?) commencent à bosser pour créer la structure qui je l'espère lui succédera. Ça ne va pas se faire en quelques heures, ça prendra sûrement plusieurs jours voire semaines. Alors arrêtez de les e**erder. Les justifications ils les ont déjà données, alors à quoi bon continuer à leur faire perdre leur temps, leur énergie et leur patience ?! Si yulpa n'a pas grâce à vos yeux, il y a d'autres hébergeurs qui vous ouvriront les bras... A bon entendeur. damien/dipisoft.
  1. Charger plus d’activité