On 2008-09-08 15:55:30 +0200, mouss wrote:
Vincent Lefevre wrote:
On 2008-09-07 16:02:57 +0200, François Boisson wrote:
Pour ces machines, ce sont les administrateurs qui l'ont mis à no.
La question serait plutôt: pourquoi Debian ne l'a-t-il pas mis à no
par défaut?
Pourquoi il est mis à no:
On 2008-09-08 14:53:45 +0200, François Cerbelle wrote:
Le Lun 8 septembre 2008 13:59, Grégory Bulot a écrit :
[...]
d'ailleurs ce serait sympa que parmis les choix dispo (quand un fichier
config, n'est pas identique a celui proposé par la mainteneur), il y
est backup de l'ancien, comme
Moi je garde toutes les modif des principaux fichiers de config via
Subversion. Ça permet aussi de voir quand il y a des changements
lors d'un upgrade de paquets.
d'ailleurs ce serait sympa que parmis les choix dispo (quand un fichier
config, n'est pas identique a celui proposé par la
Le Lun 8 septembre 2008 13:59, Grégory Bulot a écrit :
[...]
d'ailleurs ce serait sympa que parmis les choix dispo (quand un fichier
config, n'est pas identique a celui proposé par la mainteneur), il y
est backup de l'ancien, comme c'est le cas pour xorg-xserver
On 2008-09-07 20:44:24 +0200, mouss wrote:
un truc utile: quand tu modifies un fichier qui vient avec le système,
garde une copie de l'original. j'ai une tendance maniaque à faire des
titi.ORIG. ça s'avère utile si on veut comparer ou si on veut extraire
un diff pour le faire sur une
On 2008-09-07 16:02:57 +0200, François Boisson wrote:
Pour ces machines, ce sont les administrateurs qui l'ont mis à no.
La question serait plutôt: pourquoi Debian ne l'a-t-il pas mis à no
par défaut?
Pourquoi il est mis à no:
Vincent Lefevre wrote:
On 2008-09-07 16:02:57 +0200, François Boisson wrote:
Pour ces machines, ce sont les administrateurs qui l'ont mis à no.
La question serait plutôt: pourquoi Debian ne l'a-t-il pas mis à no
par défaut?
Pourquoi il est mis à no:
N'est-ce pas déjà ce qui se produit avec les fichiers .dist ? Quand
un paquet veut modifier un fichier de configuration qui a été édité
manuellement, si on choisi de conserver le fichier édité
manuellement, le fichier de configuration livré dans le paquet est
renommé en .dist, à côté du
Le Monday 08 September 2008 vers 13:35, Vincent Lefevre(Vincent
Lefevre [EMAIL PROTECTED]) a écrit:
Salut,
Moi je garde toutes les modif des principaux fichiers de config
via Subversion. Ça permet aussi de voir quand il y a des
changements lors d'un upgrade de paquets.
Une petite info:
Salut,
À mon avis, c'est parce que l'authentification par mot de passe est
désactivée dans SSH.
Vérifie son paramétrage:
grep Password /etc/ssh/sshd_config
PermitEmptyPasswords no
PasswordAuthentication yes
JB
giggz a écrit :
Bonsoir,
j'ai un soucis avec ssh.
J'ai regénéré toutes mes clés
Bonjour,
Le dimanche 07 septembre 2008, giggz a écrit...
1:47 [EMAIL PROTECTED] ~/.ssh % ssh grut
Permission denied (publickey).
Avez vous une idée ?
As tu copié les clés ?
As tu supprimé les anciennes entrées dans le fichier .ssh/known_hosts ?
--
jm
A.E.L. Sarl (R.C.S CASTRES
Salut,
À mon avis, l'authentification par mot de passe est désactivée dans SSH:
grep Password /etc/ssh/sshd_config
PermitEmptyPasswords no
PasswordAuthentication yes
JB
giggz a écrit :
Bonsoir,
j'ai un soucis avec ssh.
J'ai regénéré toutes mes clés (root et user). J'ai un serveur où j'ai de
Jean Baptiste FAVRE a écrit :
Salut,
À mon avis, c'est parce que l'authentification par mot de passe est
désactivée dans SSH.
Vérifie son paramétrage:
grep Password /etc/ssh/sshd_config
PermitEmptyPasswords no
PasswordAuthentication yes
c'est tout à fait vrai! et si je l'active ça
Jean-Michel OLTRA a écrit :
Bonjour,
Le dimanche 07 septembre 2008, giggz a écrit...
1:47 [EMAIL PROTECTED] ~/.ssh % ssh grut
Permission denied (publickey).
Avez vous une idée ?
As tu copié les clés ?
As tu supprimé les anciennes entrées dans le fichier .ssh/known_hosts ?
giggz a écrit :
Jean-Michel OLTRA a écrit :
Bonjour,
Le dimanche 07 septembre 2008, giggz a écrit...
1:47 [EMAIL PROTECTED] ~/.ssh % ssh grut
Permission denied (publickey).
Avez vous une idée ?
As tu copié les clés ?
As tu supprimé les anciennes entrées dans le fichier
giggz a écrit :
giggz a écrit :
Jean-Michel OLTRA a écrit :
Bonjour,
Le dimanche 07 septembre 2008, giggz a écrit...
1:47 [EMAIL PROTECTED] ~/.ssh % ssh grut
Permission denied (publickey).
Avez vous une idée ?
As tu copié les clés ?
As tu supprimé les anciennes entrées dans le
On 2008-09-07 10:08:48 +0200, giggz wrote:
si je mets PasswordAuthentication = yes sur mon laptop ok. mais pourquoi
ça marche direct sur mon serveur ? est ce à cause de la différence de
version de ssh ?
Tu peux savoir ce que fait ssh avec ssh -vvv.
--
Vincent Lefèvre [EMAIL PROTECTED] - Web:
On 2008-09-07 09:21:25 +0200, Jean-Michel OLTRA wrote:
1:47 [EMAIL PROTECTED] ~/.ssh % ssh grut
Permission denied (publickey).
Avez vous une idée ?
As tu copié les clés ?
As tu supprimé les anciennes entrées dans le fichier .ssh/known_hosts ?
Le .ssh/known_hosts n'a rien à voir avec
giggz wrote:
giggz a écrit :
giggz a écrit :
Jean-Michel OLTRA a écrit :
Bonjour,
Le dimanche 07 septembre 2008, giggz a écrit...
1:47 [EMAIL PROTECTED] ~/.ssh % ssh grut
Permission denied (publickey).
Avez vous une idée ?
As tu copié les clés ?
As tu supprimé les anciennes entrées
On 2008-09-07 10:26:52 +0200, giggz wrote:
si je mets ChallengeResponseAuthentication yes sur le laptop j'obtiens
le même comportement que pour le serveur.
Elle est à no sur au moins une de mes machines Debian; elle ne doit
pas être utile...
qqn sait à quoi correcspond exactement cette option
mouss a écrit :
giggz wrote:
giggz a écrit :
giggz a écrit :
Jean-Michel OLTRA a écrit :
Bonjour,
Le dimanche 07 septembre 2008, giggz a écrit...
1:47 [EMAIL PROTECTED] ~/.ssh % ssh grut
Permission denied (publickey).
Avez vous une idée ?
As tu copié les clés ?
As tu supprimé
Bonjour,
Le dimanche 07 septembre 2008, Julien Valroff a écrit...
Où sont donc stockées les clés du client sur le serveur ssh, alors.
~/.ssh/authorized_keys
Ah, c'est vrai, j'ai confondu. Mille excuses.
--
jm
A.E.L. Sarl (R.C.S CASTRES 490843240)
http://www.spidboutic.fr
--
mouss a écrit :
giggz wrote:
giggz a écrit :
giggz a écrit :
Jean-Michel OLTRA a écrit :
Bonjour,
Le dimanche 07 septembre 2008, giggz a écrit...
1:47 [EMAIL PROTECTED] ~/.ssh % ssh grut
Permission denied (publickey).
Avez vous une idée ?
As tu copié les clés ?
As tu supprimé
On 2008-09-07 11:11:14 +0200, giggz wrote:
rhaaa mes espoirs de résolution propre s'envolent...
es tu en stable, en sid ?
Il y a des machines en stable, d'autres en sid.
--
Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/
100% accessible validated (X)HTML - Blog:
Bonjour,
Le dimanche 07 septembre 2008, Vincent Lefevre a écrit...
Le .ssh/known_hosts n'a rien à voir avec les clés liées à l'utilisateur.
Où sont donc stockées les clés du client sur le serveur ssh, alors.
Lorsqu'il y a un problème avec l'authentification de l'hôte, le
message
Vincent Lefevre a écrit :
On 2008-09-07 10:08:48 +0200, giggz wrote:
si je mets PasswordAuthentication = yes sur mon laptop ok. mais pourquoi
ça marche direct sur mon serveur ? est ce à cause de la différence de
version de ssh ?
Tu peux savoir ce que fait ssh avec ssh -vvv.
voilà ce que
On 2008-09-07 11:26:36 +0200, giggz wrote:
[...]
debug2: key: /home/giggz/.ssh/identity ((nil))
debug2: key: /home/giggz/.ssh/id_rsa ((nil))
debug2: key: /home/giggz/.ssh/id_dsa (0xb85e6348)
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list
Le dimanche 07 septembre 2008 à 11:35 +0200, Jean-Michel OLTRA a écrit :
Bonjour,
Le dimanche 07 septembre 2008, Vincent Lefevre a écrit...
Le .ssh/known_hosts n'a rien à voir avec les clés liées à l'utilisateur.
Où sont donc stockées les clés du client sur le serveur ssh, alors.
Vincent Lefevre a écrit :
On 2008-09-07 11:26:36 +0200, giggz wrote:
[...]
debug2: key: /home/giggz/.ssh/identity ((nil))
debug2: key: /home/giggz/.ssh/id_rsa ((nil))
debug2: key: /home/giggz/.ssh/id_dsa (0xb85e6348)
debug1: Authentications that can continue: publickey
debug3: start over,
On 2008-09-07 11:23:56 +0200, giggz wrote:
Tu as donc modifié le comportement par défaut de ssh, non ? chez moi
en stable le yes est par défaut. Tu as une raison d'avoir mis
ChallengeResponseAuthentication no ?
Pour ces machines, ce sont les administrateurs qui l'ont mis à no.
La question
On 2008-09-07 12:48:56 +0200, giggz wrote:
bon je vais laisser le ChallengeResponseAuthentication yes par
défaut...tant pis...
Je te conseille tout de même de vérifier que sur ta machine,
l'authentification se fait par clé publique. Autrement, il peut
s'agir d'un gros trou de sécurité.
--
Vincent Lefevre a écrit :
On 2008-09-07 12:48:56 +0200, giggz wrote:
bon je vais laisser le ChallengeResponseAuthentication yes par
défaut...tant pis...
Je te conseille tout de même de vérifier que sur ta machine,
l'authentification se fait par clé publique. Autrement, il peut
s'agir d'un
giggz a écrit :
Vincent Lefevre a écrit :
On 2008-09-07 12:48:56 +0200, giggz wrote:
bon je vais laisser le ChallengeResponseAuthentication yes par
défaut...tant pis...
Je te conseille tout de même de vérifier que sur ta machine,
l'authentification se fait par clé publique. Autrement, il
Pour ces machines, ce sont les administrateurs qui l'ont mis à no.
La question serait plutôt: pourquoi Debian ne l'a-t-il pas mis à no
par défaut?
Pourquoi il est mis à no:
http://www.redhat.com/archives/redhat-list/2002-June/msg02462.html
Sur mes machines, soit ça n'est pas précisé, soit il
http://securepoint.com/lists/html/OpenSSH/2007-03/msg00070.html
pourra t'intéresser. C'est un problème analogue au tien.
François Boisson
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs
François Boisson a écrit :
http://securepoint.com/lists/html/OpenSSH/2007-03/msg00070.html
pourra t'intéresser. C'est un problème analogue au tien.
François Boisson
Ok, merci j'ai lu.
j'ai donc mis à no sur mon serveur et mon laptop. ce qui m'étonne ce que
je n'ai pas touché au
giggz wrote:
mouss a écrit :
ici:
$ grep ChallengeResp /etc/ssh/sshd_config
ChallengeResponseAuthentication no
et je n'ai pas de problème.
Tu as donc modifié le comportement par défaut de ssh, non ?
non. et comme je nepouvais pas le jurer, je viens de le reinstaller (sur
une etch) et
giggz wrote:
François Boisson a écrit :
http://securepoint.com/lists/html/OpenSSH/2007-03/msg00070.html
pourra t'intéresser. C'est un problème analogue au tien.
François Boisson
Ok, merci j'ai lu.
j'ai donc mis à no sur mon serveur et mon laptop. ce qui m'étonne ce que
je n'ai pas touché
mouss wrote:
giggz wrote:
François Boisson a écrit :
http://securepoint.com/lists/html/OpenSSH/2007-03/msg00070.html
pourra t'intéresser. C'est un problème analogue au tien.
François Boisson
Ok, merci j'ai lu.
j'ai donc mis à no sur mon serveur et mon laptop. ce qui m'étonne ce que
je
mouss a écrit :
giggz wrote:
mouss a écrit :
ici:
$ grep ChallengeResp /etc/ssh/sshd_config
ChallengeResponseAuthentication no
et je n'ai pas de problème.
Tu as donc modifié le comportement par défaut de ssh, non ?
non. et comme je nepouvais pas le jurer, je viens de le reinstaller
giggz wrote:
mouss a écrit :
giggz wrote:
mouss a écrit :
ici:
$ grep ChallengeResp /etc/ssh/sshd_config
ChallengeResponseAuthentication no
et je n'ai pas de problème.
Tu as donc modifié le comportement par défaut de ssh, non ?
non. et comme je nepouvais pas le jurer, je viens de le
Bonsoir,
j'ai un soucis avec ssh.
J'ai regénéré toutes mes clés (root et user). J'ai un serveur où j'ai de
même. Je supprime tous les firewall. je peux me connecter ss probleme
sur mon serveur en ssh. mais je ne peux pas me connecter de mon serveur
vers mon laptop.
De même si dans une console
42 matches
Mail list logo