Re: Authentification ssh et PAM

[RogerT]

> Le 21 juil. 2023 à 10:26, Michel Verdier  a écrit :
> 
> Le 19 juillet 2023 RogerT a écrit :
> 
>> La validation par le gouvernement n’est en rien une garantie (sgdg…). 
> 
> Bien sûr, mais c'est quand même un plus par rapport à rien du tout.

Ça ne vaut rien du tout. Rien.

> 
>> Pour Keepass, tu stockes ta BD où tu veux. Le problème était la possibilité 
>> d’exporter en clair les pwds :
>> https://www.it-connect.fr/faille-critique-dans-keepass-un-attaquant-peut-exporter-les-mots-de-passe-en-clair/
> 
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-24055
> Celui-là concerne le client KeePass, d'autres clients comme KeePassXC ne
> sont pas touchés. Et ça concerne le paramétrage du client pas la
> base elle-même.
> 
>> Encore une nouvelle faille en 2023 : CVE-2023-35866
>> 19/07/2023
>> https://www.it-connect.fr/une-faille-de-securite-keepassxc-permet-de-changer-le-mot-de-passe-maitre-lediteur-conteste/
> 
> https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=CVE-2023-35866
> Ca concerne KeePassXC mais il faut laisser la base ouverte en libre
> d'accès. A partir de là forcément n'importe quoi peut être fait sur la
> base et sans doute aussi sur le poste. Ce CVE est disputé.

C’est suffisamment grave et répété (pour d’autres gestionnaires de pwd) pour 
reconsidérer l’utilisation de ces passoires. 

« Disputed » : l’éditeur n’est pas d’accord. Ça ne veut rien dire d’autre 
(comme d’être partie à un procès dont on ignore l’issue). 
Avec des arguments pour keepass[xc] comme:
 « Oui, mais si un attaquant prend le contrôle de la machine alors il n’y a 
rien à faire » !!
 et « On ne peut pas faire de la sécurité en milieu non sûr » !!!
Ils sont fous ces gars !

Re: Authentification ssh et PAM

[Michel Verdier]

Le 19 juillet 2023 RogerT a écrit :

> La validation par le gouvernement n’est en rien une garantie (sgdg…). 

Bien sûr, mais c'est quand même un plus par rapport à rien du tout.

> Pour Keepass, tu stockes ta BD où tu veux. Le problème était la possibilité 
> d’exporter en clair les pwds :
> https://www.it-connect.fr/faille-critique-dans-keepass-un-attaquant-peut-exporter-les-mots-de-passe-en-clair/

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-24055
Celui-là concerne le client KeePass, d'autres clients comme KeePassXC ne
sont pas touchés. Et ça concerne le paramétrage du client pas la
base elle-même.

> Encore une nouvelle faille en 2023 : CVE-2023-35866
> 19/07/2023
> https://www.it-connect.fr/une-faille-de-securite-keepassxc-permet-de-changer-le-mot-de-passe-maitre-lediteur-conteste/

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=CVE-2023-35866
Ca concerne KeePassXC mais il faut laisser la base ouverte en libre
d'accès. A partir de là forcément n'importe quoi peut être fait sur la
base et sans doute aussi sur le poste. Ce CVE est disputé.

Re: Authentification ssh et PAM

[Vincent Lefevre]

On 2023-07-19 09:05:05 +0200, Michel Verdier wrote:
> Le 18 juillet 2023 roger tarani a écrit :
> > Quel est le mécanisme détaillé conduisant à l'authentification de 
> > l'utilisateur par l'hôte distant ? 
> > (la clef privée reste sur l'hôte local ; comment la clef publique et la 
> > clef privée sont-elles liées ? par la création d'un jeton ? ou autre ? ) 
> 
> La clef publique est indiquée au serveur lors de la demande de connexion.
> Le serveur s'en sert ensuite pour décrypter une phrase cryptée par le
> client avec sa clef privée.

Le chiffrage se fait avec la clé *publique* du destinataire. Mais
c'est HS ici, car il ne s'agit pas de chiffrer, mais d'authentifier,
qui est l'équivalent de vérifier une signature. Et la signature se
fait avec sa propre clé privée (et se vérifie avec la clé publique
associée).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Authentification ssh et PAM

[Jean Bernon]

Non je ne crois pas que ce soit des bijections inverses, sauf à s'entendre sur 
ce qu'on met derrière cette expression.

J'ai pioché la question du chiffrement il y a quelques années. Voici la petite 
synthèses que nous avions faite des principes de base. Elle ne répond pas à 
toutes questions de Roger. Mais elle peut aider à cadrer le débat.

Deux usages d'une paire de clés PGP dans l'échange de fichiers.

Premier usage : la paire de clés PGP permet de chiffrer / déchiffrer certains 
documents ou mails. Plus précisément, la clé publique sert au chiffrement et la 
clé privée au déchiffrement.

Deuxième usage : cette même paire de clés PGP peut aussi servir à signer 
électroniquement un mail (et à vérifier l’authenticité de la signature). Dans 
ce cas, la clé privée sert à signer et la clé publique à vérifier la signature.

Usages de GnuPG dans l'envoi d'un mail
Pourquoi ?  Qui ?   Comment ?
Chiffrement Expéditeur  Clé publique du destinataire
Déchiffrement   DestinataireClé privée du destinataire
Signature   Expéditeur  Clé privée de l'expéditeur
Vérification de la signatureDestinataireClé publique de l'expéditeur


- Mail original - 

> De: "elguero eric" 
> À: debian-user-french@lists.debian.org
> Envoyé: Mercredi 19 Juillet 2023 18:28:24
> Objet: Re: Authentification ssh et PAM

> pour moi crypter et décrypter ne sont que des mots
> et en réalité il s'agit de deux bijections inverses
> l'une de l'autre. donc on peut aussi bien dire qu'on commence
> par décrypter un message avant de l'envoyer et
> que le récipiendaire devra alors le crypter pour retrouver
> le message original. Ou l'inverse.

> e.e.

> Le mercredi 19 juillet 2023 à 18:08:00 UTC+2, Michel Verdier
>  a écrit :

> Le 19 juillet 2023 RogerT a écrit :

> > Après vérification, et sauf erreur ou omission de ma part, je
> > regrette
> > mais en cryptographie asymétrique, seule la clef privée permet de
> > DÉchiffrer.
> > Tandis que la clef publique permet à tout le monde de chiffrer un
> > message.

> Oui tu as raison, autant pour moi, ça fait du bien de relire les
> bases de
> temps en temps. Voilà une description assez claire :
> https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process

Re: Authentification ssh et PAM

[didier gaumet]

Le 20/07/2023 à 10:48, RogerT a écrit :
[...]

En pratique, si j’utilise une clef USB sans chiffrement ou avec chiffrement ou 
carrément un HSM, PAM est-il transparent à utiliser (cad qu’il suffit de 
configurer account, auth, password, session) ou faut-il trouver/développer un 
composant logiciel pour interagir avec chaque type ou modèle de HSM ?

[...]

Rappel: je suis nul en sécurité donc je réponds sur ce point uniquement 
(à l'exclusion de tes autres interrogations) et ma réponse est à prendre 
avec des pincettes


- pour une clé USB (au sens large ça semble considéré comme un HSM 
aussi?) apparemment il y a le module PAM USB et la commande pamusb-conf, 
une page du wiki Debian évoque ça:

https://wiki.debian.org/pamusb

- pour les HSM plus évolués de type smartcard, de mémoire, un lien 
Redhat précédent semblait indiquer un standard PKCS#11 avec parfois des 
périphériques devant rajouter un pilote propriétaire. Le wiki Debian a 
une page sur les smartcards où il évoque deux standards, openPGP ou PKSC#11:

https://wiki.debian.org/fr/Smartcards?highlight=%28pkcs%2311%29

Re: Authentification ssh et PAM

[RogerT]

> Le 20 juil. 2023 à 10:16, didier gaumet  a écrit :
> 
> Le 20/07/2023 à 09:25, Michel Verdier a écrit :
>> Le 19 juillet 2023 didier gaumet a écrit :
>>> Pour autant que ça s'applique ici, Wikipedia a une explication d'un 
>>> mécanisme
>>> d'autentification à clés asymétriques par l'utilisation d'un double
>>> chiffrement avec les deux clés publiques (celles de chaque partie):
>>> https://fr.wikipedia.org/wiki/Cryptographie_asym%C3%A9trique#M%C3%A9canismes_d'authentification
>> En français c'est mieux :)
>> On retrouve Alice et Bob. Et effectivement le dernier truc sur lequel je
>> travaillais c'est de l'authentification qui crypte avec la clef privée,
>> d'où mon inversion pour ssh.
> 
> Ah, c'est pas à moi que ça arriverait, ça: je ne me trompe jamais, qu'on se 
> le dise ;-)
> 
> D'ailleurs c'est à se demander quel phénomène occulte et maléfique est 
> intervenu pour corrompre et distordre mon message précédent, puisque à le 
> lire soigneusement ainsi que le lien qu'il cite, on s'aperçoit que je me suis 
> encore planté (c'est pas un double chiffrement par les deux clés publiques, 
> c'est un double chiffrement par la clé privée de l'émetteur puis la clé 
> publique du destinataire ;-)
> 
> Encore une preuve qu'il ne faut pas faire aveuglément confiance à un 
> contributeur mais valider l'exactitude et la pertinence de ses propos :-)
> 
Bonjour,
Il faut toujours vérifier. 
Ça me semblait bizarre de chiffrer avec les deux clefs publiques. 

En vérifiant, j’ai redécouvert le mécanisme que je connaissais de chiffrement 
d’un fichier par l’expérience avec la clef publique du destinataire. 
C’est un mécanisme pour assurer la confidentialité. 

En revérifiant, j’ai découvert le mécanisme de chiffrement d’un (hash de) 
fichier avec la clef privée de l’expéditeur, qui permet au destinataire de 
vérifier que l’expéditeur est bien celui qui le revendique. 
C’est un mécanisme d’authentification (par signature). 

Et si on combine les deux (chiffrement par l’expéditeur avec sa clef privée 
d’un hash du fichier et avec la clef publique du fichier, alors on obtient une 
communication confidentielle et authentifiée. 

On peut donc supposer que le client ssh envoie simplement au serveur un message 
signé avec sa clef privée. Et le serveur ssh qui a une copie de la clef 
publique peut vérifier que celui qui demande la connexion est celui qu’il dit 
être (authentification). 

Échanger ici a permis de mettre les idées au clair. 
Merci. 

PS : une fois cette authentification configurée, il faut penser impérativement 
à désactiver l’authentification par pwd ou bien avoir un fail2ban installé pour 
éviter des intrusions qu’on croirait devenues impossibles sans avoir la clef 
privée si longue (RSA 2048 ou 4096).


J’ai commencé à étudier PAM et ses fichiers de configuration. 

En pratique, si j’utilise une clef USB sans chiffrement ou avec chiffrement ou 
carrément un HSM, PAM est-il transparent à utiliser (cad qu’il suffit de 
configurer account, auth, password, session) ou faut-il trouver/développer un 
composant logiciel pour interagir avec chaque type ou modèle de HSM ?

Quelle est votre expérience pratique avec un HSM/une clef USB et PAM ?


PS : La question viendra ensuite de savoir quelle confiance on peut accorder à 
PAM en tant que « bus/slot/interface). Cad quelle garantie apporte-t-il de 
n’être pas un trou de sécurité ? 

Re: Authentification ssh et PAM

[Daniel Caillibaud]

Le 19/07/23 à 16:28, elguero eric  a écrit :
> pour moi crypter et décrypter ne sont que des mots

Mais les mots ont un sens ;-)

Et ici ce n'est pas le bon. En français, décrypter c'est déchiffrer un message 
dont on a pas la
clé de chiffrement (et crypter n'existe pas car ça n'a pas de sens, ça voudrait 
dire chiffrer
sans avoir la clé de chiffrement).

C'est pour ça qu'on parle de chiffrer / déchiffrer quand on code/décode un 
message en ayant la
clé.

En anglais, il n'y a pas de mot différent lorsqu'on a la clé ou pas, c'est 
toujours
encrypt/decrypt, d'où l'usage erroné très courant de crypter(sic)/décrypter en 
français.

-- 
Daniel

On tue un homme, on est un assassin.
On tue des millions d'hommes, on est un conquérant.
On les tue tous, on est un dieu.
Edmond Rostand

Re: Fwd: Authentification ssh et PAM

[didier gaumet]

Le 20/07/2023 à 09:25, Michel Verdier a écrit :

Le 19 juillet 2023 didier gaumet a écrit :


Pour autant que ça s'applique ici, Wikipedia a une explication d'un mécanisme
d'autentification à clés asymétriques par l'utilisation d'un double
chiffrement avec les deux clés publiques (celles de chaque partie):
https://fr.wikipedia.org/wiki/Cryptographie_asym%C3%A9trique#M%C3%A9canismes_d'authentification


En français c'est mieux :)
On retrouve Alice et Bob. Et effectivement le dernier truc sur lequel je
travaillais c'est de l'authentification qui crypte avec la clef privée,
d'où mon inversion pour ssh.


Ah, c'est pas à moi que ça arriverait, ça: je ne me trompe jamais, qu'on 
se le dise ;-)


D'ailleurs c'est à se demander quel phénomène occulte et maléfique est 
intervenu pour corrompre et distordre mon message précédent, puisque à 
le lire soigneusement ainsi que le lien qu'il cite, on s'aperçoit que je 
me suis encore planté (c'est pas un double chiffrement par les deux clés 
publiques, c'est un double chiffrement par la clé privée de l'émetteur 
puis la clé publique du destinataire ;-)


Encore une preuve qu'il ne faut pas faire aveuglément confiance à un 
contributeur mais valider l'exactitude et la pertinence de ses propos :-)

Re: Fwd: Authentification ssh et PAM

[Michel Verdier]

Le 19 juillet 2023 didier gaumet a écrit :

> Pour autant que ça s'applique ici, Wikipedia a une explication d'un mécanisme
> d'autentification à clés asymétriques par l'utilisation d'un double
> chiffrement avec les deux clés publiques (celles de chaque partie):
> https://fr.wikipedia.org/wiki/Cryptographie_asym%C3%A9trique#M%C3%A9canismes_d'authentification

En français c'est mieux :)
On retrouve Alice et Bob. Et effectivement le dernier truc sur lequel je
travaillais c'est de l'authentification qui crypte avec la clef privée,
d'où mon inversion pour ssh.

Re: Authentification ssh et PAM

[elguero eric]

pour moi crypter et décrypter ne sont que des mots
et en réalité il s'agit de deux bijections inverses
l'une de l'autre. donc on peut aussi bien dire qu'on commence
par décrypter un message avant de l'envoyer et
que le récipiendaire devra alors le crypter pour retrouver
le message original. Ou l'inverse.

e.e.



Le mercredi 19 juillet 2023 à 18:08:00 UTC+2, Michel Verdier  a 
écrit : 

Le 19 juillet 2023 RogerT a écrit :

> Après vérification, et sauf erreur ou omission de ma part, je regrette
> mais en cryptographie asymétrique, seule la clef privée permet de
> DÉchiffrer.
> Tandis que la clef publique permet à tout le monde de chiffrer un message. 


Oui tu as raison, autant pour moi, ça fait du bien de relire les bases de
temps en temps. Voilà une description assez claire :
https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process

Re: Authentification ssh et PAM

[RogerT]

> Le 19 juil. 2023 à 17:58, Michel Verdier  a écrit :
> 
> Le 19 juillet 2023 RogerT a écrit :
> 
 Ou alors il faut un gestionnaire de pwd pour stocker la phrase de passe…
>>> 
>>> Tout à fait, c'est à ça que sert kwallet ou gnome-agent ou keepassxc
>> Keepass[xc], etc.ne sont pas sûrs comme la plupart des gestionnaires de pwd 
>> qui ont tous déjà été attaqués. Y compris dashlane. Voir divers articles. 
> 
> keepass est validé par le gouvernement
> https://www.ssi.gouv.fr/entreprise/certification_cspn/keepass-version-2-10-portable/
> D'autres gestionnaires attaqués dont j'ai entendu parlé (1password, etc) 
> avaient du
> stockage en ligne, ce n'est pas le cas de keepass. As-tu les références 
> d'articles ?


La validation par le gouvernement n’est en rien une garantie (sgdg…). 
Pour Keepass, tu stockes ta BD où tu veux. Le problème était la possibilité 
d’exporter en clair les pwds :
https://www.it-connect.fr/faille-critique-dans-keepass-un-attaquant-peut-exporter-les-mots-de-passe-en-clair/

L’éditeur n’a pas craint d’affirmer :
« l'éditeur de KeePass estime que la base de données de mots de passe n'est pas 
censée être protégée contre un attaquant disposant déjà d'un accès local sur un 
PC. »

L’éditeur aurait aussi affirmé « on ne peut pas faire de la sécurité dans un 
environnement non sûr » !!! (j’ai lu ça ; je recherche la source). 

Encore une nouvelle faille en 2023 : CVE-2023-35866
19/07/2023
https://www.it-connect.fr/une-faille-de-securite-keepassxc-permet-de-changer-le-mot-de-passe-maitre-lediteur-conteste/
L’éditeur écrit :
 "Pour l'instant, nous ne prévoyons pas de modifier radicalement le programme 
pour répondre à cette demande." - Et aussi : "La solution la plus simple pour 
contrer ce vecteur de menace est de verrouiller votre base de données avant de 
quitter votre poste de travail."


Rappel : ne quittez pas votre poste en laissant la BD déverrouillée :
https://security.stackexchange.com/questions/115086/is-it-safe-to-leave-keepass-always-opened-on-a-computer
 

On attend la révélation des autres failles ou faiblesses…

Re: Authentification ssh et PAM

[Michel Verdier]

Le 19 juillet 2023 RogerT a écrit :

> Après vérification, et sauf erreur ou omission de ma part, je regrette
> mais en cryptographie asymétrique, seule la clef privée permet de
> DÉchiffrer.
> Tandis que la clef publique permet à tout le monde de chiffrer un message. 

Oui tu as raison, autant pour moi, ça fait du bien de relire les bases de
temps en temps. Voilà une description assez claire :
https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process

Re: Authentification ssh et PAM

[Michel Verdier]

Le 19 juillet 2023 RogerT a écrit :

>>> Ou alors il faut un gestionnaire de pwd pour stocker la phrase de passe…
>> 
>> Tout à fait, c'est à ça que sert kwallet ou gnome-agent ou keepassxc
> Keepass[xc], etc.ne sont pas sûrs comme la plupart des gestionnaires de pwd 
> qui ont tous déjà été attaqués. Y compris dashlane. Voir divers articles. 

keepass est validé par le gouvernement
https://www.ssi.gouv.fr/entreprise/certification_cspn/keepass-version-2-10-portable/
D'autres gestionnaires attaqués dont j'ai entendu parlé (1password, etc) 
avaient du
stockage en ligne, ce n'est pas le cas de keepass. As-tu les références 
d'articles ?

Re: Fwd: Authentification ssh et PAM

[didier gaumet]

Pour autant que ça s'applique ici, Wikipedia a une explication d'un 
mécanisme d'autentification à clés asymétriques par l'utilisation d'un 
double chiffrement avec les deux clés publiques (celles de chaque partie):

https://fr.wikipedia.org/wiki/Cryptographie_asym%C3%A9trique#M%C3%A9canismes_d'authentification

Fwd: Authentification ssh et PAM

[RogerT]

COMPLÉMENT

J’ai approfondi ma vérification. 

J’étais parti sur le seul schéma habituel : chiffrer avec la clef publique et 
déchiffrer avec la clef privée. 

Je crois que tu voulais parler de signature numérique, où Alice (ici le client 
ssh) chiffre avec sa clef privée probablement un message fourni par Bob (ici le 
serveur ssh). Bob « déchiffre le message d’Alice » avec la clef publique. Il 
est alors certain que ça vient d’Alice et lui ouvre la porte.
C’est ça ?

Il m’échappe encore un truc que je vais explorer : je ne comprends pas comment 
Bob peut déchiffrer avec la clef publique d’Alice un message d’Alice.
J’imagine qu’il s’agit en fait seulement de « vérifier que la signature 
provient d’Alice ». 
Je fouille dans ce sens.  
Peux-tu expliquer le procédé ?

Source :
« If Alice encrypts a message using her private key and sends the encrypted 
message to Bob, then Bob can be sure that the data he receives comes from 
Alice; if Bob can decrypt the data with Alice's public key, the message must 
have been encrypted by Alice with her private key, and only Alice has Alice's 
private key. The problem is that anybody else can read the message as well 
because Alice's public key is public. Although this scenario does not allow for 
secure data communication, it does provide the basis for digital signatures. »

https://www.ibm.com/docs/en/sdk-java-technology/8?topic=processes-public-key-cryptography


Début du message transféré :

> De: RogerT 
> Date: 19 juillet 2023 à 16:59:28 UTC+2
> À: debian-user-french@lists.debian.org
> Objet: Rép. : Authentification ssh et PAM
> 
> 
> 
>>> Le 19 juil. 2023 à 16:32, Michel Verdier  a écrit :
>>> Le 19 juillet 2023 RogerT a écrit :
>>> 
>>> Pour chiffrer une phrase il suffit de la clef publique. 
>>> Pour déchiffrer une phrase il faut la clef privée.
>> 
>> Non c'est l'inverse. C'est pour ça que seul toi a la privée et que tu
>> diffuses la publique à tous ceux qui doivent déchiffrer
> 
> Après vérification, et sauf erreur ou omission de ma part, je regrette mais 
> en cryptographie asymétrique, seule la clef privée permet de DÉchiffrer. 
> Tandis que la clef publique permet à tout le monde de chiffrer un message. 
> 
> En cas d’erreur de ma part, je te/vous remercie de m’expliquer en quoi je me 
> tromperais alors que c’est le premier cas de figure ultra connu entre Alice 
> et Bob pour échanger un secret (chiffré avec la clef publique et déchiffré 
> avec la seule clef privée). 
> 
>> 
>>> Le serveur a seulement la clef publique.  
>> 
>> Oui, tous les serveurs qui doivent te déchiffrer (= tous ceux sur
>> lesquels tu dois te connecter) ont la publique
> Le serveur distant a la clef publique que j’y ai copié. Mais pas pour 
> déchiffrer. Voir plus haut. Sauf erreur ou omission. 
> 
> 
>>> Le client a les deux clefs. 
>>> Seul le client peut déchiffrer une phrase chiffrée.
>> 
>> Non, seul le client peut chiffrer
> 
> Tous ceux qui ont la clef publique peuvent chiffrer. 
> Et aussi celui qui a seulement la clef privée car elle permet de générer une 
> clef publique (je suppose qu’on peut chiffrer aussi avec la clef privée)
> 
>> 
>>> Comment fait le serveur ssh pour savoir que c’est bien le détenteur de
>>> la clef privée qui frappe à la porte ?
>> 
>> Parce qu'il décode, avec la clef publique, une phrase chiffrée par le
>> client avec sa clef privée
> Toujours pas d’accord. 
> Peut-être as-tu un détail de la séquence entre client et serveur ?
> 
> 
>>>> L'idée c'est quand même d'y mettre un mot de passe pour avoir les 2
>>>> facteurs d'authentification.
>>> Ça enlève l’intérêt d’une authentification rapide.
>>> Ou alors il faut un gestionnaire de pwd pour stocker la phrase de passe…
>> 
>> Tout à fait, c'est à ça que sert kwallet ou gnome-agent ou keepassxc
> Keepass[xc], etc.ne sont pas sûrs comme la plupart des gestionnaires de pwd 
> qui ont tous déjà été attaqués. Y compris dashlane. Voir divers articles. 
> 
>> 
>>>> sur le client il faut utiliser le paramètre -i pour utiliser le clef adhoc
>>>> ou l'indiquer dans ~/.ssh/config du client. Donc il faut monter ta clef
>>>> pour qu'elle soit accessible par le client.
>>> Entendu.
>>> Modulo le nom du dev /dev/sdb …
>>> Sauf à utiliser un UUID pour le device (ça se fait, je crois).
>> 
>> oui tu mets ce qui va bien avec uuid ou partuid ou label dans /etc/fstab, 
>> avec
>> l'option user, et le client fait un mount du nom du répertoire que tu
>> précise. Par exemple chez moi :
>> 
>> #/dev/sdc1: LABEL_FATBOOT="CLEF" LABEL="CLEF" UUID="CC7E-404F" 
>> BLOCK

Re: Authentification ssh et PAM

[RogerT]

> Le 19 juil. 2023 à 16:32, Michel Verdier  a écrit :
> Le 19 juillet 2023 RogerT a écrit :
> 
>> Pour chiffrer une phrase il suffit de la clef publique. 
>> Pour déchiffrer une phrase il faut la clef privée.
> 
> Non c'est l'inverse. C'est pour ça que seul toi a la privée et que tu
> diffuses la publique à tous ceux qui doivent déchiffrer

Après vérification, et sauf erreur ou omission de ma part, je regrette mais en 
cryptographie asymétrique, seule la clef privée permet de DÉchiffrer. 
Tandis que la clef publique permet à tout le monde de chiffrer un message. 

En cas d’erreur de ma part, je te/vous remercie de m’expliquer en quoi je me 
tromperais alors que c’est le premier cas de figure ultra connu entre Alice et 
Bob pour échanger un secret (chiffré avec la clef publique et déchiffré avec la 
seule clef privée). 

> 
>> Le serveur a seulement la clef publique.  
> 
> Oui, tous les serveurs qui doivent te déchiffrer (= tous ceux sur
> lesquels tu dois te connecter) ont la publique
Le serveur distant a la clef publique que j’y ai copié. Mais pas pour 
déchiffrer. Voir plus haut. Sauf erreur ou omission. 


>> Le client a les deux clefs. 
>> Seul le client peut déchiffrer une phrase chiffrée.
> 
> Non, seul le client peut chiffrer

Tous ceux qui ont la clef publique peuvent chiffrer. 
Et aussi celui qui a seulement la clef privée car elle permet de générer une 
clef publique (je suppose qu’on peut chiffrer aussi avec la clef privée)

> 
>> Comment fait le serveur ssh pour savoir que c’est bien le détenteur de
>> la clef privée qui frappe à la porte ?
> 
> Parce qu'il décode, avec la clef publique, une phrase chiffrée par le
> client avec sa clef privée
Toujours pas d’accord. 
Peut-être as-tu un détail de la séquence entre client et serveur ?


>>> L'idée c'est quand même d'y mettre un mot de passe pour avoir les 2
>>> facteurs d'authentification.
>> Ça enlève l’intérêt d’une authentification rapide.
>> Ou alors il faut un gestionnaire de pwd pour stocker la phrase de passe…
> 
> Tout à fait, c'est à ça que sert kwallet ou gnome-agent ou keepassxc
Keepass[xc], etc.ne sont pas sûrs comme la plupart des gestionnaires de pwd qui 
ont tous déjà été attaqués. Y compris dashlane. Voir divers articles. 

> 
>>> sur le client il faut utiliser le paramètre -i pour utiliser le clef adhoc
>>> ou l'indiquer dans ~/.ssh/config du client. Donc il faut monter ta clef
>>> pour qu'elle soit accessible par le client.
>> Entendu.
>> Modulo le nom du dev /dev/sdb …
>> Sauf à utiliser un UUID pour le device (ça se fait, je crois).
> 
> oui tu mets ce qui va bien avec uuid ou partuid ou label dans /etc/fstab, avec
> l'option user, et le client fait un mount du nom du répertoire que tu
> précise. Par exemple chez moi :
> 
> #/dev/sdc1: LABEL_FATBOOT="CLEF" LABEL="CLEF" UUID="CC7E-404F" 
> BLOCK_SIZE="512" TYPE="vfat" PARTUUID="f42f95e2-01"
> LABEL="CLEF"/media/usb   vfat user,noexec,noauto,noatime,lazytime 
> 0   2
> 
> PARTUUID="42711922-2694-43bd-bf1f-9d6a7fccebec" /media/backup exfat 
> user,noexec,noauto,noatime,lazytime 0   0
> 
> /dev/mmcblk0p1 /media/sd  xfs 
> user,noexec,noauto,rw,noatime,inode64,logbufs=8,logbsize=32k,noquota,lazytime 
> 0 0
Ok. Merci. 


>> Je me dis que pour que le HSM se substitue à moi dans la gestion des clefs, 
>> et
>> aller au-delà d’indiquer le chemin de la clef (avec ssh -i) il faut sans 
>> doute
>> utiliser PAM (d’ailleurs, qui sert aussi à interfacer une authentification
>> LDAP).
> 
> A la base les PAM c'est plutôt pour le local, d'ailleurs sshd appelle les
> PAM pour établir la session. Là ce que tu travailles c'est la
> sécurisation d'une connexion ssh sur le client, donc à priori aucun
> rapport avec les PAM.
> Mais peut-être plutôt avec udev qui peut lancer le ssh qui va bien dès
> que tu insères une clef USB ?

Je ne sais pas trop. 
PAM offre aux applications une interface standard pour l’authentification qui 
permet de s’affranchir du mécanisme sous-jacent. Je suis en train d’étudier 
PAM. 

Re: Authentification ssh et PAM

[Michel Verdier]

Le 19 juillet 2023 RogerT a écrit :

> Pour chiffrer une phrase il suffit de la clef publique. 
> Pour déchiffrer une phrase il faut la clef privée. 

Non c'est l'inverse. C'est pour ça que seul toi a la privée et que tu
diffuses la publique à tous ceux qui doivent déchiffrer

> Le serveur a seulement la clef publique.  

Oui, tous les serveurs qui doivent te déchiffrer (= tous ceux sur
lesquels tu dois te connecter) ont la publique

> Le client a les deux clefs. 
> Seul le client peut déchiffrer une phrase chiffrée. 

Non, seul le client peut chiffrer

> Comment fait le serveur ssh pour savoir que c’est bien le détenteur de
> la clef privée qui frappe à la porte ?

Parce qu'il décode, avec la clef publique, une phrase chiffrée par le
client avec sa clef privée

>> L'idée c'est quand même d'y mettre un mot de passe pour avoir les 2
>> facteurs d'authentification.
> Ça enlève l’intérêt d’une authentification rapide.
> Ou alors il faut un gestionnaire de pwd pour stocker la phrase de passe…

Tout à fait, c'est à ça que sert kwallet ou gnome-agent ou keepassxc

>> sur le client il faut utiliser le paramètre -i pour utiliser le clef adhoc
>> ou l'indiquer dans ~/.ssh/config du client. Donc il faut monter ta clef
>> pour qu'elle soit accessible par le client.
> Entendu.
> Modulo le nom du dev /dev/sdb …
> Sauf à utiliser un UUID pour le device (ça se fait, je crois). 

oui tu mets ce qui va bien avec uuid ou partuid ou label dans /etc/fstab, avec
l'option user, et le client fait un mount du nom du répertoire que tu
précise. Par exemple chez moi :

#/dev/sdc1: LABEL_FATBOOT="CLEF" LABEL="CLEF" UUID="CC7E-404F" BLOCK_SIZE="512" 
TYPE="vfat" PARTUUID="f42f95e2-01"
LABEL="CLEF"/media/usb   vfat user,noexec,noauto,noatime,lazytime 0 
  2

PARTUUID="42711922-2694-43bd-bf1f-9d6a7fccebec" /media/backup exfat 
user,noexec,noauto,noatime,lazytime 0   0

/dev/mmcblk0p1 /media/sd  xfs 
user,noexec,noauto,rw,noatime,inode64,logbufs=8,logbsize=32k,noquota,lazytime   
  0 0

> Je me dis que pour que le HSM se substitue à moi dans la gestion des clefs, et
> aller au-delà d’indiquer le chemin de la clef (avec ssh -i) il faut sans doute
> utiliser PAM (d’ailleurs, qui sert aussi à interfacer une authentification
> LDAP).

A la base les PAM c'est plutôt pour le local, d'ailleurs sshd appelle les
PAM pour établir la session. Là ce que tu travailles c'est la
sécurisation d'une connexion ssh sur le client, donc à priori aucun
rapport avec les PAM.
Mais peut-être plutôt avec udev qui peut lancer le ssh qui va bien dès
que tu insères une clef USB ?

Re: Authentification ssh et PAM

[didier gaumet]

Le 19/07/2023 à 11:26, RogerT a écrit :

Merci beaucoup pour tes pointeurs. Je vais étudier ça.

Le HSM gérera la clef ; ou plutôt il gérera la passphrase de protection 
beaucoup plus courte que la clef elle-même 2048 bits.

En pratique, sais-tu si pour utiliser un HSM on DOIT s’interfacer avec le 
système via PAM ? (Je me dis que oui, car je crois savoir que 
l’authentification par LDAP passe par PAM).
Qui a de l’expérience sur utiliser un HSM via ou sans PAM ?
Merci.


rappel d'avertissement: je suis une tanche en réseau et sécurité, donc 
ne te fie surtout pas à mes suppositions sans te référer à des personnes 
dont tu estimes qu'elles ont une expertise valable et sans étudier avec 
esprit critique les solutions possibles.


J'ai l'*impression* (je suis une tanche) que les bonnes pratiques 
actuellement recommandent l'emploi de PAM au sein d'un groupe de 
solutions lorsqu'il s'agit d'un contexte réseau global (exemple: réseau 
d'une grosse entreprise, par opposition à un réseau d'un particulier 
offrant un unique service quelconque sans que les conséquences soient 
catastrophiques si il y a intrusion dans le réseau) ayant des impératifs 
de sécurité.


Mais j'ai l'*impression* qu'il est possible, même pour un administrateur 
réseau consciencieux et prudent, d'avoir laissé des trous dans sa config 
PAM qui permettent le contournement de PAM.


Donc j'ai l'*impression* aussi qu'il doit être possible de 
volontairement court-circuiter PAM pour employer un HSM, probablement 
dans un but de simplification


Mais j'ai aussi l'*impression* que ce serait potentiellement 
contre-productif puisque le but de PAM me semblant plus ou moins de 
border la sécurité d'accès en général et l'emploi d'un HSM représentant 
un cas d'emploi, ce serait alors potentiellement bizarre de vouloir 
contourner PAM par facilité.


Tu noteras que ça fait beaucoup d'impressions et qu'il ne serait pas 
sage de s'appuyer trop fort là-dessus ;-)


Si tu me permets une suggestion (amicale et d'un ignare du sujet), la 
réponse que t'a faite Michel Verdier par ailleurs pourrait laisser 
penser que comme moi, il s'interroge sur la clarté de tes objectifs 
(qu'est-ce que tu veux faire exactement?), et peut-être pourrais-tu 
essayer de débroussailler le but à atteindre sans dans un premier temps 
envisager les moyens à mettre en oeuvre (ici un HSM) car ça influe sur 
la réflexion


:-)

Re: Authentification ssh et PAM

[RogerT]

Merci beaucoup pour tes pointeurs. Je vais étudier ça.

Le HSM gérera la clef ; ou plutôt il gérera la passphrase de protection 
beaucoup plus courte que la clef elle-même 2048 bits.

En pratique, sais-tu si pour utiliser un HSM on DOIT s’interfacer avec le 
système via PAM ? (Je me dis que oui, car je crois savoir que 
l’authentification par LDAP passe par PAM).  
Qui a de l’expérience sur utiliser un HSM via ou sans PAM ?
Merci. 


> Le 19 juil. 2023 à 10:08, didier gaumet  a écrit :
> 
> je n'y connais rien mais tu peux éventuellement consulter ce qui suit:
> 
> - sur le fonctionnement général de PAM: la vieille doc de kernel.org (The 
> Linux-PAM System Administrators' Guide) n'est plus semble-t-il disponible sur 
> le site d'origine mais on la dtouve encore ailleurs:
> https://beausanders.org/linux_shared_files/Linux-PAM_System_Administrators_Guide.pdf
> la mage man de PAM(8) peut aussi être consultée
> 
> - sur le principe général (avec diagrammes, plus visuels) de l'emploi des 
> smartcards (sous-type de HSM); RedHat propose cette doc:
> https://www.redhat.com/en/blog/consistent-pkcs-11-support-red-hat-enterprise-linux-8
> 
> - sur la configuration particulière nécessaire à cet usage en liaison avec 
> des applis/serveurs, Red Hat propose cette doc:
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/configuring-applications-to-use-cryptographic-hardware-through-pkcs-11_security-hardening
> 

Re: Authentification ssh et PAM

[RogerT]

> Le 19 juil. 2023 à 09:05, Michel Verdier  a écrit :
> Le 18 juillet 2023 roger tarani a écrit :
> 
>> Quel est le mécanisme détaillé conduisant à l'authentification de 
>> l'utilisateur par l'hôte distant ? 
>> (la clef privée reste sur l'hôte local ; comment la clef publique et la clef 
>> privée sont-elles liées ? par la création d'un jeton ? ou autre ? )
> 
> La clef publique est indiquée au serveur lors de la demande de connexion.
> Le serveur s'en sert ensuite pour décrypter une phrase cryptée par le
> client avec sa clef privée.

Je ne comprends pas. 
Pour chiffrer une phrase il suffit de la clef publique. 
Pour déchiffrer une phrase il faut la clef privée. 
Le serveur a seulement la clef publique.  
Le client a les deux clefs. 
Seul le client peut déchiffrer une phrase chiffrée. 
Comment fait le serveur ssh pour savoir que c’est bien le détenteur de la clef 
privée qui frappe à la porte ?
Je ne vois que ça : le serveur chiffre une phrase et l’envoie au client qui lui 
retourne déchiffrée. Il compare et constate si le client a su déchiffrer. C’est 
ça ?

>> Stocker la clef privée localement avec pour seule protection des droits 600 
>> me semble léger même si c'est habituel.
> 
> L'idée c'est quand même d'y mettre un mot de passe pour avoir les 2
> facteurs d'authentification.
Ça enlève l’intérêt d’une authentification rapide.
Ou alors il faut un gestionnaire de pwd pour stocker la phrase de passe…

> 
>> Si je décide de stocker la clef privée en dehors de l'hôte local, soit sur 
>> une
>> clef flash déconnectée du réseau (avec ou sans chiffrement), soit carrément
>> sur un HSM, comment dois-je procéder pour qu'elle soit utilisée par le 
>> système
> 
> sur le client il faut utiliser le paramètre -i pour utiliser le clef adhoc
> ou l'indiquer dans ~/.ssh/config du client. Donc il faut monter ta clef
> pour qu'elle soit accessible par le client.
Entendu.
Modulo le nom du dev /dev/sdb …
Sauf à utiliser un UUID pour le device (ça se fait, je crois). 

> 
>> En cherchant, j'ai lu des choses sur PAM que je n'ai jamais pratiqué. 
>> https://linux.goffinet.org/administration/securite-locale/pluggable-authentication-modules-pam/
>>  
>> 
>> Puis-je utiliser ce qui existe (biblio PAM) pour faire communiquer l'hôte 
>> local et le HSM afin de réaliser une authentification ssh ? 
>> Comment faut-il faire ?
> 
> Je ne comprend pas ce que tu cherches à faire ? Tu veux qu'une
> authentification PAM passe par ssh et pas par le login habituel ?
Je me dis que pour que le HSM se substitue à moi dans la gestion des clefs, et 
aller au-delà d’indiquer le chemin de la clef (avec ssh -i) il faut sans doute 
utiliser PAM (d’ailleurs, qui sert aussi à interfacer une authentification 
LDAP).

Re: Authentification ssh et PAM

[didier gaumet]

je n'y connais rien mais tu peux éventuellement consulter ce qui suit:

- sur le fonctionnement général de PAM: la vieille doc de kernel.org 
(The Linux-PAM System Administrators' Guide) n'est plus semble-t-il 
disponible sur le site d'origine mais on la dtouve encore ailleurs:

https://beausanders.org/linux_shared_files/Linux-PAM_System_Administrators_Guide.pdf
la mage man de PAM(8) peut aussi être consultée

- sur le principe général (avec diagrammes, plus visuels) de l'emploi 
des smartcards (sous-type de HSM); RedHat propose cette doc:

https://www.redhat.com/en/blog/consistent-pkcs-11-support-red-hat-enterprise-linux-8

- sur la configuration particulière nécessaire à cet usage en liaison 
avec des applis/serveurs, Red Hat propose cette doc:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/configuring-applications-to-use-cryptographic-hardware-through-pkcs-11_security-hardening

Re: Authentification ssh et PAM

[Michel Verdier]

Le 18 juillet 2023 roger tarani a écrit :

> Quel est le mécanisme détaillé conduisant à l'authentification de 
> l'utilisateur par l'hôte distant ? 
> (la clef privée reste sur l'hôte local ; comment la clef publique et la clef 
> privée sont-elles liées ? par la création d'un jeton ? ou autre ? ) 

La clef publique est indiquée au serveur lors de la demande de connexion.
Le serveur s'en sert ensuite pour décrypter une phrase cryptée par le
client avec sa clef privée.

> Stocker la clef privée localement avec pour seule protection des droits 600 
> me semble léger même si c'est habituel. 

L'idée c'est quand même d'y mettre un mot de passe pour avoir les 2
facteurs d'authentification.

> Si je décide de stocker la clef privée en dehors de l'hôte local, soit sur une
> clef flash déconnectée du réseau (avec ou sans chiffrement), soit carrément
> sur un HSM, comment dois-je procéder pour qu'elle soit utilisée par le système

sur le client il faut utiliser le paramètre -i pour utiliser le clef adhoc
ou l'indiquer dans ~/.ssh/config du client. Donc il faut monter ta clef
pour qu'elle soit accessible par le client.

> En cherchant, j'ai lu des choses sur PAM que je n'ai jamais pratiqué. 
> https://linux.goffinet.org/administration/securite-locale/pluggable-authentication-modules-pam/
>  
>
> Puis-je utiliser ce qui existe (biblio PAM) pour faire communiquer l'hôte 
> local et le HSM afin de réaliser une authentification ssh ? 
> Comment faut-il faire ? 

Je ne comprend pas ce que tu cherches à faire ? Tu veux qu'une
authentification PAM passe par ssh et pas par le login habituel ?

Re: Authentification ssh et PAM

[RogerT]

Merci. 
Je connais l’usage.

Je voudrais savoir comment fonctionne le mécanisme d’authentification par clefs 
asymétriques permettant de donner l’accès à l’hôte distant. Qui fait quoi. 

Et surtout comment procéder pour utiliser un HSM ou une clef USB où sera 
stockée la clef privée. Et aussi savoir si on doit utiliser PAM, et comment.



> Le 19 juil. 2023 à 00:00, ajh-valmer  a écrit :
> 
> Il suffit de taper 3 mots dans un moteur de recherche :
> www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server-fr
> :-)
> 
>> On Tuesday 18 July 2023 18:16:21 roger.tar...@free.fr wrote:
>> Un utilisateur dispose d'une clef ssh privée et d'une clef publique 
>> rangés dans ~/.ssh/ , avec des droits 600.  
>> S'il a copié la clef publique sur un serveur distant, l'agent local
>> saura "lier la clef publique et la privée" pour lui donner accès à l'hôte
>> distant sans besoin de saisir id et pwd.   
>> Classique. 
>> Quel est le mécanisme détaillé conduisant à l'authentification de
>> l'utilisateur par l'hôte distant ?  
>> (la clef privée reste sur l'hôte local ; comment la clef publique et la clef
>> privée sont-elles liées ? par la création d'un jeton ? ou autre ? )  
>> Stocker la clef privée localement avec pour seule protection des droits 600
>> me semble léger même si c'est habituel.  
>> Si je décide de stocker la clef privée en dehors de l'hôte local, soit sur
>> une clef flash déconnectée du réseau (avec ou sans chiffrement), soit
>> carrément sur un HSM, comment dois-je procéder pour qu'elle soit utilisée
>> par le système ?
>> En cherchant, j'ai lu des choses sur PAM que je n'ai jamais pratiqué. 
>> https://linux.goffinet.org/administration/securite-locale/pluggable-authentication-modules-pam/
>>  
>> Puis-je utiliser ce qui existe (biblio PAM) pour faire communiquer l'hôte
>> local et le HSM afin de réaliser une authentification ssh ?  
>> Comment faut-il faire ?
> 

Re: Authentification ssh et PAM

[ajh-valmer]

Il suffit de taper 3 mots dans un moteur de recherche :
www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server-fr
:-)

On Tuesday 18 July 2023 18:16:21 roger.tar...@free.fr wrote:
> Un utilisateur dispose d'une clef ssh privée et d'une clef publique 
> rangés dans ~/.ssh/ , avec des droits 600.  
> S'il a copié la clef publique sur un serveur distant, l'agent local
> saura "lier la clef publique et la privée" pour lui donner accès à l'hôte
> distant sans besoin de saisir id et pwd.   
> Classique. 
> Quel est le mécanisme détaillé conduisant à l'authentification de
> l'utilisateur par l'hôte distant ?  
> (la clef privée reste sur l'hôte local ; comment la clef publique et la clef
> privée sont-elles liées ? par la création d'un jeton ? ou autre ? )  
> Stocker la clef privée localement avec pour seule protection des droits 600
> me semble léger même si c'est habituel.  
> Si je décide de stocker la clef privée en dehors de l'hôte local, soit sur
> une clef flash déconnectée du réseau (avec ou sans chiffrement), soit
> carrément sur un HSM, comment dois-je procéder pour qu'elle soit utilisée
> par le système ?
> En cherchant, j'ai lu des choses sur PAM que je n'ai jamais pratiqué. 
>https://linux.goffinet.org/administration/securite-locale/pluggable-authentication-modules-pam/
> 
> Puis-je utiliser ce qui existe (biblio PAM) pour faire communiquer l'hôte
> local et le HSM afin de réaliser une authentification ssh ?  
> Comment faut-il faire ?

Authentification ssh et PAM

[roger . tarani]

Bonjour, 

Un utilisateur dispose d'une clef ssh privée et d'une clef publique rangés dans 
~/.ssh/ , avec des droits 600. 
S'il a copié la clef publique sur un serveur distant, l'agent local saura "lier 
la clef publique et la privée" pour lui donner accès à l'hôte distant sans 
besoin de saisir id et pwd. 
Classique. 

Quel est le mécanisme détaillé conduisant à l'authentification de l'utilisateur 
par l'hôte distant ? 
(la clef privée reste sur l'hôte local ; comment la clef publique et la clef 
privée sont-elles liées ? par la création d'un jeton ? ou autre ? ) 

Stocker la clef privée localement avec pour seule protection des droits 600 me 
semble léger même si c'est habituel. 

Si je décide de stocker la clef privée en dehors de l'hôte local, soit sur une 
clef flash déconnectée du réseau (avec ou sans chiffrement), soit carrément sur 
un HSM, comment dois-je procéder pour qu'elle soit utilisée par le système ? 

En cherchant, j'ai lu des choses sur PAM que je n'ai jamais pratiqué. 
https://linux.goffinet.org/administration/securite-locale/pluggable-authentication-modules-pam/
 

Puis-je utiliser ce qui existe (biblio PAM) pour faire communiquer l'hôte local 
et le HSM afin de réaliser une authentification ssh ? 
Comment faut-il faire ? 

Merci. 

[Trouvé] Re: Sendmail et authentification par saslauthd

[BERTRAND Joël]

Bonjour à tous,

Après bricolage dans le sendmail.cf, j'ai trouvé que sendmail allait
chercher un fichier de conf Sendmail.conf partout sauf dans
/etc/mail/sasl. Normalement, ce fichier s'appelle d'ailleurs
Sendmail.conf.2 vu qu'il s'agit de saslv2.

Un lien de /etc/mail/sals/Sendmail.conf.2 vers
/usr/lib/sasl/Sendmail.conf résout le problème.

Bien cordialement,

JKB

PS: ce n'est pas la première fois que ce genre de problème m'arrive avec
Debian/Devuan, mais il serait vraiment bien que pour des modifications
qui entraînent un fonctionnement étrange sans avoir d'erreur dans les
logs avec la configuration de loglevel par défaut, celles-ci soient un
tantinet documentées. sendmail, sauf à avoir été méchamment twiké, n'a
aucune raison de chercher ce fichier sous ce nom à cet endroit.

Re: Sendmail et authentification par saslauthd

[BERTRAND Joël]

didier gaumet a écrit :
> 
> pataper: j'y connais vraiment rien
> 
> mais peut-être ici auras-tu un début de piste (utilisation de telnet et
> du port 587 pour tester sasl/smtp)
> 
> https://networking.ringofsaturn.com/Protocols/howtotestsendmailauthentication.php

Merci. Mais ça, je connais, je suis un barbu capable d'envoyer des
mails par telnet. Mon problème est surtout que sendmail semble
totalement ignorer sasl. J'en suis à comparer deux sendmail.cf, celui
d'un site fonctionnel et celui du site que je suis en train de monter.
Et même là, je ne vois rien d'aberrant.

Bien cordialement,

JKB

Re: Sendmail et authentification par saslauthd

[didier gaumet]

pataper: j'y connais vraiment rien

mais peut-être ici auras-tu un début de piste (utilisation de telnet et 
du port 587 pour tester sasl/smtp)


https://networking.ringofsaturn.com/Protocols/howtotestsendmailauthentication.php

Sendmail et authentification par saslauthd

[BERTRAND Joël]

Bonsoir à tous,

Je suis en train de monter pour une association un serveur de mail et
je butte sur un problème que je n'arrive par à résoudre.

J'utilise un sendmail des familles (parce que ça fait trente ans que
j'utilise sendmail sur tous mes systèmes allant de VMS à Solaris et que
je maîtrise à peu près l'engin, donc ne me répondez pas de passer à
postfix, exim ou pire qmail...).

Il reçoit sans problème avec tous les milters qui vont bien, mais je
n'arrive pas à envoyer un mail. L'authentification échoue. Et là, je ne
sais plus quoi faire.

J'ai bien configuré sasl2 (avec pam qui va prendre les informations
dans passwd/shadow). saslauthd fonctionne :

root:[/etc/mail] > testsaslauthd -u bertrand -p 
0: OK "Success."
root:[/etc/mail] > testsaslauthd -u bertrand -p 
0: NO "authentication failed"

J'ai naturellement redémarré sendmail après saslauthd (c'est un grand
gag, je me suis fait avoir un certain paquet de fois).

J'ai tenté de lancer sendmail avec la ligne suivante :

/usr/sbin/sendmail  -d95.99 -bD -X test.log

histoire d'avoir toute la transaction dans le fichier test.log. Le
client de messagerie envoie le mot de passe après STARTLS en plain puis
login et se fait claquer la porte aux nez. Si je lance saslautd dans un
terminal, je ne note aucune tentative vers saslauthd de la part de
sendmail (un testsaslauthd montre bien une requête).

J'ai comparé la configuration d'un serveur fonctionnel (celui à partir
duquel je poste) avec celui que je viens de monter, je ne vois pas les
différences. J'ai même vérifié les droits des différents fichiers.
Sendmail ne semble par renvoyer d'erreur, mais n'appelle pas le
mécanisme d'authentification.

Mon sendmail.mc se termine par :
LOCAL_CONFIG
include(`/etc/mail/sasl/sasl.m4')dnl
include(`/etc/mail/tls/starttls.m4')dnl

Je suis preneur de toute idée raisonnable pour débugguer la chose.

Bien cordialement,

JKB

Jitsi, authentification, host et guest

[BERTRAND Joël]

Bonjour à tous,

Je pose ma question ici, peut-être des gens ont-ils été ou sont-ils
confrontés au même problème.

J'ai indiqué il y a quelque temps ma configuration de jitsi avec
authentification pour les hôtes et les invités. Il y a en revanche un
petit quelque chose gênant que je n'arrive pas à corriger.

L'hôte peut créer un salon de discussion et des invités peuvent s'y
connecter (en s'authentifiant). Problème : si tous les invités se voient
entre eux, ils ne voient pas l'hôte. L'hôte, quant à lui, voit tout le
monde. Je ne sais plus où chercher. Mon installation est actuellement la
suivante :

rayleigh:[~] > dpkg-query -l | grep jitsi
ii  jitsi-meet2.0.4627-1
all  WebRTC JavaScript video conferences
ii  jitsi-meet-prosody1.0.4127-1
all  Prosody configuration for Jitsi Meet
ii  jitsi-meet-web1.0.4127-1
all  WebRTC JavaScript video conferences
ii  jitsi-meet-web-config 1.0.4127-1
all  Configuration for web serving of Jitsi Meet
rc  jitsi-videobridge 1126-1
amd64WebRTC compatible Selective Forwarding Unit (SFU)
ii  jitsi-videobridge22.1-202-g5f9377b9-1
all  WebRTC compatible Selective Forwarding Unit (SFU)

Je n'ai rien de particulier dans les logs. Même lorsque l'hôte coche
"tout le monde me suit", rien n'y fait.

Des idées ? J'ai bien remonté le problème au suppor de jitsi, mais
celui-ci est muet. Aujourd'hui, pour que cela fonctionne, je me connecte
en tant qu'hôte (sans caméra ni micro) pour créer le salon et je me
reconnecte à partir de la même machine en invité. Pas très pratique.

Bien cordialement,

JKB

Re: Authentification mixte Linux/AD

[Pierre Malard]

Bonjour,

Est-ce que cela ne viendrait pas de la configuration de nss ?
Et/ou la configuration de pam.d ?
Voir votre fichier /etc/nsswitch.conf et ce qui a été modifié
(ou pas) dans /etc/pam.d/ comme « common-* » .

Attention tout cela est à manier avec précaution car vous pouvez
arriver à … votre situation. ;-)
Au point où vous en êtes… une bonne lecture des « man » avec une
recherche documentaire pourrait être utile. Lisez la page
https://wiki.debian.org/LDAP/Kerberos elle aborde justement la
configuration de PAM, NSS, …
Idem avec https://wiki.debian.org/AuthenticatingLinuxWithActiveDirectory,
voir les paragraphes « Setup Authentification », « PAM » et …

Cordialement


> Le 24 avr. 2020 à 22:45, Jean-Luc Chandezon  a écrit :
> 
> 
> Bonjour,
> 
> J’ai paramétré l’authentification Active Directory va Kerberos en suivant le 
> documentation https://wiki.debian.org/AuthenticatingLinuxWithActiveDirectory, 
> et ça fonctionne bien.
> J’ai bien ajouté un groupe AD dans sudoers, sans problème. Le suffixe par 
> défaut est @mydomain.ad. Les utilisateurs n’ont donc pas besoin de le saisir.
> 
> Le problème est que, même localement, je ne peux plus ouvrir de session avec 
> root, ou avec un utilisateur local. Est-ce que cela est possible ? J’ai testé 
> root@localhost par exemple, sans succès.
> Voici ci-dessous le paramétrage de krb5.conf.
> 
> Merci
> 
> ---
> logging]
> Default = FILE:/var/log/krb5.log
> 
> [libdefaults]
> ticket_lifetime = 24000
> click-skew = 300
> default_realm = MYDOMAIN.AD
> 
> # The following krb5.conf variables are only for MIT Kerberos.
> kdc_timesync = 1
> ccache_type = 4
> forwardable = true
> proxiable = true
> [realms]
> MYDOMAIN.AD = {
> kdc = mydomain.ad:88
> admin_server = mydomain.ad:464
> default_domain = mydomain.ad
> }
> 
> Jean-Luc

--
Pierre Malard

   « Si, comme le disait le général de Gaulle, la France n'avait pas été la
   France... on peut logiquement penser que tous les français auraient été
   des étrangers » ;-)
   
Pierre Dac
   |\  _,,,---,,_
   /,`.-'`'-.  ;-;;,_
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)   πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) )-,_. ,\ 
(  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--



signature.asc
Description: Message signed with OpenPGP

Authentification mixte Linux/AD

[Jean-Luc Chandezon]

Bonjour,

J'ai paramétré l'authentification Active Directory va Kerberos en suivant le 
documentation https://wiki.debian.org/AuthenticatingLinuxWithActiveDirectory, 
et ça fonctionne bien.
J'ai bien ajouté un groupe AD dans sudoers, sans problème. Le suffixe par 
défaut est @mydomain.ad. Les utilisateurs n'ont donc pas besoin de le saisir.

Le problème est que, même localement, je ne peux plus ouvrir de session avec 
root, ou avec un utilisateur local. Est-ce que cela est possible ? J'ai testé 
root@localhost par exemple, sans succès.
Voici ci-dessous le paramétrage de krb5.conf.

Merci

---
logging]
Default = FILE:/var/log/krb5.log

[libdefaults]
ticket_lifetime = 24000
click-skew = 300
default_realm = MYDOMAIN.AD

# The following krb5.conf variables are only for MIT Kerberos.
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true
[realms]
MYDOMAIN.AD = {
kdc = mydomain.ad:88
admin_server = mydomain.ad:464
default_domain = mydomain.ad
}

Jean-Luc

Re: Authentification failure

[steve]

Le 05-06-2019, à 14:23:04 +0200, Yahoo a écrit :



Il est donc possible que  soit trop simple


C'est ce qui semble en effet. J'ai choisi un port différent (guess what)
et depuis 4 jours, pas une seule tentative !

Re: Authentification failure

[Florian Blanc]

Je persiste et signe qu'un DROP est je ne sais combien de fois mieux qu'un
REJECT sur du traffic non legit.
Il le bénéfice de masquer ton service.
Le botnets peuvent avoir le timeout qu'ils veulent même de 1s c'est pas un
problème.
Justement à chaque DROP tu économise un ICMP destination-unreachable par
rapport au REJECT...

après niveau lectures tu trouveras toujours de tout du style: les
reptiliens existent et voici un peu de lecture :
https://8e-etage.fr/2014/11/07/les-reptiliens-la-plus-grande-conspiration-politique-jamais-inventee/


Le ven. 7 juin 2019 à 19:37, daniel huhardeaux  a
écrit :

> Le 07/06/2019 à 18:40, Florian Blanc a écrit :
> > le client va timeout
>
> Sauf qu'un attaquant ne va pas utiliser des scanners habituels mais des
> outils spécifiques qui pour eux DROP ou REJECT ne change rien, leur
> timeout sera très court
>
> Une lecture par ex.
>
> http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject
>
> >
> > Le ven. 7 juin 2019 à 18:39, Florian Blanc  > > a écrit :
> >
> >  > si on peut lister les URL légitimes, un silent DROP systématique
> > permet de ne pas confirmer la présence d'une cible potentielle, non ?
> > exactement
> >
> > Le ven. 7 juin 2019 à 18:34, Eric Degenetais  > > a écrit :
> >
> > bonjour,
> > si on peut lister les URL légitimes, un silent DROP systématique
> > permet de ne pas confirmer la présence d'une cible potentielle,
> > non ?
> > À l'inverse, fail2ban, qui est utile quoi qu'il arrive pour
> > arrêter les tentatives de brute force qui atteignent le service
> > protégé, a besoin d'enregistrer un certain nombre d'échecs avant
> > de bannir, donc l'existence et la nature de la cible (sshd) sont
> > confirmées à l'attaquant.
> >
> > Éric Dégenètais
> >
> > Le ven. 7 juin 2019 17:48, Daniel Caillibaud  > > a écrit :
> >
> > Le 07/06/19 à 16:39, Florian Blanc
> >  > > a écrit :
> >  >  > Et ça change vraiment grand chose ?
> >
> >  > cf. modele OSI ton firewall refusera les connexions layer
> > 3/4.
> >
> > Merci ;-)
> >
> > Ce que je voulais dire, c'est que le gain de perfs[1] est
> > tellement
> > négligeable que je pense qu'on arrive même pas à le mesurer
> > sur une machine
> > en prod (qui bosse).
> >
> > Mais ici le pb est pas tellement la perf, tu veux bloquer
> > des connexions
> > ssh avec un liste blanche d'ip (dynamique dans ton cas), ça
> > n'est pas
> > envisageable dans mon contexte (mes ssh publics doivent
> > rester accessibles
> > par trop d'ip ≠ qui changent tout le temps), et sur le fond
> > je vois pas
> > d'intérêt à sécuriser davantage ssh que de forcer la
> > connexion par clé.
> >
> > [1] si y'en a un, faudrait comparer ce que coûte une règle
> > iptable
> > supplémentaire (qq cycles cpu sur tous les paquets reçus) vs
> > qq connexions
> > ssh inutiles (sshd doit attendre une clé qui ne vient pas
> > puis couper).
> >
> > --
> > Daniel
> >
> > La médecine est un métier dangereux :
> > les clients qui ne meurent pas peuvent porter plainte.
> > Coluche
> >
>
>

Re: Authentification failure

[daniel huhardeaux]

Le 07/06/2019 à 18:40, Florian Blanc a écrit :

le client va timeout


Sauf qu'un attaquant ne va pas utiliser des scanners habituels mais des 
outils spécifiques qui pour eux DROP ou REJECT ne change rien, leur 
timeout sera très court


Une lecture par ex.

http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject



Le ven. 7 juin 2019 à 18:39, Florian Blanc > a écrit :


 > si on peut lister les URL légitimes, un silent DROP systématique
permet de ne pas confirmer la présence d'une cible potentielle, non ?
exactement

Le ven. 7 juin 2019 à 18:34, Eric Degenetais mailto:edegenet...@henix.fr>> a écrit :

bonjour,
si on peut lister les URL légitimes, un silent DROP systématique
permet de ne pas confirmer la présence d'une cible potentielle,
non ?
À l'inverse, fail2ban, qui est utile quoi qu'il arrive pour
arrêter les tentatives de brute force qui atteignent le service
protégé, a besoin d'enregistrer un certain nombre d'échecs avant
de bannir, donc l'existence et la nature de la cible (sshd) sont
confirmées à l'attaquant.

Éric Dégenètais

Le ven. 7 juin 2019 17:48, Daniel Caillibaud mailto:m...@lairdutemps.org>> a écrit :

Le 07/06/19 à 16:39, Florian Blanc
mailto:florian.blanc@gmail.com>> a écrit :
 >  > Et ça change vraiment grand chose ?

 > cf. modele OSI ton firewall refusera les connexions layer
3/4.

Merci ;-)

Ce que je voulais dire, c'est que le gain de perfs[1] est
tellement
négligeable que je pense qu'on arrive même pas à le mesurer
sur une machine
en prod (qui bosse).

Mais ici le pb est pas tellement la perf, tu veux bloquer
des connexions
ssh avec un liste blanche d'ip (dynamique dans ton cas), ça
n'est pas
envisageable dans mon contexte (mes ssh publics doivent
rester accessibles
par trop d'ip ≠ qui changent tout le temps), et sur le fond
je vois pas
d'intérêt à sécuriser davantage ssh que de forcer la
connexion par clé.

[1] si y'en a un, faudrait comparer ce que coûte une règle
iptable
supplémentaire (qq cycles cpu sur tous les paquets reçus) vs
qq connexions
ssh inutiles (sshd doit attendre une clé qui ne vient pas
puis couper).

-- 
Daniel


La médecine est un métier dangereux :
les clients qui ne meurent pas peuvent porter plainte.
Coluche

Re: Authentification failure

[Florian Blanc]

le client va timeout

Le ven. 7 juin 2019 à 18:39, Florian Blanc  a
écrit :

> > si on peut lister les URL légitimes, un silent DROP systématique permet
> de ne pas confirmer la présence d'une cible potentielle, non ?
> exactement
>
> Le ven. 7 juin 2019 à 18:34, Eric Degenetais  a
> écrit :
>
>> bonjour,
>> si on peut lister les URL légitimes, un silent DROP systématique permet
>> de ne pas confirmer la présence d'une cible potentielle, non ?
>> À l'inverse, fail2ban, qui est utile quoi qu'il arrive pour arrêter les
>> tentatives de brute force qui atteignent le service protégé, a besoin
>> d'enregistrer un certain nombre d'échecs avant de bannir, donc l'existence
>> et la nature de la cible (sshd) sont confirmées à l'attaquant.
>>
>> Éric Dégenètais
>>
>> Le ven. 7 juin 2019 17:48, Daniel Caillibaud  a
>> écrit :
>>
>>> Le 07/06/19 à 16:39, Florian Blanc  a
>>> écrit :
>>> >  > Et ça change vraiment grand chose ?
>>>
>>> > cf. modele OSI ton firewall refusera les connexions layer 3/4.
>>>
>>> Merci ;-)
>>>
>>> Ce que je voulais dire, c'est que le gain de perfs[1] est tellement
>>> négligeable que je pense qu'on arrive même pas à le mesurer sur une
>>> machine
>>> en prod (qui bosse).
>>>
>>> Mais ici le pb est pas tellement la perf, tu veux bloquer des connexions
>>> ssh avec un liste blanche d'ip (dynamique dans ton cas), ça n'est pas
>>> envisageable dans mon contexte (mes ssh publics doivent rester
>>> accessibles
>>> par trop d'ip ≠ qui changent tout le temps), et sur le fond je vois pas
>>> d'intérêt à sécuriser davantage ssh que de forcer la connexion par clé.
>>>
>>> [1] si y'en a un, faudrait comparer ce que coûte une règle iptable
>>> supplémentaire (qq cycles cpu sur tous les paquets reçus) vs qq
>>> connexions
>>> ssh inutiles (sshd doit attendre une clé qui ne vient pas puis couper).
>>>
>>> --
>>> Daniel
>>>
>>> La médecine est un métier dangereux :
>>> les clients qui ne meurent pas peuvent porter plainte.
>>> Coluche
>>>
>>>

Re: Authentification failure

[Florian Blanc]

> si on peut lister les URL légitimes, un silent DROP systématique permet
de ne pas confirmer la présence d'une cible potentielle, non ?
exactement

Le ven. 7 juin 2019 à 18:34, Eric Degenetais  a
écrit :

> bonjour,
> si on peut lister les URL légitimes, un silent DROP systématique permet de
> ne pas confirmer la présence d'une cible potentielle, non ?
> À l'inverse, fail2ban, qui est utile quoi qu'il arrive pour arrêter les
> tentatives de brute force qui atteignent le service protégé, a besoin
> d'enregistrer un certain nombre d'échecs avant de bannir, donc l'existence
> et la nature de la cible (sshd) sont confirmées à l'attaquant.
>
> Éric Dégenètais
>
> Le ven. 7 juin 2019 17:48, Daniel Caillibaud  a
> écrit :
>
>> Le 07/06/19 à 16:39, Florian Blanc  a écrit
>> :
>> >  > Et ça change vraiment grand chose ?
>>
>> > cf. modele OSI ton firewall refusera les connexions layer 3/4.
>>
>> Merci ;-)
>>
>> Ce que je voulais dire, c'est que le gain de perfs[1] est tellement
>> négligeable que je pense qu'on arrive même pas à le mesurer sur une
>> machine
>> en prod (qui bosse).
>>
>> Mais ici le pb est pas tellement la perf, tu veux bloquer des connexions
>> ssh avec un liste blanche d'ip (dynamique dans ton cas), ça n'est pas
>> envisageable dans mon contexte (mes ssh publics doivent rester accessibles
>> par trop d'ip ≠ qui changent tout le temps), et sur le fond je vois pas
>> d'intérêt à sécuriser davantage ssh que de forcer la connexion par clé.
>>
>> [1] si y'en a un, faudrait comparer ce que coûte une règle iptable
>> supplémentaire (qq cycles cpu sur tous les paquets reçus) vs qq connexions
>> ssh inutiles (sshd doit attendre une clé qui ne vient pas puis couper).
>>
>> --
>> Daniel
>>
>> La médecine est un métier dangereux :
>> les clients qui ne meurent pas peuvent porter plainte.
>> Coluche
>>
>>

Re: Authentification failure

[Eric Degenetais]

bonjour,
si on peut lister les URL légitimes, un silent DROP systématique permet de
ne pas confirmer la présence d'une cible potentielle, non ?
À l'inverse, fail2ban, qui est utile quoi qu'il arrive pour arrêter les
tentatives de brute force qui atteignent le service protégé, a besoin
d'enregistrer un certain nombre d'échecs avant de bannir, donc l'existence
et la nature de la cible (sshd) sont confirmées à l'attaquant.

Éric Dégenètais

Le ven. 7 juin 2019 17:48, Daniel Caillibaud  a écrit :

> Le 07/06/19 à 16:39, Florian Blanc  a écrit :
> >  > Et ça change vraiment grand chose ?
>
> > cf. modele OSI ton firewall refusera les connexions layer 3/4.
>
> Merci ;-)
>
> Ce que je voulais dire, c'est que le gain de perfs[1] est tellement
> négligeable que je pense qu'on arrive même pas à le mesurer sur une machine
> en prod (qui bosse).
>
> Mais ici le pb est pas tellement la perf, tu veux bloquer des connexions
> ssh avec un liste blanche d'ip (dynamique dans ton cas), ça n'est pas
> envisageable dans mon contexte (mes ssh publics doivent rester accessibles
> par trop d'ip ≠ qui changent tout le temps), et sur le fond je vois pas
> d'intérêt à sécuriser davantage ssh que de forcer la connexion par clé.
>
> [1] si y'en a un, faudrait comparer ce que coûte une règle iptable
> supplémentaire (qq cycles cpu sur tous les paquets reçus) vs qq connexions
> ssh inutiles (sshd doit attendre une clé qui ne vient pas puis couper).
>
> --
> Daniel
>
> La médecine est un métier dangereux :
> les clients qui ne meurent pas peuvent porter plainte.
> Coluche
>
>

Re: Authentification failure

[Daniel Caillibaud]

Le 07/06/19 à 16:39, Florian Blanc  a écrit :
>  > Et ça change vraiment grand chose ?

> cf. modele OSI ton firewall refusera les connexions layer 3/4.

Merci ;-)

Ce que je voulais dire, c'est que le gain de perfs[1] est tellement
négligeable que je pense qu'on arrive même pas à le mesurer sur une machine
en prod (qui bosse).

Mais ici le pb est pas tellement la perf, tu veux bloquer des connexions
ssh avec un liste blanche d'ip (dynamique dans ton cas), ça n'est pas
envisageable dans mon contexte (mes ssh publics doivent rester accessibles
par trop d'ip ≠ qui changent tout le temps), et sur le fond je vois pas
d'intérêt à sécuriser davantage ssh que de forcer la connexion par clé.

[1] si y'en a un, faudrait comparer ce que coûte une règle iptable
supplémentaire (qq cycles cpu sur tous les paquets reçus) vs qq connexions
ssh inutiles (sshd doit attendre une clé qui ne vient pas puis couper).

-- 
Daniel

La médecine est un métier dangereux :
les clients qui ne meurent pas peuvent porter plainte.
Coluche

Re: Authentification failure

[Florian Blanc]

 > Et ça change vraiment grand chose ?
cf. modele OSI ton firewall refusera les connexions layer 3/4.

> C'est ça que je comprends pas trop, quel rapport avec ip fixe ou pas ?
> Sans ip fixe ça fonctionne aussi très bien avec un ssh classique sur le
> port 22 (sans ces règles iptables).
Si client avec ip fixe, tu ajoutes ta règle définitivement.
Si client avec ip dynamique ou nomade, ta règle doit évoluer .. (d'où
l'utilisation du noip avec cron).

> Ta solution bloque le port 22 si on arrive pas de la bonne ip, qu'elle
soit
> fixe ou pas, et c'est ça que je trouve pas très utile (car me concernant
> je veux pas restreindre l'accès ssh à une seule ip, mais je pensais
surtout
> au gain du port fermé si on vient pas du bon endroit vs l'énergie à
déployer
> pour maintenir ces règles et la perte potentielle de temps le jour où on
> voudra comprendre pourquoi un truc standard marche pas), mais ça reste mon
> avis, y'a pas de jugement de valeur.
bin une règle par ip ( ou noip )/range/network.
le reste du traffic non legit => DROP.
(la requête est encaissée mais pas de retour client ni de propagation).

Le ven. 7 juin 2019 à 14:25, Daniel Caillibaud  a
écrit :

> Le 07/06/19 à 03:53, Florian Blanc  a écrit :
> > Alors non ssh ne recevra seulement les requêtes provenant de l'adresse Ip
> > autorisée dans iptables tu le sais,  donc tout le reste du traffic sera
> > traité par iptables et non par le service.
>
> Et ça change vraiment grand chose ?
>
> Car un ssh qui écoute, ouvre une connexion pour attendre une clé et
> referme, même avec des ssh souvent attaqués en bruteforce, ça se voit pas
> sur mes mesures tellement c'est négligeable devant le reste.
>
> Avec ta solution iptables ça lui fait une chaîne de plus à traiter pour
> chaque paquet entrant, ça doit pas être bien cher non plus mais je ne suis
> pas sûr que ce soit meilleur coté perfs (j'en sais rien, et amha la perf
> n'est pas le pb ici).
>
> > Effectivement je flush une chaîne iptables et je réinsére mes (3)règles
> > (dynamiques seulement) avec résolution dns(3) toutes les 20 minutes.
> Alors
> > bench le si tu veux mais c'est rien comparé aux flux que tu as si tu
> > laisse tout le monde accéder jusqu'à l'authentification du service.
> > (3 car 3 postes clients, même plus ça serait pas un problème).
> >
> > Et pour finir la mise à jour du noip c'est côté client donc ça c'est pas
> > un problème on en parle même pas.
> >
> > Ma solution n'est pas la meilleure mais c'est une bonne alternative si on
> > n'a pas d'ip fixe côté client bien entendu.
>
> C'est ça que je comprends pas trop, quel rapport avec ip fixe ou pas ?
>
> Sans ip fixe ça fonctionne aussi très bien avec un ssh classique sur le
> port 22 (sans ces règles iptables).
>
> Ta solution bloque le port 22 si on arrive pas de la bonne ip, qu'elle soit
> fixe ou pas, et c'est ça que je trouve pas très utile (car me concernant
> je veux pas restreindre l'accès ssh à une seule ip, mais je pensais surtout
> au gain du port fermé si on vient pas du bon endroit vs l'énergie à
> déployer
> pour maintenir ces règles et la perte potentielle de temps le jour où on
> voudra comprendre pourquoi un truc standard marche pas), mais ça reste mon
> avis, y'a pas de jugement de valeur.
>
> Amicalement,
>
> --
> Daniel
>
> Un clavier azerty en vaut deux.
>
>

Re: Authentification failure

[Daniel Caillibaud]

Le 07/06/19 à 03:53, Florian Blanc  a écrit :
> Alors non ssh ne recevra seulement les requêtes provenant de l'adresse Ip
> autorisée dans iptables tu le sais,  donc tout le reste du traffic sera
> traité par iptables et non par le service.

Et ça change vraiment grand chose ?

Car un ssh qui écoute, ouvre une connexion pour attendre une clé et
referme, même avec des ssh souvent attaqués en bruteforce, ça se voit pas
sur mes mesures tellement c'est négligeable devant le reste.

Avec ta solution iptables ça lui fait une chaîne de plus à traiter pour
chaque paquet entrant, ça doit pas être bien cher non plus mais je ne suis
pas sûr que ce soit meilleur coté perfs (j'en sais rien, et amha la perf
n'est pas le pb ici).

> Effectivement je flush une chaîne iptables et je réinsére mes (3)règles
> (dynamiques seulement) avec résolution dns(3) toutes les 20 minutes. Alors
> bench le si tu veux mais c'est rien comparé aux flux que tu as si tu
> laisse tout le monde accéder jusqu'à l'authentification du service.
> (3 car 3 postes clients, même plus ça serait pas un problème).
> 
> Et pour finir la mise à jour du noip c'est côté client donc ça c'est pas
> un problème on en parle même pas.
> 
> Ma solution n'est pas la meilleure mais c'est une bonne alternative si on
> n'a pas d'ip fixe côté client bien entendu.

C'est ça que je comprends pas trop, quel rapport avec ip fixe ou pas ?

Sans ip fixe ça fonctionne aussi très bien avec un ssh classique sur le
port 22 (sans ces règles iptables). 

Ta solution bloque le port 22 si on arrive pas de la bonne ip, qu'elle soit
fixe ou pas, et c'est ça que je trouve pas très utile (car me concernant
je veux pas restreindre l'accès ssh à une seule ip, mais je pensais surtout
au gain du port fermé si on vient pas du bon endroit vs l'énergie à déployer
pour maintenir ces règles et la perte potentielle de temps le jour où on
voudra comprendre pourquoi un truc standard marche pas), mais ça reste mon
avis, y'a pas de jugement de valeur.

Amicalement,

-- 
Daniel

Un clavier azerty en vaut deux.

Re: Authentification failure

[Florian Blanc]

C'est dommage on arrive dans tes retranchements, pour quelqu'un
d'omniscient ça doit faire bizarre.

Alors non ssh ne recevra seulement les requêtes provenant de l'adresse Ip
autorisée dans iptables tu le sais,  donc tout le reste du traffic sera
traité par iptables et non par le service.

Effectivement je flush une chaîne iptables et je réinsére mes (3)règles
(dynamiques seulement) avec résolution dns(3) toutes les 20 minutes. Alors
bench le si tu veux mais c'est rien comparé aux flux que tu as si tu laisse
tout le monde accéder jusqu'à l'authentification du service.
(3 car 3 postes clients, même plus ça serait pas un problème).

Et pour finir la mise à jour du noip c'est côté client donc ça c'est pas un
problème on en parle même pas.

Ma solution n'est pas la meilleure mais c'est une bonne alternative si on
n'a pas d'ip fixe côté client bien entendu.
Si tu es nomade, cette solution peut t'intéresser également.

C'est dommage car c'est pas la première fois que je te vois répondre ici et
tu as plein de connaissances. Malheureusement tu n'aime vraiment pas le
contre exemple ou solution qui ne va pas en ton sens.
Cependant t'as une bonne habileté rhétorique en général.

Un esprit humble plus communautaire et moins "mentorisé" serait apprécié.

Pour finir, iptables est livré avec un hitcount qui est très utile si vous
êtes capable de définir un nombre max de hit sur une durée par user pour
tel service. Finissez avec Fail2ban qui regarde les logs. (Ceux utilisant
des certificats ne sont pas exempts).

Bonne journée.

Re: Authentification failure

[Daniel Huhardeaux]

Le 06/06/2019 à 20:10, Florian Blanc a écrit :
Lol tu réduis la charge serveur au lieu de laisser ssh écouter et 
répondre à tout le net... (valable pour tous les types 
d'authentification ssh)

Merci de me faire savoir si je me trompe 


Je pense que oui:

. avec tes règles ssh écoute également tout le net, il doit bien savoir 
si c'est toi qui tente une connexion

. tu génères du trafic cron inutile toutes les 20mn
. tu génères du trafic pour mettre noip à jour


T'es le meilleur Daniel


Je suis d'accord, sa solution est la meilleure



On Thu, Jun 6, 2019, 19:42 Daniel Caillibaud > wrote:


Le 06/06/19 à 16:51, Florian Blanc mailto:florian.blanc@gmail.com>> a écrit :
 > Bon je vais vous livrer un petit secret.
 > J'utilise des noip qui mettent à jour mon ip public cliente sur
un dns.
 >
 > Sur mon script principal iptables je crée une chain qui s'appelle
 > INDYNAMIC à partir de INPUT:
 > /sbin/iptables -A INPUT -j INDYNAMIC
 >
 > Ensuite j'ai un second script iptables pour écraser mes regles
dynamique
 > comme ceci:
 > /sbin/iptables -F INDYNAMIC # ici je flush
 > /sbin/iptables -A INDYNAMIC -m tcp -p tcp --src
 > lolilol.dyndnsnoiplalala.io 
--dport 22 -j ACCEPT # j'autorise
 > lolilol.dyndnsnoiplalala.io 
sur le port 22 (il fait la résolution comme
 > un grand).
 >
 > je crontab ce dernier script qui s'execute toutes les x minutes
(20 par
 > exemple).
 > tu le combine à fail2ban et c'est bon.

C'est bien ce que je disais :

 > > Pourquoi faire (compliqué) ?

Car je ne vois aucun avantage par rapport à ne rien faire (en dehors de
virer l'auth par mot de passe si c'est pas déjà le cas).

-- 
Daniel


Certaines zones de pêche commencent a être tellement polluées
par les hydrocarbures qu'on y pêche des turbots diesels.
Philippe Geluck, Le chat

Re: Authentification failure

[Florian Blanc]

Lol tu réduis la charge serveur au lieu de laisser ssh écouter et répondre
à tout le net... (valable pour tous les types d'authentification ssh)
Merci de me faire savoir si je me trompe 
T'es le meilleur Daniel

On Thu, Jun 6, 2019, 19:42 Daniel Caillibaud  wrote:

> Le 06/06/19 à 16:51, Florian Blanc  a écrit :
> > Bon je vais vous livrer un petit secret.
> > J'utilise des noip qui mettent à jour mon ip public cliente sur un dns.
> >
> > Sur mon script principal iptables je crée une chain qui s'appelle
> > INDYNAMIC à partir de INPUT:
> > /sbin/iptables -A INPUT -j INDYNAMIC
> >
> > Ensuite j'ai un second script iptables pour écraser mes regles dynamique
> > comme ceci:
> > /sbin/iptables -F INDYNAMIC # ici je flush
> > /sbin/iptables -A INDYNAMIC -m tcp -p tcp --src
> > lolilol.dyndnsnoiplalala.io --dport 22 -j ACCEPT # j'autorise
> > lolilol.dyndnsnoiplalala.io sur le port 22 (il fait la résolution comme
> > un grand).
> >
> > je crontab ce dernier script qui s'execute toutes les x minutes (20 par
> > exemple).
> > tu le combine à fail2ban et c'est bon.
>
> C'est bien ce que je disais :
>
> > > Pourquoi faire (compliqué) ?
>
> Car je ne vois aucun avantage par rapport à ne rien faire (en dehors de
> virer l'auth par mot de passe si c'est pas déjà le cas).
>
> --
> Daniel
>
> Certaines zones de pêche commencent a être tellement polluées
> par les hydrocarbures qu'on y pêche des turbots diesels.
> Philippe Geluck, Le chat
>
>

Re: Authentification failure

[Daniel Caillibaud]

Le 06/06/19 à 16:51, Florian Blanc  a écrit :
> Bon je vais vous livrer un petit secret.
> J'utilise des noip qui mettent à jour mon ip public cliente sur un dns.
> 
> Sur mon script principal iptables je crée une chain qui s'appelle
> INDYNAMIC à partir de INPUT:
> /sbin/iptables -A INPUT -j INDYNAMIC
> 
> Ensuite j'ai un second script iptables pour écraser mes regles dynamique
> comme ceci:
> /sbin/iptables -F INDYNAMIC # ici je flush
> /sbin/iptables -A INDYNAMIC -m tcp -p tcp --src
> lolilol.dyndnsnoiplalala.io --dport 22 -j ACCEPT # j'autorise
> lolilol.dyndnsnoiplalala.io sur le port 22 (il fait la résolution comme
> un grand).
> 
> je crontab ce dernier script qui s'execute toutes les x minutes (20 par
> exemple).
> tu le combine à fail2ban et c'est bon.

C'est bien ce que je disais :

> > Pourquoi faire (compliqué) ?

Car je ne vois aucun avantage par rapport à ne rien faire (en dehors de
virer l'auth par mot de passe si c'est pas déjà le cas).

-- 
Daniel

Certaines zones de pêche commencent a être tellement polluées 
par les hydrocarbures qu'on y pêche des turbots diesels.
Philippe Geluck, Le chat

Re: Authentification failure

[Florian Blanc]

Bon je vais vous livrer un petit secret.
J'utilise des noip qui mettent à jour mon ip public cliente sur un dns.

Sur mon script principal iptables je crée une chain qui s'appelle INDYNAMIC
à partir de INPUT:
/sbin/iptables -A INPUT -j INDYNAMIC

Ensuite j'ai un second script iptables pour écraser mes regles dynamique
comme ceci:
/sbin/iptables -F INDYNAMIC # ici je flush
/sbin/iptables -A INDYNAMIC -m tcp -p tcp --src lolilol.dyndnsnoiplalala.io
--dport 22 -j ACCEPT # j'autorise lolilol.dyndnsnoiplalala.io sur le port
22 (il fait la résolution comme un grand).

je crontab ce dernier script qui s'execute toutes les x minutes (20 par
exemple).
tu le combine à fail2ban et c'est bon.

Le jeu. 6 juin 2019 à 15:45, Daniel Caillibaud  a
écrit :

> Le 06/06/19 à 10:31, Arnaud Gambonnet  a
> écrit :
> > Bonjour la liste,
> >
> > Je n'ai pas lu en détails le fil, mais pour protéger les demandes
> > intempestives de connexions ssh (et d'autres si besoin), il existe la
> > solution de port knocking.
>
> Pourquoi faire (compliqué) ?
>
> > Ce qui n’empêche pas de mettre en place une authentification par
> > certificat et fail2ban pour les services moins sensibles.
>
> Au contraire, auth par certif pour tous les serveurs, sensibles ou pas, et
> plus besoin de port knocking ni port exotique ni fail2ban, on peut rester
> sur du standard avec ssh sur le port 22 qui fonctionne comme attendu.
>
> --
> Daniel
>
> On devient jeune à soixante ans.
> Malheureusement c'est trop tard.
> Pablo Picasso
>
>

Re: Authentification failure

[Daniel Caillibaud]

Le 06/06/19 à 10:31, Arnaud Gambonnet  a écrit :
> Bonjour la liste,
> 
> Je n'ai pas lu en détails le fil, mais pour protéger les demandes
> intempestives de connexions ssh (et d'autres si besoin), il existe la
> solution de port knocking.

Pourquoi faire (compliqué) ?

> Ce qui n’empêche pas de mettre en place une authentification par
> certificat et fail2ban pour les services moins sensibles.

Au contraire, auth par certif pour tous les serveurs, sensibles ou pas, et
plus besoin de port knocking ni port exotique ni fail2ban, on peut rester
sur du standard avec ssh sur le port 22 qui fonctionne comme attendu.

-- 
Daniel

On devient jeune à soixante ans.
Malheureusement c'est trop tard.
Pablo Picasso

Re: Authentification failure

[Arnaud Gambonnet]

Bonjour la liste,

Je n'ai pas lu en détails le fil, mais pour protéger les demandes
intempestives de connexions ssh (et d'autres si besoin), il existe la
solution de port knocking.
Ce qui n’empêche pas de mettre en place une authentification par certificat
et fail2ban pour les services moins sensibles.

Bonnes cogitations...

Le jeu. 6 juin 2019 à 09:18, Pierre Malard  a écrit :

>
> > Le 6 juin 2019 à 09:09, Daniel Caillibaud  a écrit :
> >
> > Le 06/06/19 à 08:30, Pierre Malard  a écrit :
> >> Bonjour,
> >>
> >> Sans présumer de qui est le plus « méchant » (Chinois, Russes, USA, Fr…)
> >> et pratique le scan massif, je ne saurait trop conseiller un filtrage
> >> avec la limitation des ports ouverts par un pare-feu et, sur les
> serveurs
> >> ouverts, l’installation de « Fail2Ban » en validant les règles «
> récidive
> >> ».
> >
> > Sur un serveur en prod, l'intérêt d'un pare-feu est quand même très
> limité
> > (éventuellement pour gérer du throttle), à priori si un port est ouvert
> sur
> > une ip publique c'est qu'on veut qu'il soit accessible (sinon on l'aurait
> > pas ouvert là).
>
> Effectivement c’est pourquoi il y avait un « et » et non un « ou ».
>
> > Pour le sshd, le plus efficace reste encore de le configurer pour
> interdire
> > la connexion par mot de passe, ensuite fail2ban n'est plus nécessaire
> > (sinon pour réduire le bruit dans auth.log).
> >
> > Il faut mettre dans /etc/ssh/sshd_config la ligne :
> >
> >  PasswordAuthentication no
>
> Effectivement, c’est même l’option par défaut sur toute installation
> actuellement. C'était, dans mon esprit, la configuration de base mais il
> est vrai
> que ce n’est pas parce que « ça allait sans le dire qu’il ne faut pas …
> le dire ».
>
> Merci
>
> --
> Pierre Malard
> - --> Ce message n’engage que son auteur <--
>
>

Re: Authentification failure

[Pierre Malard]

> Le 6 juin 2019 à 09:09, Daniel Caillibaud  a écrit :
> 
> Le 06/06/19 à 08:30, Pierre Malard  a écrit :
>> Bonjour,
>> 
>> Sans présumer de qui est le plus « méchant » (Chinois, Russes, USA, Fr…)
>> et pratique le scan massif, je ne saurait trop conseiller un filtrage
>> avec la limitation des ports ouverts par un pare-feu et, sur les serveurs
>> ouverts, l’installation de « Fail2Ban » en validant les règles « récidive
>> ».
> 
> Sur un serveur en prod, l'intérêt d'un pare-feu est quand même très limité
> (éventuellement pour gérer du throttle), à priori si un port est ouvert sur
> une ip publique c'est qu'on veut qu'il soit accessible (sinon on l'aurait
> pas ouvert là).

Effectivement c’est pourquoi il y avait un « et » et non un « ou ».

> Pour le sshd, le plus efficace reste encore de le configurer pour interdire
> la connexion par mot de passe, ensuite fail2ban n'est plus nécessaire
> (sinon pour réduire le bruit dans auth.log).
> 
> Il faut mettre dans /etc/ssh/sshd_config la ligne :
> 
>  PasswordAuthentication no

Effectivement, c’est même l’option par défaut sur toute installation
actuellement. C'était, dans mon esprit, la configuration de base mais il est 
vrai
que ce n’est pas parce que « ça allait sans le dire qu’il ne faut pas …
le dire ».

Merci

--
Pierre Malard
- --> Ce message n’engage que son auteur <--



signature.asc
Description: Message signed with OpenPGP

Re: Authentification failure

[Daniel Caillibaud]

Le 06/06/19 à 08:30, Pierre Malard  a écrit :
> Bonjour,
> 
> Sans présumer de qui est le plus « méchant » (Chinois, Russes, USA, Fr…)
> et pratique le scan massif, je ne saurait trop conseiller un filtrage
> avec la limitation des ports ouverts par un pare-feu et, sur les serveurs
> ouverts, l’installation de « Fail2Ban » en validant les règles « récidive
> ».

Sur un serveur en prod, l'intérêt d'un pare-feu est quand même très limité
(éventuellement pour gérer du throttle), à priori si un port est ouvert sur
une ip publique c'est qu'on veut qu'il soit accessible (sinon on l'aurait
pas ouvert là).

Pour le sshd, le plus efficace reste encore de le configurer pour interdire
la connexion par mot de passe, ensuite fail2ban n'est plus nécessaire
(sinon pour réduire le bruit dans auth.log).

Il faut mettre dans /etc/ssh/sshd_config la ligne :

  PasswordAuthentication no

-- 
Daniel

Ne disons pas du mal du diable : c'est peut-être l'homme 
d'affaires du bon dieu.
Bernard Fontenelle 


pgpoEkqiupUlf.pgp
Description: Signature digitale OpenPGP

Re: Authentification failure

[Pierre Malard]

Bonjour,

Sans présumer de qui est le plus « méchant » (Chinois, Russes, USA, Fr…) et 
pratique
le scan massif, je ne saurait trop conseiller un filtrage avec la limitation des
ports ouverts par un pare-feu et, sur les serveurs ouverts, l’installation de
« Fail2Ban » en validant les règles « récidive ».

Pour ceux qui ne savent pas entendre raison il y a le truc de « ban-them » qui
construit une liste à chaud de ceux-là et … les bannis définitivement. C’est
très utile et évite de faire tout ça à la main :
https://www.cybernaute.ch/bannir-definitivement-ip-bannies-frequemment-fail2ban/#comment-366
Cela demande tout de même une surveillance pour éviter les faux positifs mais
c’est très bien.

Cordialement

> Le 5 juin 2019 à 14:23, Yahoo  a écrit :
> 
> D??sol??, je n'avais pas compris ta demande.
> 
> Donc sur la fr??quence, de mon c??t?? j'ai tr??s peu d'attaque force brut sur 
> le service ssh, mais effectivement j'utilise un port un peu plus exotique que 
> le tiens
> 
> la vue pour un serveur up depuis 1 ans:
> 
> Status for the jail: sshd
> |- Filter
> |?? |- Currently failed: 0
> |?? |- Total failed: 23
> |?? `- File list:?? /var/log/auth.log
> `- Actions
>  |- Currently banned: 0
>  |- Total banned: 1
>  `- Banned IP list:
> 
> Il est donc possible que  soit trop simple
> 
> 
> Le 05/06/2019 ?? 13:33, steve a ??crit??:
>> Le mercredi 05 juin 2019, Yahoo a ??crit??:
>> 
>>> ?? Bonjour,
>>> 
>>> ?? c'est quasiment tous le temps, si tu veux limiter cela tu peux modifier 
>>> le
>>> ?? port de ta connexion ssh, cela ??vite une bonne partie de ces bots,
>> 
>> D??j?? fait depuis longtemps (22->). Peut-??tre faudrait-il que je
>> mette un port moins ??vident???
>> 
>>> ?? ensuite tu peux mettre fail2ban pour les irr??ductibles que trouverais le
>>> ?? bon ports.
>> 
>> # fail2ban-client status sshd
>> Status for the jail: sshd
>> |- Filter
>> |?? |- Currently failed:?? 2
>> |?? |- Total failed:?? 11952
>> |?? `- File list:?? /var/log/auth.log
>> `- Actions
>> ?? |- Currently banned:?? 3
>> ?? |- Total banned:?? 54
>> ?? `- Banned IP list:?? 73.15.91.251 104.248.187.179 41.223.142.211
>> 
>> 
>> Mais en fait ma question ??tait plus sur une ??ventuelle augmentation de
>> la fr??quence de scan que sur les m??thodes de mitigation que je connais
>> d??j?? et qui sont en place.
>> 
> 

--
Pierre Malard

  « Les utopies ne sont souvent que des vérités prématurées »
  Alphonse de Lamartine
   |\  _,,,---,,_
   /,`.-'`'-.  ;-;;,_
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)   πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) )-,_. ,\ 
(  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--



signature.asc
Description: Message signed with OpenPGP

Re: Authentification failure

[Yahoo]

D??sol??, je n'avais pas compris ta demande.

Donc sur la fr??quence, de mon c??t?? j'ai tr??s peu d'attaque force brut 
sur le service ssh, mais effectivement j'utilise un port un peu plus 
exotique que le tiens


la vue pour un serveur up depuis 1 ans:

Status for the jail: sshd
|- Filter
|?? |- Currently failed: 0
|?? |- Total failed: 23
|?? `- File list:?? /var/log/auth.log
`- Actions
 |- Currently banned: 0
 |- Total banned: 1
 `- Banned IP list:

Il est donc possible que  soit trop simple


Le 05/06/2019 ?? 13:33, steve a ??crit??:

Le mercredi 05 juin 2019, Yahoo a ??crit??:


?? Bonjour,

?? c'est quasiment tous le temps, si tu veux limiter cela tu peux 
modifier le

?? port de ta connexion ssh, cela ??vite une bonne partie de ces bots,


D??j?? fait depuis longtemps (22->). Peut-??tre faudrait-il que je
mette un port moins ??vident???

?? ensuite tu peux mettre fail2ban pour les irr??ductibles que 
trouverais le

?? bon ports.


# fail2ban-client status sshd
Status for the jail: sshd
|- Filter
|?? |- Currently failed:?? 2
|?? |- Total failed:?? 11952
|?? `- File list:?? /var/log/auth.log
`- Actions
?? |- Currently banned:?? 3
?? |- Total banned:?? 54
?? `- Banned IP list:?? 73.15.91.251 104.248.187.179 41.223.142.211


Mais en fait ma question ??tait plus sur une ??ventuelle augmentation de
la fr??quence de scan que sur les m??thodes de mitigation que je connais
d??j?? et qui sont en place.

Re: Authentification failure

[steve]

Le mercredi 05 juin 2019, Yahoo a écrit :


  Bonjour,

  c'est quasiment tous le temps, si tu veux limiter cela tu peux modifier le
  port de ta connexion ssh, cela évite une bonne partie de ces bots,


Déjà fait depuis longtemps (22->). Peut-être faudrait-il que je
mette un port moins évident ?


  ensuite tu peux mettre fail2ban pour les irréductibles que trouverais le
  bon ports.


# fail2ban-client status sshd
Status for the jail: sshd
|- Filter
|  |- Currently failed: 2
|  |- Total failed: 11952
|  `- File list:/var/log/auth.log
`- Actions
  |- Currently banned:  3
  |- Total banned:  54
  `- Banned IP list:73.15.91.251 104.248.187.179 41.223.142.211


Mais en fait ma question était plus sur une éventuelle augmentation de
la fréquence de scan que sur les méthodes de mitigation que je connais
déjà et qui sont en place.

Re: Authentification failure

[Cyrille Bollu]

Oui oui ça fait partie de l’Internet standard.

Si cela t’inquiète vraiment, le programme fail2ban peut t’aider.

Cyrille

> Le 5 juin 2019 à 08:37, Belaïd  a écrit :
> 
> Bonjour, 
> 
> Pour ma part,  tout le temps !   et la quasi totalité des tentatives de 
> connexions viennent d'Asie (sans cité un paye en particulier  !   )
> 
> Le mer. 5 juin 2019 08:32, steve  a écrit :
>> Salut à tous,
>> 
>> Depuis une dizaine de jours, j'observe une augmentation massive de scans
>> sur ma machine.
>> 
>> sshd:
>> Authentication Failures:
>>unknown (115.159.235.17): 100 Time(s)
>>unknown (153.37.192.4): 99 Time(s)
>>unknown (183.103.146.208): 99 Time(s)
>>unknown (190.0.159.69): 99 Time(s)
>>unknown (106.13.103.204): 98 Time(s)
>>unknown (109.86.200.141): 98 Time(s)
>>unknown (94.23.62.187): 98 Time(s)
>>unknown (45.127.106.51): 96 Time(s)
>>unknown (103.202.132.175): 95 Time(s)
>>unknown (217.182.95.16): 95 Time(s)
>>unknown (47.74.150.153): 95 Time(s)
>>unknown (220.168.86.37): 87 Time(s)
>>unknown (122.155.223.31): 73 Time(s)
>>unknown (190.111.239.48): 70 Time(s)
>>unknown (188.166.31.205): 56 Time(s)
>>unknown (47.254.158.221): 48 Time(s)
>>unknown (51.15.117.94): 47 Time(s)
>>unknown (142.93.237.233): 34 Time(s)
>>unknown (223.83.155.77): 16 Time(s)
>>unknown (41.77.145.34): 13 Time(s)
>>unknown (118.24.99.163): 12 Time(s)
>>unknown (46.190.57.82): 9 Time(s)
>>unknown (89.79.197.61): 9 Time(s)
>>unknown (115.159.30.108): 8 Time(s)
>>backup (188.166.31.205): 2 Time(s)
>>root (104.236.102.16): 2 Time(s)
>>root (223.17.237.138): 2 Time(s)
>>unknown (128.199.221.18): 2 Time(s)
>>backup (103.202.132.175): 1 Time(s)
>>backup (47.254.158.221): 1 Time(s)
>>backup (47.74.150.153): 1 Time(s)
>>daemon (45.127.106.51): 1 Time(s)
>>backup (188.166.31.205): 2 Time(s)
>>root (104.236.102.16): 2 Time(s)
>>root (223.17.237.138): 2 Time(s)
>>unknown (128.199.221.18): 2 Time(s)
>>backup (103.202.132.175): 1 Time(s)
>>backup (47.254.158.221): 1 Time(s)
>>backup (47.74.150.153): 1 Time(s)
>>daemon (45.127.106.51): 1 Time(s)
>>games (103.202.132.175): 1 Time(s)
>>games (188.166.31.205): 1 Time(s)
>>games (94.23.62.187): 1 Time(s)
>>gnats (159.65.144.233): 1 Time(s)
>>gnats (190.111.239.48): 1 Time(s)
>>gnats (45.127.106.51): 1 Time(s)
>>hplip (103.202.132.175): 1 Time(s)
>>irc (106.13.103.204): 1 Time(s)
>>irc (217.182.95.16): 1 Time(s)
>>irc (41.77.145.34): 1 Time(s)
>>irc (47.74.150.153): 1 Time(s)
>>list (47.254.158.221): 1 Time(s)
>>lp (217.182.95.16): 1 Time(s)
>>mail (103.202.132.175): 1 Time(s)
>>man (115.159.30.108): 1 Time(s)
>>man (153.37.192.4): 1 Time(s)
>>man (47.74.150.153): 1 Time(s)
>>mysql (109.86.200.141): 1 Time(s)
>>mysql (153.37.192.4): 1 Time(s)
>>mysql (190.111.239.48): 1 Time(s)
>>mysql (202.88.241.107): 1 Time(s)
>>mysql (45.127.106.51): 1 Time(s)
>>mysql (51.15.117.94): 1 Time(s)
>>mysql (81.133.216.92): 1 Time(s)
>>mysql (94.23.62.187): 1 Time(s)
>>news (190.0.159.69): 1 Time(s)
>>news (47.74.150.153): 1 Time(s)
>>nobody (118.25.221.166): 1 Time(s)
>>nobody (217.182.95.16): 1 Time(s)
>>plex (217.182.95.16): 1 Time(s)
>>proxy (103.202.132.175): 1 Time(s)
>>proxy (47.74.150.153): 1 Time(s)
>>root (104.248.211.180): 1 Time(s)
>>root (105.235.116.254): 1 Time(s)
>>Invalid Users:
>>Unknown Account: 1610 Time(s)
>> 
>> 
>> Je me demandais si vous observiez la même chose.
>> 
>> Merci
>> 
>> Steve
>> 

Re: Authentification failure

[Yann Serre]

Bonjour,

Même si vous faites parti des personnes sensibilisées, voici un article 
de presse grand public. Je pense que ça a un rapport avec le sujet même 
si la piste mafieuse serait probablement à privilégier.


https://www.ouest-france.fr/high-tech/le-risque-d-un-pearl-harbor-informatique-contre-la-france-est-bien-reel-6381766

Re: Authentification failure

[Jean Millet]

Bonjour,

J’observe cela depuis plusieurs années. au départ les bot chinois qui 
sont très actifs puis d'autres.


Chez GuppY (CMS) nous avons préconisé l'utilisation de blocage de plages 
IP dans le .htaccess à la racine des sites hébergés en mutualisé et nous 
utilisons iptables sur nos serveurs


Exemple pour les htaccess à la racine des sites :


  
    Require all granted

# Cambodia (KH)
Require not ip 114.134.184.0/21
# Chinese (CN) IP addresses follow (split into two lines on 7/6/17 to 
avoid possible Server 500 due to excess line length):
Require not ip 1.24.0.0/13 1.48.0.0/15 1.50.0.0/16 1.56.0.0/13 
1.68.0.0/14 1.80.0.0/13 1.92.0.0/14 1.180.0.0/14 1.188.0.0/14 
1.192.0.0/13 1.202.0.0/15 1.204.0.0/14 14.16.0.0/12 14.104.0.0/13 
14.112.0.0/12 14.134.0.0/15 14.144.0.0/12 14.204.0.0/15 14.208.0.0/12 
23.80.54.0/24 23.104.141.0/24 23.105.14.0/24 23.226.208.0/24 27.8.0.0/13 
27.16.0.0/12 27.36.0.0/14 27.40.0.0/13 27.50.128.0/17 27.54.192.0/18 
27.106.128.0/18 27.115.0.0/17 27.148.0.0/14 27.152.0.0/13 27.184.0.0/13 
27.192.0.0/11 27.224.0.0/14 36.1.0.0/16 36.4.0.0/14 36.26.0.0/16 
36.32.0.0/14 36.36.0.0/16 36.40.0.0/13 36.48.0.0/15 36.56.0.0/13 
36.96.0.0/11 36.128.0.0/11 36.248.0.0/14 39.64.0.0/11 39.128.0.0/10 
42.4.0.0/14 42.48.0.0/15 42.52.0.0/14 42.56.0.0/14 42.84.0.0/14 
42.88.0.0/13 42.96.128.0/17 42.100.0.0/14 42.120.0.0/14 42.156.0.0/16 
42.176.0.0/13 42.185.0.0/16 42.202.0.0/15 42.224.0.0/12 42.242.0.0/15 
42.248.0.0/15 43.255.0.0/20 43.255.16.0/22 43.255.48.0/22 43.255.60.0/22 
43.255.64.0/20 43.255.96.0/20 43.255.144.0/22 43.255.168.0/22 
43.255.176.0/22 43.255.184.0/22 43.255.192.0/22 43.255.200.0/21 
43.255.208.0/21 43.255.224.0/21 43.255.232.0/22 43.255.244.0/22 
47.88.0.0/14 47.92.0.0/14 49.5.0.0/16 49.64.0.0/11 49.112.0.0/13 
54.222.0.0/15 58.16.0.0/14 58.20.0.0/16 58.21.0.0/16 58.22.0.0/15 
58.34.0.0/16 58.37.0.0/16 58.38.0.0/16 58.40.0.0/16 58.42.0.0/16 
58.44.0.0/14 58.48.0.0/13 58.56.0.0/14 58.60.0.0/14 58.68.128.0/17 
58.82.0.0/15 58.100.0.0/15 58.116.0.0/14 58.128.0.0/13 58.208.0.0/12 
58.240.0.0/13 58.248.0.0/13 59.32.0.0/12 59.48.0.0/14 59.52.0.0/14 
59.56.0.0/13 59.72.0.0/16 59.108.0.0/15 59.172.0.0/14 60.0.0.0/12 
60.11.0.0/16 60.12.0.0/14 60.16.0.0/13 60.24.0.0/13 60.160.0.0/11 
60.194.0.0/15 60.205.0.0/16 60.208.0.0/12 60.253.128.0/17 61.4.64.0/20 
61.4.80.0/22 61.4.176.0/20 61.48.0.0/13 61.128.0.0/10 61.135.0.0/16 
61.136.0.0/18 61.139.0.0/16 61.145.73.208/28 61.147.0.0/16 61.150.0.0/16 
61.152.0.0/16 61.154.0.0/16 61.160.0.0/16 61.162.0.0/15 61.164.0.0/16 
61.172.0.0/15 61.175.0.0/16 61.177.0.0/16 61.179.0.0/16 61.183.0.0/16 
61.184.0.0/16 61.185.219.232/29 61.187.0.0/16 61.188.0.0/16 
61.232.0.0/14 61.236.0.0/15 61.240.0.0/14


Etc

__

pour iptables :

iptables -I INPUT 1 -s 212.83.144.0/20 -j DROP
iptables -I INPUT 1 -s 118.200.0.0/16 -j DROP
iptables -I INPUT 1 -s 207.46.0.0/16 -j DROP
iptables -I INPUT 1 -s 54.254.0.0/16 -j DROP
iptables -I INPUT 1 -s 91.224.160.0/23 -j DROP
iptables -I INPUT 1 -s 175.100.144.0/20 -j DROP
iptables -I INPUT 1 -s 134.212.0.0/15 -j DROP
iptables -I INPUT 1 -s 134.214.0.0/16 -j DROP
iptables -I INPUT 1 -s 190.255.176.88/29 -j DROP
iptables -I INPUT 1 -s 118.70.176.0/20 -j DROP
iptables -I INPUT 1 -s 195.154.0.0/17 -j DROP
iptables -I INPUT 1 -s 91.200.12.0/22 -j DROP
iptables-save -c > /etc/iptables-save

Etc


Amicalement,
Jean alias JeandePeyrat
https://www.freeguppy.org/
https://asso.freeguppy.org/
https://www.anacr-correze.fr/
https://Beaucoup d'autres !

Le 05/06/2019 à 08:32, steve a écrit :

Salut à tous,

Depuis une dizaine de jours, j'observe une augmentation massive de scans
sur ma machine.

sshd:
   Authentication Failures:
  unknown (115.159.235.17): 100 Time(s)
  unknown (153.37.192.4): 99 Time(s)
  unknown (183.103.146.208): 99 Time(s)
  unknown (190.0.159.69): 99 Time(s)
  unknown (106.13.103.204): 98 Time(s)
  unknown (109.86.200.141): 98 Time(s)
  unknown (94.23.62.187): 98 Time(s)
  unknown (45.127.106.51): 96 Time(s)
  unknown (103.202.132.175): 95 Time(s)
  unknown (217.182.95.16): 95 Time(s)
  unknown (47.74.150.153): 95 Time(s)
  unknown (220.168.86.37): 87 Time(s)
  unknown (122.155.223.31): 73 Time(s)
  unknown (190.111.239.48): 70 Time(s)
  unknown (188.166.31.205): 56 Time(s)
  unknown (47.254.158.221): 48 Time(s)
  unknown (51.15.117.94): 47 Time(s)
  unknown (142.93.237.233): 34 Time(s)
  unknown (223.83.155.77): 16 Time(s)
  unknown (41.77.145.34): 13 Time(s)
  unknown (118.24.99.163): 12 Time(s)
  unknown (46.190.57.82): 9 Time(s)
  unknown (89.79.197.61): 9 Time(s)
  unknown (115.159.30.108): 8 Time(s)
  backup (188.166.31.205): 2 Time(s)
  root (104.236.102.16): 2 Time(s)
  root (223.17.237.138): 2 Time(s)
  unknown (128.199.221.18): 2 Time(s)
  backup (103.202.132.175): 1 Time(s)
  backup (47.254.158.221): 1 

Re: Authentification failure

[Yahoo]

Bonjour,

c'est quasiment tous le temps, si tu veux limiter cela tu peux modifier 
le port de ta connexion ssh, cela ??vite une bonne partie de ces bots,


ensuite tu peux mettre fail2ban pour les irr??ductibles que trouverais le 
bon ports.


Lo??c

Le 05/06/2019 ?? 08:32, steve a ??crit??:

Salut ?? tous,

Depuis une dizaine de jours, j'observe une augmentation massive de scans
sur ma machine.

sshd:
 Authentication Failures:
?? unknown (115.159.235.17): 100 Time(s)
?? unknown (153.37.192.4): 99 Time(s)
?? unknown (183.103.146.208): 99 Time(s)
?? unknown (190.0.159.69): 99 Time(s)
?? unknown (106.13.103.204): 98 Time(s)
?? unknown (109.86.200.141): 98 Time(s)
?? unknown (94.23.62.187): 98 Time(s)
?? unknown (45.127.106.51): 96 Time(s)
?? unknown (103.202.132.175): 95 Time(s)
?? unknown (217.182.95.16): 95 Time(s)
?? unknown (47.74.150.153): 95 Time(s)
?? unknown (220.168.86.37): 87 Time(s)
?? unknown (122.155.223.31): 73 Time(s)
?? unknown (190.111.239.48): 70 Time(s)
?? unknown (188.166.31.205): 56 Time(s)
?? unknown (47.254.158.221): 48 Time(s)
?? unknown (51.15.117.94): 47 Time(s)
?? unknown (142.93.237.233): 34 Time(s)
?? unknown (223.83.155.77): 16 Time(s)
?? unknown (41.77.145.34): 13 Time(s)
?? unknown (118.24.99.163): 12 Time(s)
?? unknown (46.190.57.82): 9 Time(s)
?? unknown (89.79.197.61): 9 Time(s)
?? unknown (115.159.30.108): 8 Time(s)
?? backup (188.166.31.205): 2 Time(s)
?? root (104.236.102.16): 2 Time(s)
?? root (223.17.237.138): 2 Time(s)
?? unknown (128.199.221.18): 2 Time(s)
?? backup (103.202.132.175): 1 Time(s)
?? backup (47.254.158.221): 1 Time(s)
?? backup (47.74.150.153): 1 Time(s)
?? daemon (45.127.106.51): 1 Time(s)
?? backup (188.166.31.205): 2 Time(s)
?? root (104.236.102.16): 2 Time(s)
?? root (223.17.237.138): 2 Time(s)
?? unknown (128.199.221.18): 2 Time(s)
?? backup (103.202.132.175): 1 Time(s)
?? backup (47.254.158.221): 1 Time(s)
?? backup (47.74.150.153): 1 Time(s)
?? daemon (45.127.106.51): 1 Time(s)
?? games (103.202.132.175): 1 Time(s)
?? games (188.166.31.205): 1 Time(s)
?? games (94.23.62.187): 1 Time(s)
?? gnats (159.65.144.233): 1 Time(s)
?? gnats (190.111.239.48): 1 Time(s)
?? gnats (45.127.106.51): 1 Time(s)
?? hplip (103.202.132.175): 1 Time(s)
?? irc (106.13.103.204): 1 Time(s)
?? irc (217.182.95.16): 1 Time(s)
?? irc (41.77.145.34): 1 Time(s)
?? irc (47.74.150.153): 1 Time(s)
?? list (47.254.158.221): 1 Time(s)
?? lp (217.182.95.16): 1 Time(s)
?? mail (103.202.132.175): 1 Time(s)
?? man (115.159.30.108): 1 Time(s)
?? man (153.37.192.4): 1 Time(s)
?? man (47.74.150.153): 1 Time(s)
?? mysql (109.86.200.141): 1 Time(s)
?? mysql (153.37.192.4): 1 Time(s)
?? mysql (190.111.239.48): 1 Time(s)
?? mysql (202.88.241.107): 1 Time(s)
?? mysql (45.127.106.51): 1 Time(s)
?? mysql (51.15.117.94): 1 Time(s)
?? mysql (81.133.216.92): 1 Time(s)
?? mysql (94.23.62.187): 1 Time(s)
?? news (190.0.159.69): 1 Time(s)
?? news (47.74.150.153): 1 Time(s)
?? nobody (118.25.221.166): 1 Time(s)
?? nobody (217.182.95.16): 1 Time(s)
?? plex (217.182.95.16): 1 Time(s)
?? proxy (103.202.132.175): 1 Time(s)
?? proxy (47.74.150.153): 1 Time(s)
?? root (104.248.211.180): 1 Time(s)
?? root (105.235.116.254): 1 Time(s)
?? Invalid Users:
?? Unknown Account: 1610 Time(s)


Je me demandais si vous observiez la m??me chose.

Merci

Steve

Re: Authentification failure

[Eric Degenetais]

Il y a 5 ans déjà, je constatais des scans à longueur de journées sur l'ip
publique serveurs sans nom de domaine, dès leur première journée. Il y a
clairement une exploration systématique de certaines plages IP à la
recherche de serveurs à subvertir.

Éric Dégenètais

Le mer. 5 juin 2019 8:37 AM, Belaïd  a écrit :

> Bonjour,
>
> Pour ma part,  tout le temps !   et la quasi totalité des tentatives de
> connexions viennent d'Asie (sans cité un paye en particulier  !   )
>
> Le mer. 5 juin 2019 08:32, steve  a écrit :
>
>> Salut à tous,
>>
>> Depuis une dizaine de jours, j'observe une augmentation massive de scans
>> sur ma machine.
>>
>> sshd:
>> Authentication Failures:
>>unknown (115.159.235.17): 100 Time(s)
>>unknown (153.37.192.4): 99 Time(s)
>>unknown (183.103.146.208): 99 Time(s)
>>unknown (190.0.159.69): 99 Time(s)
>>unknown (106.13.103.204): 98 Time(s)
>>unknown (109.86.200.141): 98 Time(s)
>>unknown (94.23.62.187): 98 Time(s)
>>unknown (45.127.106.51): 96 Time(s)
>>unknown (103.202.132.175): 95 Time(s)
>>unknown (217.182.95.16): 95 Time(s)
>>unknown (47.74.150.153): 95 Time(s)
>>unknown (220.168.86.37): 87 Time(s)
>>unknown (122.155.223.31): 73 Time(s)
>>unknown (190.111.239.48): 70 Time(s)
>>unknown (188.166.31.205): 56 Time(s)
>>unknown (47.254.158.221): 48 Time(s)
>>unknown (51.15.117.94): 47 Time(s)
>>unknown (142.93.237.233): 34 Time(s)
>>unknown (223.83.155.77): 16 Time(s)
>>unknown (41.77.145.34): 13 Time(s)
>>unknown (118.24.99.163): 12 Time(s)
>>unknown (46.190.57.82): 9 Time(s)
>>unknown (89.79.197.61): 9 Time(s)
>>unknown (115.159.30.108): 8 Time(s)
>>backup (188.166.31.205): 2 Time(s)
>>root (104.236.102.16): 2 Time(s)
>>root (223.17.237.138): 2 Time(s)
>>unknown (128.199.221.18): 2 Time(s)
>>backup (103.202.132.175): 1 Time(s)
>>backup (47.254.158.221): 1 Time(s)
>>backup (47.74.150.153): 1 Time(s)
>>daemon (45.127.106.51): 1 Time(s)
>>backup (188.166.31.205): 2 Time(s)
>>root (104.236.102.16): 2 Time(s)
>>root (223.17.237.138): 2 Time(s)
>>unknown (128.199.221.18): 2 Time(s)
>>backup (103.202.132.175): 1 Time(s)
>>backup (47.254.158.221): 1 Time(s)
>>backup (47.74.150.153): 1 Time(s)
>>daemon (45.127.106.51): 1 Time(s)
>>games (103.202.132.175): 1 Time(s)
>>games (188.166.31.205): 1 Time(s)
>>games (94.23.62.187): 1 Time(s)
>>gnats (159.65.144.233): 1 Time(s)
>>gnats (190.111.239.48): 1 Time(s)
>>gnats (45.127.106.51): 1 Time(s)
>>hplip (103.202.132.175): 1 Time(s)
>>irc (106.13.103.204): 1 Time(s)
>>irc (217.182.95.16): 1 Time(s)
>>irc (41.77.145.34): 1 Time(s)
>>irc (47.74.150.153): 1 Time(s)
>>list (47.254.158.221): 1 Time(s)
>>lp (217.182.95.16): 1 Time(s)
>>mail (103.202.132.175): 1 Time(s)
>>man (115.159.30.108): 1 Time(s)
>>man (153.37.192.4): 1 Time(s)
>>man (47.74.150.153): 1 Time(s)
>>mysql (109.86.200.141): 1 Time(s)
>>mysql (153.37.192.4): 1 Time(s)
>>mysql (190.111.239.48): 1 Time(s)
>>mysql (202.88.241.107): 1 Time(s)
>>mysql (45.127.106.51): 1 Time(s)
>>mysql (51.15.117.94): 1 Time(s)
>>mysql (81.133.216.92): 1 Time(s)
>>mysql (94.23.62.187): 1 Time(s)
>>news (190.0.159.69): 1 Time(s)
>>news (47.74.150.153): 1 Time(s)
>>nobody (118.25.221.166): 1 Time(s)
>>nobody (217.182.95.16): 1 Time(s)
>>plex (217.182.95.16): 1 Time(s)
>>proxy (103.202.132.175): 1 Time(s)
>>proxy (47.74.150.153): 1 Time(s)
>>root (104.248.211.180): 1 Time(s)
>>root (105.235.116.254): 1 Time(s)
>>Invalid Users:
>>Unknown Account: 1610 Time(s)
>>
>>
>> Je me demandais si vous observiez la même chose.
>>
>> Merci
>>
>> Steve
>>
>>

Re: Authentification failure

[Belaïd]

Bonjour,

Pour ma part,  tout le temps !   et la quasi totalité des tentatives de
connexions viennent d'Asie (sans cité un paye en particulier  !   )

Le mer. 5 juin 2019 08:32, steve  a écrit :

> Salut à tous,
>
> Depuis une dizaine de jours, j'observe une augmentation massive de scans
> sur ma machine.
>
> sshd:
> Authentication Failures:
>unknown (115.159.235.17): 100 Time(s)
>unknown (153.37.192.4): 99 Time(s)
>unknown (183.103.146.208): 99 Time(s)
>unknown (190.0.159.69): 99 Time(s)
>unknown (106.13.103.204): 98 Time(s)
>unknown (109.86.200.141): 98 Time(s)
>unknown (94.23.62.187): 98 Time(s)
>unknown (45.127.106.51): 96 Time(s)
>unknown (103.202.132.175): 95 Time(s)
>unknown (217.182.95.16): 95 Time(s)
>unknown (47.74.150.153): 95 Time(s)
>unknown (220.168.86.37): 87 Time(s)
>unknown (122.155.223.31): 73 Time(s)
>unknown (190.111.239.48): 70 Time(s)
>unknown (188.166.31.205): 56 Time(s)
>unknown (47.254.158.221): 48 Time(s)
>unknown (51.15.117.94): 47 Time(s)
>unknown (142.93.237.233): 34 Time(s)
>unknown (223.83.155.77): 16 Time(s)
>unknown (41.77.145.34): 13 Time(s)
>unknown (118.24.99.163): 12 Time(s)
>unknown (46.190.57.82): 9 Time(s)
>unknown (89.79.197.61): 9 Time(s)
>unknown (115.159.30.108): 8 Time(s)
>backup (188.166.31.205): 2 Time(s)
>root (104.236.102.16): 2 Time(s)
>root (223.17.237.138): 2 Time(s)
>unknown (128.199.221.18): 2 Time(s)
>backup (103.202.132.175): 1 Time(s)
>backup (47.254.158.221): 1 Time(s)
>backup (47.74.150.153): 1 Time(s)
>daemon (45.127.106.51): 1 Time(s)
>backup (188.166.31.205): 2 Time(s)
>root (104.236.102.16): 2 Time(s)
>root (223.17.237.138): 2 Time(s)
>unknown (128.199.221.18): 2 Time(s)
>backup (103.202.132.175): 1 Time(s)
>backup (47.254.158.221): 1 Time(s)
>backup (47.74.150.153): 1 Time(s)
>daemon (45.127.106.51): 1 Time(s)
>games (103.202.132.175): 1 Time(s)
>games (188.166.31.205): 1 Time(s)
>games (94.23.62.187): 1 Time(s)
>gnats (159.65.144.233): 1 Time(s)
>gnats (190.111.239.48): 1 Time(s)
>gnats (45.127.106.51): 1 Time(s)
>hplip (103.202.132.175): 1 Time(s)
>irc (106.13.103.204): 1 Time(s)
>irc (217.182.95.16): 1 Time(s)
>irc (41.77.145.34): 1 Time(s)
>irc (47.74.150.153): 1 Time(s)
>list (47.254.158.221): 1 Time(s)
>lp (217.182.95.16): 1 Time(s)
>mail (103.202.132.175): 1 Time(s)
>man (115.159.30.108): 1 Time(s)
>man (153.37.192.4): 1 Time(s)
>man (47.74.150.153): 1 Time(s)
>mysql (109.86.200.141): 1 Time(s)
>mysql (153.37.192.4): 1 Time(s)
>mysql (190.111.239.48): 1 Time(s)
>mysql (202.88.241.107): 1 Time(s)
>mysql (45.127.106.51): 1 Time(s)
>mysql (51.15.117.94): 1 Time(s)
>mysql (81.133.216.92): 1 Time(s)
>mysql (94.23.62.187): 1 Time(s)
>news (190.0.159.69): 1 Time(s)
>news (47.74.150.153): 1 Time(s)
>nobody (118.25.221.166): 1 Time(s)
>nobody (217.182.95.16): 1 Time(s)
>plex (217.182.95.16): 1 Time(s)
>proxy (103.202.132.175): 1 Time(s)
>proxy (47.74.150.153): 1 Time(s)
>root (104.248.211.180): 1 Time(s)
>root (105.235.116.254): 1 Time(s)
>Invalid Users:
>Unknown Account: 1610 Time(s)
>
>
> Je me demandais si vous observiez la même chose.
>
> Merci
>
> Steve
>
>

Authentification failure

[steve]

Salut à tous,

Depuis une dizaine de jours, j'observe une augmentation massive de scans
sur ma machine.

sshd:
   Authentication Failures:
  unknown (115.159.235.17): 100 Time(s)
  unknown (153.37.192.4): 99 Time(s)
  unknown (183.103.146.208): 99 Time(s)
  unknown (190.0.159.69): 99 Time(s)
  unknown (106.13.103.204): 98 Time(s)
  unknown (109.86.200.141): 98 Time(s)
  unknown (94.23.62.187): 98 Time(s)
  unknown (45.127.106.51): 96 Time(s)
  unknown (103.202.132.175): 95 Time(s)
  unknown (217.182.95.16): 95 Time(s)
  unknown (47.74.150.153): 95 Time(s)
  unknown (220.168.86.37): 87 Time(s)
  unknown (122.155.223.31): 73 Time(s)
  unknown (190.111.239.48): 70 Time(s)
  unknown (188.166.31.205): 56 Time(s)
  unknown (47.254.158.221): 48 Time(s)
  unknown (51.15.117.94): 47 Time(s)
  unknown (142.93.237.233): 34 Time(s)
  unknown (223.83.155.77): 16 Time(s)
  unknown (41.77.145.34): 13 Time(s)
  unknown (118.24.99.163): 12 Time(s)
  unknown (46.190.57.82): 9 Time(s)
  unknown (89.79.197.61): 9 Time(s)
  unknown (115.159.30.108): 8 Time(s)
  backup (188.166.31.205): 2 Time(s)
  root (104.236.102.16): 2 Time(s)
  root (223.17.237.138): 2 Time(s)
  unknown (128.199.221.18): 2 Time(s)
  backup (103.202.132.175): 1 Time(s)
  backup (47.254.158.221): 1 Time(s)
  backup (47.74.150.153): 1 Time(s)
  daemon (45.127.106.51): 1 Time(s)
  backup (188.166.31.205): 2 Time(s)
  root (104.236.102.16): 2 Time(s)
  root (223.17.237.138): 2 Time(s)
  unknown (128.199.221.18): 2 Time(s)
  backup (103.202.132.175): 1 Time(s)
  backup (47.254.158.221): 1 Time(s)
  backup (47.74.150.153): 1 Time(s)
  daemon (45.127.106.51): 1 Time(s)
  games (103.202.132.175): 1 Time(s)
  games (188.166.31.205): 1 Time(s)
  games (94.23.62.187): 1 Time(s)
  gnats (159.65.144.233): 1 Time(s)
  gnats (190.111.239.48): 1 Time(s)
  gnats (45.127.106.51): 1 Time(s)
  hplip (103.202.132.175): 1 Time(s)
  irc (106.13.103.204): 1 Time(s)
  irc (217.182.95.16): 1 Time(s)
  irc (41.77.145.34): 1 Time(s)
  irc (47.74.150.153): 1 Time(s)
  list (47.254.158.221): 1 Time(s)
  lp (217.182.95.16): 1 Time(s)
  mail (103.202.132.175): 1 Time(s)
  man (115.159.30.108): 1 Time(s)
  man (153.37.192.4): 1 Time(s)
  man (47.74.150.153): 1 Time(s)
  mysql (109.86.200.141): 1 Time(s)
  mysql (153.37.192.4): 1 Time(s)
  mysql (190.111.239.48): 1 Time(s)
  mysql (202.88.241.107): 1 Time(s)
  mysql (45.127.106.51): 1 Time(s)
  mysql (51.15.117.94): 1 Time(s)
  mysql (81.133.216.92): 1 Time(s)
  mysql (94.23.62.187): 1 Time(s)
  news (190.0.159.69): 1 Time(s)
  news (47.74.150.153): 1 Time(s)
  nobody (118.25.221.166): 1 Time(s)
  nobody (217.182.95.16): 1 Time(s)
  plex (217.182.95.16): 1 Time(s)
  proxy (103.202.132.175): 1 Time(s)
  proxy (47.74.150.153): 1 Time(s)
  root (104.248.211.180): 1 Time(s)
  root (105.235.116.254): 1 Time(s)
  Invalid Users:
  Unknown Account: 1610 Time(s)


Je me demandais si vous observiez la même chose.

Merci

Steve

Re: Authentification imap par clé

[Wallace]

En mobile ça peut être pénible car ça déconnecte souvent en changement
de réseau mobile et les optimisations batteries ont tendance à couper
cours les communications.

L'autre solution c'est d'avoir un mot de passe renforcé sur ces comptes,
si la personne a un gestionnaire de mot de passe, mettre un mot de passe
de 50 caractères aléatoires qu'elle copie collera dans ses configurations.

Pour Fail2ban, mettre un ban plus long du type 24h voir plus au bout de
10 tentatives infructueuses. 10 tentatives ça laisse de la marge pour
les utilisateurs légitimes qui tapent encore leur mot de passe de tête
et plusieurs jours de ban ça ralentira très très fortement l'utilisateur.

Avec le fail2ban et le mot de passe fort ça rendra la tâche impossible.

Idéalement je rêve d'avoir un système de 2FA sur les comptes mails, mais
je n'ai pas vu d'implémentation probante pourtant sur un élément aussi
vital et sensible ...


Le 21/03/2019 à 17:39, Sil a écrit :
> Le 21/03/2019 à 15:38, Wallace a écrit :
>>
>> As tu regardé si ton bruteforce vise explicitement un compte qui
>> existe déjà?
>>
> Bonjour,
>
> L'attaque est bien ciblée sur des comptes existants...
>
> Le VPN pourrait être une bonne solution, il est déjà en place sur ce
> serveur. Une clé par client. Je vais regarder si ça n'est pas trop
> lourd en utilisation mobile.
>
> Merci.
>
> Sil
>



signature.asc
Description: OpenPGP digital signature

Re: Authentification imap par clé

[Sil]

Le 21/03/2019 à 15:38, Wallace a écrit :


As tu regardé si ton bruteforce vise explicitement un compte qui 
existe déjà?



Bonjour,

L'attaque est bien ciblée sur des comptes existants...

Le VPN pourrait être une bonne solution, il est déjà en place sur ce 
serveur. Une clé par client. Je vais regarder si ça n'est pas trop lourd 
en utilisation mobile.


Merci.

Sil

Authentification imap par clé

[Sil]

Bonjour la liste,

Quelqu'un continue de brute-forcer mes comptes IMAP. Fail2ban le ralenti 
mais ne peut pas le stopper car il change d'IP à chaque connexion.


Existe-t-il un moyen de sécuriser les connexions IMAP externes avec clé 
individuelle comme pour SSH ?

Est-ce compliqué à mettre en œuvre sur courier-imap ?

Par avance merci.

Sil

utiliser sftp dans proftpd avec authentification "Mysql"

[Bernard Schoenacker]

bonjour,

je suis en train de mettre en place alternc et j'ai
créer un user proftpd et je compte employer sftp
pour le transfert, jusque là je n'ai pas de problème
de compréhension 

maintenant dans le tuto j'ai ça :

sudo ssh-keygen -e -f /path/to/id_rsa.pub | sudo tee 
/etc/proftpd/authorized_keys/username_who_owns_key


source :
https://www.digitalocean.com/community/tutorials/how-to-configure-proftpd-to-use-sftp-instead-of-ftp


et je souhaiterai stocker les clés ssh (sftp) dans la base de données mariadb 
car mon user ftp y est déjà enregistré

et proftpd est installé :

dpkg -l |awk '/proftpd/ {print $1" "$2"  "$3}'
hi proftpd-basic  1.3.5b-4
hi proftpd-mod-mysql  1.3.5b-4

pour info, voici la conf de proftpd :

grep ServerName /etc/proftpd/proftpd.conf   
  
ServerName  "AlternC"



comment y arriver ?


merci

slt

bernard

Re: Authentification dans NTP

[Vincent Lefevre]

On 2015-08-24 12:22:40 +0200, j...@free.fr wrote:
> Il y a une couche d'authentification dans NTP ? 

Oui, à partir de NTPv3:

  http://linux.die.net/man/5/ntp_auth

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Authentification dans NTP

[juke]

On Mon, Jul 27, 2015 at 01:13:39AM +0200, Vincent Lefevre wrote:
 
 Je dirais qu'il vaut mieux un véritable client NTP, capable
 d'interroger plusieurs serveurs à la fois, et si possible avec
 de l'authentification. 

Bonjour

Il y a une couche d'authentification dans NTP ? 

Julien 


signature.asc
Description: Digital signature

Re: Authentification webmail

[Vincent Danjean]

On 11/12/2014 15:36, BERTRAND Joël wrote:
 andre_deb...@numericable.fr a écrit :
 On Thursday 11 December 2014 13:29:49 BERTRAND Joël wrote:
 Pour roundcube, j'ai ceci :
 Dec 11 13:23:37 rayleigh imapd-ssl: couriertls: accept:
 error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1
 alert unknown ca

 On dirait un problème de protocole SSL dans imapd-ssl.

Il y a eu des changements dans les (sous)protocoles SSL
supportés dans les différentes bibliothèques suite à des failles
dans les protocoles eux-même.
  C'est possible qu'un protocole qui était utilisé soit maintenant
interdit par le client et/ou le serveur et qu'ils n'arrivent pas
à ce mettre d'accord sur un autre protocole commun.
  Ceci dit, il faudra fouiller plus pour avoir l'info complète.
J'ai mis ici tout ce dont je me souviens de mémoire.

  A+
Vincent



-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54a1d769.8010...@free.fr

Authentification webmail

[BERTRAND Joël]

Bonjour à tous,

	Pour diverses raisons, j'ai un serveur de mail personnel qui fonctionne 
parfaitement avec courrier (imaps/pop3s), sendmail et procmail. Cette 
machine tourne en jessie à jour.


	Lorsque je suis en déplacement, j'utilise au choix squirrelmail 
(connexion lente) ou roundcube.


	Depuis une mise à jour récente, alors que le serveur de mail continue à 
parfaitement fonctionner, je suis devenu incapable de me connecter aux 
webmails. L'authentification échoue. J'avoue ne plus savoir où chercher.


Squirrelmail est assez verbeux et affiche :
Erreur lors de la connexion au serveur IMAP tls://...

Roudcube indique juste que l'authetification a échoué.

	Mais seamonkey arrive parfaitement à se débrouiller en local comme à 
distance (uniquement en ssl). J'ai vérifié les paramètres des deux 
webmails, rien ne me saute aux yeux.


	J'ai bien vu passer une alerte PHP dont certaines fonctions du 5.6 sont 
incompatibles avec les anciennes 5.5, mais je n'ai pas réussi à 
contourner le problème.


Toute idée serait la bienvenue...

Cordialement,

JKB

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/5489743b.9000...@systella.fr

Re: Authentification webmail

[Sébastien NOBILI]

Bonjour,

Le jeudi 11 décembre 2014 à 11:38, BERTRAND Joël a écrit :
   Depuis une mise à jour récente, alors que le serveur de mail continue à
 parfaitement fonctionner, je suis devenu incapable de me connecter aux
 webmails. L'authentification échoue. J'avoue ne plus savoir où chercher.
 
   Squirrelmail est assez verbeux et affiche :
 Erreur lors de la connexion au serveur IMAP tls://...
 
   Roudcube indique juste que l'authetification a échoué.

Courrier est assez verbeux, il trace notamment les ouvertures et fermetures de
session. Par exemple chez moi :

Dec 11 12:32:43 serveur imapd: Connection, ip=[:::192.168.1.52]
Dec 11 12:32:43 serveur imapd: LOGIN, user=, ip=[:::192.168.1.52], 
port=[46932], protocol=IMAP

Quand tu tentes de te connecter avec ton Webmail, vois-tu ce genre de traces
(/var/log/syslog) ?

   J'ai bien vu passer une alerte PHP dont certaines fonctions du 5.6 sont
 incompatibles avec les anciennes 5.5, mais je n'ai pas réussi à contourner
 le problème.

Quelle version de RoundCube utilises-tu ? Celle des dépôts ou bien une autre ?

Chez moi (avec le PHP des dépôts mais un RoundCube venant du site officiel du
projet), je n'ai aucun souci.

Seb

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/2014123506.gb15...@sebian.nob900.homeip.net

Re: Authentification webmail

[BERTRAND Joël]

Sébastien NOBILI a écrit :

Bonjour,

Le jeudi 11 décembre 2014 à 11:38, BERTRAND Joël a écrit :

Depuis une mise à jour récente, alors que le serveur de mail continue à
parfaitement fonctionner, je suis devenu incapable de me connecter aux
webmails. L'authentification échoue. J'avoue ne plus savoir où chercher.

Squirrelmail est assez verbeux et affiche :
Erreur lors de la connexion au serveur IMAP tls://...

Roudcube indique juste que l'authetification a échoué.


Courrier est assez verbeux, il trace notamment les ouvertures et fermetures de
session. Par exemple chez moi :

 Dec 11 12:32:43 serveur imapd: Connection, ip=[:::192.168.1.52]
 Dec 11 12:32:43 serveur imapd: LOGIN, user=, ip=[:::192.168.1.52], 
port=[46932], protocol=IMAP

Quand tu tentes de te connecter avec ton Webmail, vois-tu ce genre de traces
(/var/log/syslog) ?


Pour roundcube, j'ai ceci :

Dec 11 13:23:37 rayleigh imapd-ssl: couriertls: accept: 
error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca


	Pour squirrelmail, j'ai la même chose. Ce comportement semble provenir 
d'une modification du fonctionnement de je ne sais plus quelle fonction 
de php.



J'ai bien vu passer une alerte PHP dont certaines fonctions du 5.6 sont
incompatibles avec les anciennes 5.5, mais je n'ai pas réussi à contourner
le problème.


Quelle version de RoundCube utilises-tu ? Celle des dépôts ou bien une autre ?


Celle des dépôts.


Chez moi (avec le PHP des dépôts mais un RoundCube venant du site officiel du
projet), je n'ai aucun souci.


	Je ne sais pas s'il y a encore un effort pour maintenir roundcube dasn 
les dépôts officiels :-( Il me semble que le problème est corrigé dans 
la version officielle, mais pour l'instant, je préfère rester avec la 
version officielle debian.


Cordialement,

JKB

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54898e3d.3000...@systella.fr

Re: Authentification webmail

[Sébastien NOBILI]

Le jeudi 11 décembre 2014 à 13:29, BERTRAND Joël a écrit :
 Sébastien NOBILI a écrit :
 Bonjour,
 
 Le jeudi 11 décembre 2014 à 11:38, BERTRAND Joël a écrit :
 Depuis une mise à jour récente, alors que le serveur de mail continue à
 parfaitement fonctionner, je suis devenu incapable de me connecter aux
 webmails. L'authentification échoue. J'avoue ne plus savoir où chercher.
 
 Squirrelmail est assez verbeux et affiche :
 Erreur lors de la connexion au serveur IMAP tls://...
 
 Roudcube indique juste que l'authetification a échoué.
 
 Courrier est assez verbeux, il trace notamment les ouvertures et fermetures 
 de
 session. Par exemple chez moi :
 
  Dec 11 12:32:43 serveur imapd: Connection, ip=[:::192.168.1.52]
  Dec 11 12:32:43 serveur imapd: LOGIN, user=, 
  ip=[:::192.168.1.52], port=[46932], protocol=IMAP
 
 Quand tu tentes de te connecter avec ton Webmail, vois-tu ce genre de traces
 (/var/log/syslog) ?
 
   Pour roundcube, j'ai ceci :
 
 Dec 11 13:23:37 rayleigh imapd-ssl: couriertls: accept: error:14094418:SSL
 routines:SSL3_READ_BYTES:tlsv1 alert unknown ca

SSL3 refoulé ? Un rapport avec POODLE peut-être ?

https://fr.wikipedia.org/wiki/POODLE

Le serveur IMAP est-il sur la même machine que le Webmail ? Si oui, le plus
simple sera sûrement de désactiver la crypto dans les échanges…

Si non, alors je vais avoir du mal à t'aider plus, puisque chez moi, la
connexion entre le Webmail et le serveur IMAP se fait en clair (et donc je n'ai
pas le problème).

Seb

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20141211130219.gc15...@sebian.nob900.homeip.net

Re: Authentification webmail

[andre_debian]

On Thursday 11 December 2014 13:29:49 BERTRAND Joël wrote:
   Pour roundcube, j'ai ceci :
 Dec 11 13:23:37 rayleigh imapd-ssl: couriertls: accept:
 error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 
 alert unknown ca 

On dirait un problème de protocole SSL dans imapd-ssl.

Un fichier de conf, openssl, apache... suite à l'upgrade ?

http://serverfault.com/questions/453300/openssl-client-authentication-error-tlsv1-alert-unknown-ca-ssl-alert-numbe

Ça doit pas être trop grave :-)

André

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/201412111407.59443.andre_deb...@numericable.fr

Re: Authentification webmail

[BERTRAND Joël]

andre_deb...@numericable.fr a écrit :

On Thursday 11 December 2014 13:29:49 BERTRAND Joël wrote:

Pour roundcube, j'ai ceci :
Dec 11 13:23:37 rayleigh imapd-ssl: couriertls: accept:
error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1
alert unknown ca


On dirait un problème de protocole SSL dans imapd-ssl.


	Je ne pense pas parce que ce qui n'est pas webmail arrive à 
s'authentifier. Donc le problème n'est pas dans courier.



Un fichier de conf, openssl, apache... suite à l'upgrade ?


Là encore, je ne vois pas trop lequel.


http://serverfault.com/questions/453300/openssl-client-authentication-error-tlsv1-alert-unknown-ca-ssl-alert-numbe

Ça doit pas être trop grave :-)


Certes, mais c'est emm*rdant.

JKB

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/5489abe6.5060...@systella.fr

Re: Forcer authentification smtp

[Gilles Mocellin]

Le 17/12/2013 19:28, Nicolas a écrit :

Bonsoir la liste,

Je continue sur la configuration de mon serveur mail (imap et smtp).
D'abord, merci à Christophe (pour le déblocage du port 25) et Frédéric 
(pour la suggestion du port 587 et du smtp authentifié).
Je voudrais avoir maintenant des pistes pour forcer l'authentification 
smtp. En clair, je voudrais empêcher les connexions sur le port 25 
sans authentification pour forcer les clients mail à utiliser 
l'authentification avec mot de passe sur le port 587 ou 465.


Une piste ?

Cordialement,
Nicolas


Salut,

Il faut utiliser SASL.
Dans ma conf, postfix fait authentifier les clients par dovecot, mon 
server imap. Comme ça, il n'y a qu'une base de login / mot de passe, 
celle de dovecot.


Sur mon postfix, en essayant de ne prendre que les lignes qui concerne 
ce point, j'ai ça dans /etc/postfix/main.cf :


# SASL options: only secure methods, without plain text
broken_sasl_auth_clients = yes
smtpd_sasl_type = dovecot
# Can be an absolute path, or relative to $queue_directory
# Debian/Ubuntu users: Postfix is setup by default to run chrooted, so 
it is best to leave it as-is below

smtpd_sasl_path = private/auth
# and the common settings to enable SASL:
smtpd_tls_auth_only = yes
smtpd_sasl_security_options = noanonymous, noplaintext
smtpd_sasl_tls_security_options = noanonymous
smtpd_sasl_local_domain = $myhostname

smtpd_recipient_restrictions = permit_sasl_authenticated, 
permit_mynetworks, reject_unauth_destination



Je ne passe même pas par un saslauthd, dovecot parle directement SASL.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/52b172a1.4050...@nuagelibre.org

Forcer authentification smtp

[Nicolas]

Bonsoir la liste,

Je continue sur la configuration de mon serveur mail (imap et smtp).
D'abord, merci à Christophe (pour le déblocage du port 25) et Frédéric 
(pour la suggestion du port 587 et du smtp authentifié).
Je voudrais avoir maintenant des pistes pour forcer l'authentification 
smtp. En clair, je voudrais empêcher les connexions sur le port 25 sans 
authentification pour forcer les clients mail à utiliser 
l'authentification avec mot de passe sur le port 587 ou 465.


Une piste ?

Cordialement,
Nicolas

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/24c2a47f8686398d9844e36f7e46c...@tycho.fr

[wheezy][ldap] authentification

[Nicolas Pechon]

Bonjour,

J'essaye d'appliquer ce document:
http://uid.free.fr/Ldap/ldap.html

J'ai créé mon service ldap.
Créer l'architecture ldap
Créer un utilisateur.

Maintenant, j'essaye de configurer le serveur pour utiliser ldap pour
l'authentification.

J'ai donc fait:
cp /usr/share/doc/libnss-ldap/examples/nsswitch.ldap /etc/nsswitch.conf

Afin de prendre en compte ldap.
Puis, j'ai modifié les fichiers: common-auth et common-account à l'aide de
pam-auth-update

Mais, rien n'y fait. Il ne vois pas l'utilisateur test créé avec ldap sur
le serveur.

Si quelqu'un avais une idée ou une piste à suivre.

Merci d'avance

-- 
C'est le temps que tu as perdu pour ta rose qui fait ta rose si importante.
-+- Antoine De Saint-Exupéry -+-


-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
http://lists.debian.org/7bda5268f4198aa080ca0c7fed0e64a0.squirrel@bureau

Re: [wheezy][ldap] authentification

[Nicolas Pechon]

citation de=Nicolas Pechon

 Bonjour,

 J'essaye d'appliquer ce document:
 http://uid.free.fr/Ldap/ldap.html

 J'ai créé mon service ldap.
 Créer l'architecture ldap
 Créer un utilisateur.


Je suis un peu perdu quand à la marche à suivre. Toutefois, j'ai essayé:

 ldapsearch -x -b dc=VeroNico,dc=net -H ldapi://bureau
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

qui ne fonctionne pas. Hors,
ldapsearch -x -b dc=VeroNico,dc=net -h bureau
Fonctionne.

ldapsearch -x -b dc=VeroNico,dc=net -H ldap://bureau
Fonctionne aussi.

J'ai donc essayé de reconfigurer libnss-ldapp afin de le modifier et
d'utiliser ldap://bureau, mais rien n'y fait. :-(


-- 
Le fait de pouvoir élire librement des maîtres ne supprime ni les
maîtres ni les esclaves.
-+- Herbert Marcuse -+-


-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
http://lists.debian.org/6440de903e366c3b20628f289f516cd0.squirrel@bureau

Re: Authentification AD: directe ou via OpenLDAP ?

[Olivier]

Le 9 octobre 2012 09:31, Mathias Dufresne mathias.dufre...@gmail.com a
écrit :

 Salut,

 Les deux devraient fonctionner sans souci, d'un point de
 l'authentification.

 La difficulté réside essentiellement, si je ne dis pas de bêtises, dans la
 configuration de Kerberos, mais le net doit fourmiller de documentation
 depuis le temps que les Linux accèdent aux AD.
 La question du coup me semble plus être :
 - faut-il configurer Kerberos pour une auth directe ?
 - si oui, ne serait-ce pas plus simple de configurer Kerberos avec
 OpenLDAP et avoir une auth web pure LDAP ? Ce qui pourrait faire un poil
 diminuer la sécurité du site s'il n'utilise pas krb, celui-ci ne devant pas
 être complètement inutile :p

 Cdlt,

 mathias

 Le 8 octobre 2012 08:49, Olivier oza_4...@yahoo.fr a écrit :

 Bonjour,

 Je suis totalement novice dans le domaine des annuaires LDAP.
 Je développe une appli web (apache2, ...) qui comprend un module
 d'authentification-autorisation.
 Elle va être utilisée chez un client qui utilise Active Directory.

 Est-il préférable de configurer apache2 pour authentifier-autoriser les
 utilisateurs en interrogeant directement Active Directory ou bien est-il
 préférable d'interroger une base intermédiaire sous OpenLDAP, par exemple,
 et de mettre en place une synchronisation entre OpenLDAP et Active
 Directory ?

 Slts



Suite aux indications de Mathias, je viens en effet, de (re-)découvrir le
protocole Kerberos et son module libapache2-mod-auth-kerb.
Ce protocole semble bien adapté à mon contexte car il permet le Single Sign
On.
Il semble donc possible de configurer Apache2 pour authentifier-autoriser
des utilisateurs définis dans une base Active Directory via le protocole
Kerberos.

Pour bien faire, j'ai recherché des annuaires LDAP Open Source supportant
aussi Kerberos et qui pourraient avantageusement de se substituer  à une
base Active Directory, pour des tests ou des démos, par exemple.

Le projet 389-ds semble inclure un module Kerberos mais 389-ds n'est pas
encore empaqueté pour Squeeze ou Wheezy.
Le projet FusionDirectory prévoit pour sa future version 1.0.5, un plugin
Kerberos mais la version 1.0.4 du projet n'est pas encore publiée.

Avez-vous des recommandations en la matière ?

Re: Authentification AD: directe ou via OpenLDAP ?

[Mathias Dufresne]

Salut,

Les deux devraient fonctionner sans souci, d'un point de
l'authentification.

La difficulté réside essentiellement, si je ne dis pas de bêtises, dans la
configuration de Kerberos, mais le net doit fourmiller de documentation
depuis le temps que les Linux accèdent aux AD.
La question du coup me semble plus être :
- faut-il configurer Kerberos pour une auth directe ?
- si oui, ne serait-ce pas plus simple de configurer Kerberos avec OpenLDAP
et avoir une auth web pure LDAP ? Ce qui pourrait faire un poil diminuer la
sécurité du site s'il n'utilise pas krb, celui-ci ne devant pas être
complètement inutile :p

Cdlt,

mathias

Le 8 octobre 2012 08:49, Olivier oza_4...@yahoo.fr a écrit :

 Bonjour,

 Je suis totalement novice dans le domaine des annuaires LDAP.
 Je développe une appli web (apache2, ...) qui comprend un module
 d'authentification-autorisation.
 Elle va être utilisée chez un client qui utilise Active Directory.

 Est-il préférable de configurer apache2 pour authentifier-autoriser les
 utilisateurs en interrogeant directement Active Directory ou bien est-il
 préférable d'interroger une base intermédiaire sous OpenLDAP, par exemple,
 et de mettre en place une synchronisation entre OpenLDAP et Active
 Directory ?

 Slts

Authentification AD: directe ou via OpenLDAP ?

[Olivier]

Bonjour,

Je suis totalement novice dans le domaine des annuaires LDAP.
Je développe une appli web (apache2, ...) qui comprend un module
d'authentification-autorisation.
Elle va être utilisée chez un client qui utilise Active Directory.

Est-il préférable de configurer apache2 pour authentifier-autoriser les
utilisateurs en interrogeant directement Active Directory ou bien est-il
préférable d'interroger une base intermédiaire sous OpenLDAP, par exemple,
et de mettre en place une synchronisation entre OpenLDAP et Active
Directory ?

Slts

[HS] : HTTPLib2 et 2 way SSL Authentification

[Thierry Leurent]

Bonjour,

!!! Ce mail est HS car, il parle d'une application python tournant !!! 
!!! actuellement sous Windows mais conçue pour fonctionner également !!!
!!! sous Linux !!!

--- Il a également été posté sur une mailing-liste python ---


Je tente de réaliser un gateway SOAP qui utilise une authentification 2 way SSL 
pour se connecter à un organisme mettant à disposition des webservices.
J'ai reçu de mon organisme certificateur (l'état belge) :
- Mon certificat.
- Ma clé privée.
- 2 certificats, dans un format binaire avec l'extension cer, pour le chainage.

J'ai commencé par utiliser wget pour effectuer mes tests.
Après plusieurs essais, j'ai reçu logiquement une erreur 500, en utilisant les 
options suibantes certifile, private-key et no-check-certificate (1).
j'ai déjà réalisé la permière version de ce gateway qui utilise une simple 
connection SSL (one way), j'ai repris le code (HTTPLib2), j'en ai extrait la 
partie utile à l'envois de la requête et je l'ai adapté pour faire du 2 way 
SSL.(2)
Comme vous povez le voir dans le code, j'ai utilisé les même paramètres que 
pour le wget qui a réussi. 
Parcontre sortie(3), je retrouve avec même code d'erreur que si j'ai reçu avec 
wget sans certificat ni clé(4) !!
J'avoue que j'ai un peu de mal à comprendre le pourquoi du comment.

Donc quelqu'un a-t-il une idée comment :
- Intégrer le chaining et éventuellement le trouver. Pour vérifier le certif du 
serveur ?
- Résoudre le problème de HTTPLib2 ?
- Une autre solution.

Attention, mon développement est sous Windows.

Merci

Thierry

(1)Wget: Avec certif. et sans verification du certif..

C:\Program Files\GNU\wgetwget https://b2b-test.webserv.fgov.be:4520 --certific
ate=C:\SOA CA\CERTIF\20120405 c-b2b-test.dosz-ossom.fgov.be.crt --private-
key=
C:\SOA CA\KEYS\c-b2b-test.dosz-ossom.fgov.be.key --no-check-certificate
--2012-04-26 11:48:28--  https://b2b-test.webserv.fgov.be:4520/
Resolving b2b-test.webserv.fgov.be... 85.91.184.96
Connecting to b2b-test.webserv.fgov.be|85.91.184.96|:4520... connected.
WARNING: cannot verify b2b-test.webserv.fgov.be's certificate, issued by `/C=BE
/CN=Government CA/serialNumber=2010':
  Self-signed certificate encountered.
WARNING: certificate common name `b2b-test.ksz.bcss.fgov.be' doesn't match 
reque
sted host name `b2b-test.webserv.fgov.be'.
HTTP request sent, awaiting response... 500 Error
2012-04-26 11:48:28 ERROR 500: Error.

(2)Le code python
#! /usr/bin/env python


import sys, httplib2
import urllib
import ssl

filin = open(C:\\Python\\SOAP\\files\\EdessaRequest.rqst,'r')
SOAPRequest=filin.read()
filin.close()
filin = open(C:\\SOA CA\\KEYS\\c-b2b-test.me.fgov.be.key,'r')
tmpKey=filin.read()
filin.close()
print --- RESULT ---
httplib2.debuglevel = 1
h = httplib2.Http(.cache/EdessaCache, timeout=30, 
disable_ssl_certificate_validation=True)

h.add_certificate(tmpKey, tmpCert, 'b2b-test.webserv.fgov.be')

SOAPServerResponse, SOAPResponseContent = h.request(https://b2b-
test.webserv.fgov.be:4520/TestConnectionServiceService/sendTestMessage,POST, 
body=SOAPRequest, headers={'content-type':'text/plain; charset=utf-8' , 
'SOAPAction':'http://soap.fgov.be/TestConnectionServiceService/sendTestMessage'}
 
)

(3)HTTPLib2 avec certifs et sans verification du certif

--- RESULT ---
Traceback (most recent call last):
  File C:\Python\SOAP\bin\test.py, line 35, in module
SOAPServerResponse, SOAPResponseContent = h.request(https://b2b-test.ksz-
bc
ss.fgov.be:4520/TestConnectionServiceService/sendTestMessage,POST, 
body=SOAPR
equest, headers={'content-type':'text/plain; charset=utf-8' , 
'SOAPAction':'ht
tp://kszbcss.fgov.be/TestConnectionServiceService/sendTestMessage'} )
  File D:\Python27\lib\site-packages\httplib2\__init__.py, line 1544, in 
reque
st
(response, content) = self._request(conn, authority, uri, request_uri, 
metho
d, body, headers, redirections, cachekey)
  File D:\Python27\lib\site-packages\httplib2\__init__.py, line 1294, in 
_requ
est
(response, content) = self._conn_request(conn, request_uri, method, body, 
he
aders)
  File D:\Python27\lib\site-packages\httplib2\__init__.py, line 1230, in 
_conn
_request
conn.connect()
  File D:\Python27\lib\site-packages\httplib2\__init__.py, line 1005, in 
conne
ct
raise SSLHandshakeError(e)
httplib2.SSLHandshakeError: [Errno 1] _ssl.c:504: error:14094410:SSL 
routines:SS
L3_READ_BYTES:sslv3 alert handshake failure

(4)Wget : Sans Certif

C:\Program Files\GNU\wgetwget https://b2b-test.webserv.fgov.be:4520
--2012-04-26 11:41:39--  https://b2b-test.webserv.fgov.be:4520/
Resolving b2b-test.webserv.fgov.be... 85.91.184.96
Connecting to b2b-test.webserv.fgov.be|85.91.184.96|:4520... connected.
OpenSSL: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake 
failu
re
Unable to establish SSL connection.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ

Re: authentification du dépôt backports pour squeeze

[Tulum]

Le dimanche 03 octobre 2010 13:16:41 François, vous avez écrit :
 Le 03/10/2010 11:31, Tulum a écrit :
  Par contre j'ai installé dans les sources le dépôt backports.debian.org.
  Lorsque je met à jour les sources, j'ai un problème d'authentification de
  la source backports.
 
 Il n'y a de backports que pour les versions stables. Il faudra donc
 attendre que la Squeeze soit stable pour qu'elle ait des backports.
ok merci pour la réponse

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/201010091640.57243.tu...@laposte.net

authentification du dépôt backports pour squeeze

[Tulum]

Bonjour,

Je suis sous debian depuis 1 semaine. Pour l'instant tout fonctionne très bien 
et vu l'usage de mon PC (assez basique) cela devrait durer.

Par contre j'ai installé dans les sources le dépôt backports.debian.org. 
Lorsque je met à jour les sources, j'ai un problème d'authentification de la 
source backports.

Je ne trouve pas la clé sur le site et google ne m'aide pas plus.

Une idée ? merci

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/201010031131.06265.tu...@laposte.net

Re: authentification du dépôt backports pour squeeze

[Thierry Chatelet]

On Sunday 03 October 2010 11:31:05 Tulum wrote:
 Bonjour,
 
 Je suis sous debian depuis 1 semaine. Pour l'instant tout fonctionne très
 bien et vu l'usage de mon PC (assez basique) cela devrait durer.
 
 Par contre j'ai installé dans les sources le dépôt backports.debian.org.
 Lorsque je met à jour les sources, j'ai un problème d'authentification de
 la source backports.
 
 Je ne trouve pas la clé sur le site et google ne m'aide pas plus.
 
 Une idée ? merci

Je crois que backport est le portage de  certains package de squeeze vers 
lenny. Donc si tu as une squeeze, backport ne t'apportera rien de nouveau.
Thierry

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/201010031228.44181.tchate...@free.fr

Re: authentification du dépôt backports pour squeeze

[François]

Le 03/10/2010 11:31, Tulum a écrit :

Par contre j'ai installé dans les sources le dépôt backports.debian.org.
Lorsque je met à jour les sources, j'ai un problème d'authentification de la
source backports.


Il n'y a de backports que pour les versions stables. Il faudra donc 
attendre que la Squeeze soit stable pour qu'elle ait des backports.


--
François

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/i89ohg$tj...@dough.gmane.org

Re: authentification du dépô t backports pour squeeze

[Jeremie COURREGES-ANGLAS]

Le Sunday 03 October 2010 à 11:31:05AM, Tulum a écrit :
 Bonjour,
 
 Je suis sous debian depuis 1 semaine. Pour l'instant tout fonctionne très 
 bien 
 et vu l'usage de mon PC (assez basique) cela devrait durer.
 
 Par contre j'ai installé dans les sources le dépôt backports.debian.org. 
 Lorsque je met à jour les sources, j'ai un problème d'authentification de la 
 source backports.
 
 Je ne trouve pas la clé sur le site et google ne m'aide pas plus.
 
 Une idée ? merci
 

http://backports.org/dokuwiki/doku.php?id=instructions

Nettoie tes lunettes ;)

-- 
Free software, free society.
Jérémie Courrèges-Anglas
GPG key : 06A11494


pgpiye78EvRGh.pgp
Description: PGP signature

Re: authentification du dépôt backports pour squeeze

[François]

Le 03/10/2010 13:16, François a écrit :

Le 03/10/2010 11:31, Tulum a écrit :

Par contre j'ai installé dans les sources le dépôt backports.debian.org.
Lorsque je met à jour les sources, j'ai un problème d'authentification
de la
source backports.


Il n'y a de backports que pour les versions stables. Il faudra donc
attendre que la Squeeze soit stable pour qu'elle ait des backports.

Pour accéder aux backports, il faut installer le paquet 
debian-backports-keyring qui fournit la clé.


--
François

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/i8aml0$eq...@dough.gmane.org

rsync vers un serveur ssh avec un port différen t de 22 + authentification clé publique

[Thierry B]

Bonsoir,

J'aimerais effectuer des copies de dossier avec rsync par ssh mais avec
un serveur cible sur un port différent de 22. J'ai installé sur le
serveur distant une clé publique pour pouvoir faire la copie sans
demander de mot de passe pour que ca puisse être automatisé par la suite.

Je remarque que :

ssh -p  u...@host_dest marche.

Mais:

rsync --rsh='ssh -' test.txt u...@host_dest:

donne:

sh: rsync: command not found
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(635)
[sender=3.0.3]

De même pour rsync -e 'ssh -p' :-(

Bizarre, car j'ai vu cette syntaxe sur de nombreux tutos.


J'ai aussi essayé de mettre dans le répertoire .ssh du user de la
machine source, au niveau du fichier config:

Host alias_host_dest
hostname host_dest
port 

puis: rsync test.txt u...@alias_host_dest:

Mais:

ssh u...@alias_host_dest fonctionne aussi nikel sans demander de mdp...


La machine source est sous debian lenny et la cible est une VM sous
Debian lenny aussi.

Une idée?

Merci :-)

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/4c686385.2050...@tbzone.org

Re: rsync vers un serveur ssh avec un port différent de 22 + authentification clé publique

[Thierry B]

Le 16/08/2010 00:00, Thierry B a écrit :
 Bonsoir,
 
 J'aimerais effectuer des copies de dossier avec rsync par ssh mais avec
 un serveur cible sur un port différent de 22. J'ai installé sur le
 serveur distant une clé publique pour pouvoir faire la copie sans
 demander de mot de passe pour que ca puisse être automatisé par la suite.
 
 Je remarque que :
 
 ssh -p  u...@host_dest marche.
 
 Mais:
 
 rsync --rsh='ssh -' test.txt u...@host_dest:
 
 donne:
 
 sh: rsync: command not found
 rsync: connection unexpectedly closed (0 bytes received so far) [sender]
 rsync error: error in rsync protocol data stream (code 12) at io.c(635)
 [sender=3.0.3]
 
 De même pour rsync -e 'ssh -p' :-(
 
 Bizarre, car j'ai vu cette syntaxe sur de nombreux tutos.
 
 
 J'ai aussi essayé de mettre dans le répertoire .ssh du user de la
 machine source, au niveau du fichier config:
 
 Host alias_host_dest
 hostname host_dest
 port 
 
 puis: rsync test.txt u...@alias_host_dest:
 
 Mais:
 
 ssh u...@alias_host_dest fonctionne aussi nikel sans demander de mdp...
 
 
 La machine source est sous debian lenny et la cible est une VM sous
 Debian lenny aussi.
 
 Une idée?
 
 Merci :-)
 

Désolé,

En fait, c'est juste qu'il n'y avait pas rsync d'installer sur la VM
distante...lol.

Bonne soirée.

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/4c6868dd.7050...@tbzone.org

Re: Authentification sur le site de la poste

[Jean-Baptiste Bourgoin]

Le lundi 29 mars 2010 à 22:55 +0200, Guy Roussin a écrit :
 Bonsoir,
 
 https://www.labanquepostale.fr/index.html
 
 Résultats obtenus avec une debian sid 386 à jour :
 
 Avec iceweasel, je n'arrive pas à faire apparaître la
 fenêtre de saisie du compte et du mot de passe
 sur le site de la poste. A la place, j'ai toujours
 connexion réinitialisée.
 
 Avec le navigateur web de gnome (epiphany) et konqueror
 ça va un peu mieux mais il ne m'affiche que des zéros pour les
 codes à saisir et la vocalisation ne marche pas : impossible de
 saisir son code, ou alors, il faut de la chance ;-)
 
 
 C'est finalement avec google chrome que je peux accéder
 à mon compte (ça à l'air aussi ok avec opera, vocalisation ok) ..,
 
 Avez vous les mêmes symptômes ?
 
 
 Merci.
 
 -- 
 Guy

Oui, mais j'ai remarqué quelque chose d'étrange :

Je n'ai ces symptômes que lorsque j'utilise le plugin flash gnash,
lorsque j'installe le plugin flash officiel, j'accède sans problèmes à
la fenêtre de saisie.

Pourtant ce ne me semble pas être un outil flash.

Jean-Baptiste Bourgoin


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: Authentification sur le site de la poste

[Gaëtan PERRIER]

Le Sun, 04 Apr 2010 22:46:21 +0200
Jean-Baptiste Bourgoin monsieur.cami...@gmail.com a écrit:

 Oui, mais j'ai remarqué quelque chose d'étrange :
 
 Je n'ai ces symptômes que lorsque j'utilise le plugin flash gnash,
 lorsque j'installe le plugin flash officiel, j'accède sans problèmes à
 la fenêtre de saisie.
 
 Pourtant ce ne me semble pas être un outil flash.
 

Moi, ça le fait aussi avec le flash d'adobe.

A+

-- 
Gaëtan PERRIER gaetan.perr...@neuf.fr

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20100404230714.7b7cb939.gaetan.perr...@neuf.fr

Re: Authentification sur le site de la poste

[Pierre Meurisse]

Bonjour,

On Mon, Mar 29, 2010 at 10:55:58PM +0200, Guy Roussin wrote:
 
 Bonsoir,
 
 https://www.labanquepostale.fr/index.html
 
 Résultats obtenus avec une debian sid 386 à jour :

chez moi, pas de pb ce matin avec iceweasel et sid amd64.


-- 
Pierre Meurisse

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20100330060848.ga3...@cosidlvm.bureau.maison

Re: Authentification sur le site de la poste

[Alex Perso]

Gaëtan PERRIER a écrit :
 Le Mon, 29 Mar 2010 22:55:58 +0200
 Guy Roussin guy.rous...@teledetection.fr a écrit:
 
 Bonsoir,

 https://www.labanquepostale.fr/index.html

 Résultats obtenus avec une debian sid 386 à jour :

 Avez vous les mêmes symptômes ?


 
 J'ai 3 machines en testing. Une me pose des problèmes mais en
 rechargeant plusieurs fois la page j'arrive à obtenir la page
 d'identification. Avec les deux autres je n'ai jamais de problème.
 J'utilise iceweasel sur les 3.
 
 Gaëtan
 
Idem
En rechargeant plus fois la page, j'arrive à avoir la page de login.

alex

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/4bb1a5d7.3050...@rendour.org

Re: Authentification sur le site de la poste

[Guy Roussin]

https://www.labanquepostale.fr/index.html

Résultats obtenus avec une debian sid 386 à jour :

Avez vous les mêmes symptômes ?


  

J'ai 3 machines en testing. Une me pose des problèmes mais en
rechargeant plusieurs fois la page j'arrive à obtenir la page
d'identification. Avec les deux autres je n'ai jamais de problème.
J'utilise iceweasel sur les 3.


Idem
En rechargeant plus fois la page, j'arrive à avoir la page de login.

alex
  

Merci, effectivement en rechargeant plusieurs fois la page ça fini
par passer ...

--
Guy 


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/4bb1a988.5050...@teledetection.fr

Re: Authentification sur le site de la poste

[Grégory Bulot]

Guy Roussin guy.rous...@teledetection.fr à écrit le Tue, 30 Mar 2010
09:34:32 +0200

 
  Idem
  En rechargeant plus fois la page, j'arrive à avoir la page de login.
 
  alex

 Merci, effectivement en rechargeant plusieurs fois la page ça fini
 par passer ...

ça me fait penser à un problème de load balancing sans transfert de
session, ça ne fait pas avancer le problème directement, mais peut
être qu'en changeant la stratégie locale (iceweasel et le cookies pour
ce site, il pourrait y avoir un moyen de faire fonctionner)

J'ai bon ?

-- 

Cordialement
Grégory BULOT

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20100330093839.4ec15...@morpheus.bulot-fr.com

Re: Authentification sur le site de la poste

[Guy Roussin]

Merci, effectivement en rechargeant plusieurs fois la page ça fini
par passer ...



ça me fait penser à un problème de load balancing sans transfert de
session, ça ne fait pas avancer le problème directement, mais peut
être qu'en changeant la stratégie locale (iceweasel et le cookies pour
ce site, il pourrait y avoir un moyen de faire fonctionner)

J'ai bon ?
  

Je sais pas, en tout cas maintenant ça marche à tous les coups sans avoir
rien fait ! c'est sans doute côté serveur de la poste qu'il se passe des 
choses ...

Si le problème se pose à nouveau, je ferai quelques tests supplémentaires
dans ce sens.

Guy

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/4bb1ae14.1030...@teledetection.fr

Authentification sur le site de la poste

[Guy Roussin]

Bonsoir,

https://www.labanquepostale.fr/index.html

Résultats obtenus avec une debian sid 386 à jour :

Avec iceweasel, je n'arrive pas à faire apparaître la
fenêtre de saisie du compte et du mot de passe
sur le site de la poste. A la place, j'ai toujours
connexion réinitialisée.

Avec le navigateur web de gnome (epiphany) et konqueror
ça va un peu mieux mais il ne m'affiche que des zéros pour les
codes à saisir et la vocalisation ne marche pas : impossible de
saisir son code, ou alors, il faut de la chance ;-)


C'est finalement avec google chrome que je peux accéder
à mon compte (ça à l'air aussi ok avec opera, vocalisation ok) ..,

Avez vous les mêmes symptômes ?


Merci.

--
Guy

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/4bb113de.1060...@teledetection.fr

Re: Authentification sur le site de la poste

[Jean-Yves F. Barbier]

Le Mon, 29 Mar 2010 22:55:58 +0200,
Guy Roussin guy.rous...@teledetection.fr a écrit :

 Bonsoir,
 
 https://www.labanquepostale.fr/index.html
 
 Résultats obtenus avec une debian sid 386 à jour :
 
 Avec iceweasel, je n'arrive pas à faire apparaître la
 fenêtre de saisie du compte et du mot de passe
 sur le site de la poste. A la place, j'ai toujours
 connexion réinitialisée.
 
 Avec le navigateur web de gnome (epiphany) et konqueror
 ça va un peu mieux mais il ne m'affiche que des zéros pour les
 codes à saisir et la vocalisation ne marche pas : impossible de
 saisir son code, ou alors, il faut de la chance ;-)
 
 
 C'est finalement avec google chrome que je peux accéder
 à mon compte (ça à l'air aussi ok avec opera, vocalisation ok) ..,
 
 Avez vous les mêmes symptômes ?

@20100330-000306:TU: Yep avec iceweasel
another fine day in m$ fucking world...

-- 
Even a blind pig stumbles upon a few acorns.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/2010033651.1e41a...@anubis.defcon1

Re: Authentification sur le site de la poste

[Gaëtan PERRIER]

Le Mon, 29 Mar 2010 22:55:58 +0200
Guy Roussin guy.rous...@teledetection.fr a écrit:

 
 Bonsoir,
 
 https://www.labanquepostale.fr/index.html
 
 Résultats obtenus avec une debian sid 386 à jour :
 
 Avec iceweasel, je n'arrive pas à faire apparaître la
 fenêtre de saisie du compte et du mot de passe
 sur le site de la poste. A la place, j'ai toujours
 connexion réinitialisée.
 
 Avec le navigateur web de gnome (epiphany) et konqueror
 ça va un peu mieux mais il ne m'affiche que des zéros pour les
 codes à saisir et la vocalisation ne marche pas : impossible de
 saisir son code, ou alors, il faut de la chance ;-)
 
 
 C'est finalement avec google chrome que je peux accéder
 à mon compte (ça à l'air aussi ok avec opera, vocalisation ok) ..,
 
 Avez vous les mêmes symptômes ?
 
 

J'ai 3 machines en testing. Une me pose des problèmes mais en
rechargeant plusieurs fois la page j'arrive à obtenir la page
d'identification. Avec les deux autres je n'ai jamais de problème.
J'utilise iceweasel sur les 3.

Gaëtan

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20100330005523.4fca77b1.gaetan.perr...@neuf.fr

Re: Authentification smtp

[Mourad Jaber]

On 06/01/2010 10:09, Bernardo wrote:

Bonjour,

ce tuto peut t'intéresser :

http://blog.rom1v.com/2010/01/ajouter-lauthentification-smtp-sur-un-serveur-mail/

C'est pour un Ubuntu Server, mais c'est du Debian ! ;-)

   
Merci pour ce lien, après avoir modifié quelques droits sur les 
répertoires de saslauthd, j'arrive presque à une authentification...


J'ai un souci avec greylist !

Si le domaine vers lequel j'envoie n'est pas connu par greylist, il 
refuse de router le message la première fois, et il faut que j'attende 
le timeout de postgrey pour pouvoir envoyer le message !


Existe-il une possibilité de by passer grey liste pour les utilisateurs 
authentifiés ?


@ +

Mourad



--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org